Subject: [zf-contributors] Zend Framework 1.8.0 sanity check tarballs available

From: Matthew Weier O'Phinney <[email-masked]>
Date: Tue, 28 Apr 2009 01:41:24 -0400

We have posted sanity check tarballs of the upcoming 1.8.0 release on
the site. You may get them at the following URLs:

    http://framework.zend.com/releases/preview/ZendFramework-1.8.0.tar.gz
    http://framework.zend.com/releases/preview/ZendFramework-1.8.0.zip
    http://framework.zend.com/releases/preview/ZendFramework-1.8.0-minimal.tar.gz
    http://framework.zend.com/releases/preview/ZendFramework-1.8.0-minimal.zip
    http://framework.zend.com/releases/preview/ZendAMF-1.8.0.tar.gz
    http://framework.zend.com/releases/preview/ZendAMF-1.8.0.zip
    http://framework.zend.com/releases/preview/ZendGdata-1.8.0.tar.gz
    http://framework.zend.com/releases/preview/ZendGdata-1.8.0.zip
    http://framework.zend.com/releases/preview/ZendInfoCard-1.8.0.tar.gz
    http://framework.zend.com/releases/preview/ZendInfoCard-1.8.0.zip

Please let the Zend Framework team know ASAP if you notice any critical
errors. We will be releasing within the next few days.

Thanks again for all the hard work -- the end is in sight!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 19:30:59 +0100
From: till <[email-masked]>
To: Giorgio Sironi <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

On Thu, Feb 25, 2010 at 6:37 PM, Giorgio Sironi
<[email-masked]> wrote:
> On Thu, Feb 25, 2010 at 5:44 PM, Luke Crouch <[email-masked]> wrote:
>>
>> Maybe I'm turning into a crotchety old programmer, but I'm not really
>> impressed with git. We switched from svn to git at my day job and I
>> haven't really seen any big benefits aside from a few sweet syntactic
>> shortcuts like git stash. For larger projects with well-organized
>> branching I just haven't seen much additional value from git.
>
> I'm also starting out with git. The point is in having the possibility to
> branch at every moment of development, and to use those branches to merge
> changes that would break the trunk. With distributed version control branch
> is very cheap and people working on unstable components will be happier.
>

+1

@Luke

If you're not convinced, I urge you to check in something like Magento
into subversion and then into git. =) The pure performance is reason
enough to switch. That, and the "almost-anything-merger". :)

Till

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 20:59:01 +0100
From: Juozas <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

-1 from me too.

Looking at the interface it's absolutely not clear what are those two
methods intended for. Interfaces should not require looking at the
actual implementation to get that some methods are just for the sake
of making testing easier (?) and in all implementations just provide a
proxy.

Personally, I think that once you can do things in more than 1 way,
it's confusing and misleading (not in all senses, but in a sense of
method call). Now it *might* work if that proxy is provided by
abstract class (just to make code more backwards compatible/any other
reason), but still since we are talking about 2.0 here, I'd rather
have only __invoke.

Speaking of tests, I didn't completely get where the problem lies:

$filter->filter($value);

becomes:

$filter($value);

is this the refactoring you are mentioning?

--
Juozas Kaziuk=C4=97nas ([email-masked])
My website - JuoKaz (http://www.juokaz.com)

On Wed, Mar 31, 2010 at 8:38 PM, Lukas K=C3=B6ll <[email-masked]> wrote:
> -1 from me, too - I'm totally agreeing with Renan.
> Additionally I don't think design decisions should be based on how much w=
ork it
> is to write the corresponding unit tests. Don't get me wrong, of course t=
he code
> must be testable. But especially for framework code I think that a low ov=
erhead
> should be preferred against easier testability - infact framework code is
> written (or changed) far more seldom than executed.
>
> If, however you decide to use __invoke as proxy, I would recommend to som=
ehow
> prevent the proxied methods (filter, validate) to be called from outside =
or at least mark them as deprecated
> so client code _must_ use invoke and we could then remove the proxies lat=
er on if
> it should be decided that the tests are rewritten.
>
> best regards
>
> Lukas K=C3=B6ll
>
>> -1
>>
>> Talking to my coworkers, a big piece of people take a little more time
>> to understand something when there is more than one way to do what
>> they want to do. I think that when we start a new project with
>> unnecessary duplicated features it's not good. This usually happens
>> after years, we should get this situations away. Obviously sometimes
>> it's interesting we provide alternative ways to achieve a goal, but
>> for those situations =C2=A0(filter, validator...) it's not.
>>
>>>> The benefits:
>>>>
>>>> * Fewer changes necessary to existing unit tests
>>
>> time is the solution ;-)
>>
>>>> * interface method names may be more descriptive of intent
>>
>> they should pick a better name for their variables, like $filterFloat,
>> $filterAlpha
>>
>>>> Problems:
>>>>
>>>> * Using __invoke() introduces overhead -- 2 method calls instead of on=
e
>>>> * Redundancy (two methods doing the same thing)
>>
>> that's my point! this extra way is not relevant, this one adds no new fe=
ature
>>
>>>> * A few extra tests to write (to ensure __invoke works as expecte)
>>
>> my 1 cent ;-)
>>
>> --
>> Renan de Lima Barbosa
>> gtalk/msn: [email-masked]
>> skype: renandelima
>> +55 61 8166-7755
>> renandelima.com
>>
>>
>>
>> On 31 March 2010 11:38, Dennis Winter <[email-masked]> =
wrote:
>>> +1 on this! It's ok to have two methods for the same thing! And the ben=
efit
>>> of clearer interfaces is overwhelming the disadvantages!
>>> Just my 2 cents!
>>>
>>> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney <[email-masked]=
m>:
>>>
>>>> Greetings, all --
>>>>
>>>> Per the roadmap, one change we're planning on making is making plugin
>>>> usage consistent across components: plugins will implement __invoke(),
>>>> which makes them inherently callable.
>>>>
>>>> In our refactoring branch, I've done this now with Zend_Filter. Howeve=
r,
>>>> it required a ton of refactoring on the unit tests (had to either call
>>>> __invoke() directly, or $filter($value)), and it got me to thinking:
>>>>
>>>> Would it make sense to keep the original interfaces (filter, isValid,
>>>> render, etc.), but also implement __invoke() -- having it proxy to the
>>>> appropriate interface method?
>>>>
>>>> As an example:
>>>>
>>>> =C2=A0 interface Filter
>>>> =C2=A0 {
>>>> =C2=A0 =C2=A0 =C2=A0 public function filter($value);
>>>> =C2=A0 =C2=A0 =C2=A0 public function __invoke($value);
>>>> =C2=A0 }
>>>>
>>>> =C2=A0 class Digits implements Filter
>>>> =C2=A0 {
>>>> =C2=A0 =C2=A0 =C2=A0 public function filter($value)
>>>> =C2=A0 =C2=A0 =C2=A0 {
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... logic...
>>>> =C2=A0 =C2=A0 =C2=A0 }
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0 public function __invoke($value)
>>>> =C2=A0 =C2=A0 =C2=A0 {
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return $this->filter($value);
>>>> =C2=A0 =C2=A0 =C2=A0 }
>>>> =C2=A0 }
>>>>
>>>> The benefits:
>>>>
>>>> * Fewer changes necessary to existing unit tests
>>>> * interface method names may be more descriptive of intent
>>>>
>>>> Problems:
>>>>
>>>> * Using __invoke() introduces overhead -- 2 method calls instead of on=
e
>>>> * Redundancy (two methods doing the same thing)
>>>> * A few extra tests to write (to ensure __invoke works as expecte)
>>>>
>>>> After discussion with Ralph and Alex, I'm leaning towards having
>>>> __invoke() as an _additional_ method, instead of replacing existing
>>>> methods.
>>>>
>>>> Any thoughts or comments?
>>>>
>>>> --
>>>> Matthew Weier O'Phinney
>>>> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]=
om
>>>> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.ze=
nd.com/
>>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>>
>
>

nFrom nobody Wed Apr  7 08:46:06 2010
Date: Tue, 22 Sep 2009 21:26:04 +0200
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?
From: Tobias Gies <[email-masked]>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Cc: "Matthew Weier O'Phinney" <[email-masked]>, 
	Zend Framework Contributors <[email-masked]>

--001485f772a2c11fa004742f915e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would have written my own statement, but Paddy's sums it up quite nicely.
A pl release will do :).

Best regards,
Tobias

2009/9/22 P=E1draic Brady <[email-masked]>

> I don't envy you the decision.
>
> My 2c, is that the usage is probably not obscure or uncommon. There was
> bound to be attempted uses of such a common method that just worked (whet=
her
> the behaviour was intentional or not) and never changed. In that sense, i=
t
> should not have changed in a minor release, but been reserved for a point
> release with the current minor version's method docblock, and the
> documentation (to raise awareness), both modified to signal it would chan=
ge
> for definite with 1.10.
>
> I also don't think it's such a major problem, yet, to require a complete
> rebuild. So a patch level release to deprecate the current seems like a
> suitable and prompt response.
>
> P=E1draic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative<http://www.openideurope.eu/=
>
>
>
> ------------------------------
> *From:* Matthew Weier O'Phinney <[email-masked]>
> *To:* [email-masked]
> *Sent:* Tuesday, September 22, 2009 7:01:47 PM
> *Subject:* [zf-contributors] Considering yanking 1.9.3 -- thoughts?
>
> I'd like the opinion of the various contributors, if you could.
>
> There's been a lot of debate about the BC break regarding
> Zend_Db::factory(), and I'm even hearing rumblings about forks over it.
> Putting all personal issues aside, I'd like to hear your thoughts about
> how we should proceed.
>
> First, I need to give some background about the situation we find
> ourselves in, and not just from the code side.
>
> On the code side, the matter is spelled out in the release announcement:
>
>     http://dz.zend.com/a/10050
>
> On the non-code side, we have a number of issues going on.
>
> First, on my side, I did not realize a BC break had occurred until this
> morning -- and not from any official report in response to the sanity
> check packages, but from an innocent post on fw-general. At that time,
> we were already in progress deploying the packages and site updates.
> For better or worse, re-packaging and releasing takes ~6-8 hours. It's
> non-trivial, and this is why we do it on a schedule (what takes so long?
> primarily building the manuals, building the API docs, and creating the
> manual search indexes).
>
> Second, we have an added onus this week: our colo facility is being
> relocated at the end of the week, and we have a very small window for
> getting new packages released before we have to sync and do a site
> freeze.
>
> The options I can see are:
>
> * Yank the current package, and rebuild.
> * Create a patch-level package (1.9.3pl1), and deprecate 1.9.3.
> * Do nothing, and continue on.
>
> I understand that many do not see original behavior as buggy, and relied
> on it. I also feel that the new solution is much better -- but if
> somebody can propose and implement a better one, I'm open to it.
>
> I'd like to make a decision in the next few hours; if new packages are
> needed, we need to make them ASAP.
>
> Please spread the word about this post and help in the process.
>
> Thanks!
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--001485f772a2c11fa004742f915e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would have written my own statement, but Paddy&#39;s sums it up quite nic=
ely. A pl release will do :).<br><br>Best regards,<br>Tobias<br><br><div cl=
ass=3D"gmail_quote">2009/9/22 P=E1draic Brady <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span><=
br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div style=
=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;">I =
don&#39;t envy you the decision.<br>
<br>My 2c, is that the usage is probably not obscure or uncommon. There was=
 bound to be attempted uses of such a common method that just worked (wheth=
er the behaviour was intentional or not) and never changed. In that sense, =
it should not have changed in a minor release, but been reserved for a poin=
t release with the current minor version&#39;s method docblock, and the doc=
umentation (to raise awareness), both modified to signal it would change fo=
r definite with 1.10.<br>
<br>I also don&#39;t think it&#39;s such a major problem, yet, to require a=
 complete rebuild. So a patch level release to deprecate the current seems =
like a suitable and prompt response.<br><div>=A0</div><span style=3D"color:=
 rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new york,time=
s,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br>
<br></span></font><span style=3D"font-style: italic;"><font style=3D"font-f=
amily: times new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow=
" href=3D"http://blog.astrumfutura.com" target=3D"_blank">http://blog.astru=
mfutura.com</a><br>
<a rel=3D"nofollow" href=3D"http://www.survivethedeepend.com" target=3D"_bl=
ank">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" href=3D"ht=
tp://www.openideurope.eu/" target=3D"_blank">OpenID Europe Foundation Irish=
 Representative</a><br>
</font></span></span><div><br></div><div style=3D"font-family: times new ro=
man,new york,times,serif; font-size: 12pt;"><br><div style=3D"font-family: =
tahoma,new york,times,serif; font-size: 8pt;"><font size=3D"2" face=3D"Taho=
ma"><hr size=3D"1">
<b><span style=3D"font-weight: bold;">From:</span></b> Matthew Weier O&#39;=
Phinney &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">matthew@z=
end.com</a>&gt;<br><b><span style=3D"font-weight: bold;">To:</span></b> <a =
href=3D"mailto:[email-masked]" target=3D"_blank">zf-contrib=
[email-masked]</a><br>
<b><span style=3D"font-weight: bold;">Sent:</span></b> Tuesday, September 2=
2, 2009 7:01:47 PM<br><b><span style=3D"font-weight: bold;">Subject:</span>=
</b> [zf-contributors] Considering yanking 1.9.3 -- thoughts?<br></font><di=
v>
<div></div><div class=3D"h5"><br>
I&#39;d like the opinion of the various contributors, if you could.<br><br>=
There&#39;s been a lot of debate about the BC break regarding<br>Zend_Db::f=
actory(), and I&#39;m even hearing rumblings about forks over it.<br>Puttin=
g all personal issues aside, I&#39;d like to hear your thoughts about<br>
how we should proceed.<br><br>First, I need to give some background about t=
he situation we find<br>ourselves in, and not just from the code side.<br><=
br>On the code side, the matter is spelled out in the release announcement:=
<br>
<br><span>=A0 =A0 <a href=3D"http://dz.zend.com/a/10050" target=3D"_blank">=
http://dz.zend.com/a/10050</a></span><br><br>On the non-code side, we have =
a number of issues going on. <br><br>First, on my side, I did not realize a=
 BC break had occurred until this<br>
morning -- and not from any official report in response to the sanity<br>ch=
eck packages, but from an innocent post on fw-general. At that time,<br>we =
were already in progress deploying the
 packages and site updates.<br>For better or worse, re-packaging and releas=
ing takes ~6-8 hours. It&#39;s<br>non-trivial, and this is why we do it on =
a schedule (what takes so long?<br>primarily building the manuals, building=
 the API docs, and creating the<br>
manual search indexes). <br><br>Second, we have an added onus this week: ou=
r colo facility is being<br>relocated at the end of the week, and we have a=
 very small window for<br>getting new packages released before we have to s=
ync and do a site<br>
freeze.<br><br>The options I can see are:<br><br> * Yank the current packag=
e, and rebuild.<br> * Create a patch-level package (1.9.3pl1), and deprecat=
e 1.9.3.<br> * Do nothing, and continue on.<br><br>I understand that many d=
o not see original behavior as buggy, and relied<br>
on it. I also feel that the new solution is much better -- but if<br>somebo=
dy can propose and implement a better one, I&#39;m open to it.<br><br>I&#39=
;d like to make a decision in the next few
 hours; if new packages are<br>needed, we need to make them ASAP. <br><br>P=
lease spread the word about this post and help in the process.<br><br>Thank=
s!<br><br>-- <br>Matthew Weier O&#39;Phinney<br>Project Lead=A0 =A0 =A0 =A0=
 =A0 =A0 | <a href=3D"mailto:[email-masked]" target=3D"_blank">matthew@ze=
nd.com</a><br>
<span>Zend Framework=A0 =A0 =A0 =A0 =A0 | <a href=3D"http://framework.zend.=
com/" target=3D"_blank">http://framework.zend.com/</a></span><br></div></di=
v></div></div></div></div></blockquote></div><br>

--001485f772a2c11fa004742f915e--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 5 Apr 2010 08:04:35 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

-- Giorgio Sironi <[email-masked]> wrote
(on Saturday, 03 April 2010, 12:41 PM +0200):
> From a design point of view we can make an example:
> <?php
> interface CapableOfSomething
> {
>     public function doSomething(MyClass $value);
>     public function __invoke(MyClass $value);
> }
> When there is a type hint on the parameter, it is clearer that there
> is a duplication in place: the methods accomplish the same thing, and
> are coupled to change together. I agree that removing the analogue to
> doSomething() makes the code less readable when using a single object,
> so probably __invoke() has to go.
> Placing an __invoke() method only on implementations it's useful to
> simplify the chaining, but there is no way to enforce its
> implementation (maybe a separate interface Chainable?)

Actually, with filter chains, you're simply attaching callbacks to the
chain. In such a case, it can check to see if the object passed
is_callable(); if not, then it can throw an exception (or allow passing
a second parameter indicating the method to call, which is how I handle
it in Phly_PubSub).

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Thu, 19 Mar 2009 16:41:14 -0700
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] Code freeze for 1.8 is Friday!

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A8EC.31511F36
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK, now that I have your attention, code freeze for 1.8 isn't really
Friday. But it should be. J

=20

That is to say, we're getting pretty close, and soon I will try
something new and actually tell you when the release date is. ;) It a
safe bet that it will be within a month or so.

=20

That means that if you have a proposal in the standard or extras
incubators that you want to get in to 1.8, you should finish it ASAP.
I've cleaned up both areas and left messages on the proposals that have
a chance of getting in to 1.8, and I noticed someone graciously sorted
the extras and standard incubator proposals in to the right categories
(my money is on Matthew). Take a look at these and please decide which
ones you'll finish for 1.8 in the next few days. You don't have to tell
anyone, just get them done. J

=20

On a related note, we'll be making a print-on-demand version of our ref
guide available through our publishing partner, Apress. They would like
to have all the 1.8 documentation completed by 3/31 so that we know how
long the book will be. Since it's also just generally a good idea,
please finish your docs by this date and check them in. They don't have
to be perfect- and I'll always help with English grammar for anyone who
requests it- but you could help us a lot by committing a rough draft by
this deadline.

=20

Things are going to start getting pretty exciting in the next few weeks.
I hope everyone is looking forward to it as much as I am. J

=20

Thanks!

,Wil

=20

=20

------_=_NextPart_001_01C9A8EC.31511F36
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>OK, now that I have your attention, code freeze for =
1.8 isn&#8217;t
really Friday. But it should be. <span =
style=3D'font-family:Wingdings'>J</span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>That is to say, we&#8217;re getting pretty close, =
and soon I
will try something new and actually tell you when the release date is. =
;) It a
safe bet that it will be within a month or so.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>That means that if you have a proposal in the =
standard or
extras incubators that you want to get in to 1.8, you should finish it =
ASAP. I&#8217;ve
cleaned up both areas and left messages on the proposals that have a =
chance of
getting in to 1.8, and I noticed someone graciously sorted the extras =
and
standard incubator proposals in to the right categories (my money is on =
Matthew).
Take a look at these and please decide which ones you&#8217;ll finish =
for 1.8
in the next few days. You don&#8217;t have to tell anyone, just get them =
done. <span
style=3D'font-family:Wingdings'>J</span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>On a related note, we&#8217;ll be making a =
print-on-demand version
of our ref guide available through our publishing partner, Apress. They =
would
like to have all the 1.8 documentation completed by 3/31 so that we know =
how
long the book will be. Since it&#8217;s also just generally a good idea, =
please
finish your docs by this date and check them in. They don&#8217;t have =
to be
perfect- and I&#8217;ll always help with English grammar for anyone who =
requests
it- but you could help us a lot by committing a rough draft by this =
deadline.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Things are going to start getting pretty exciting =
in the
next few weeks. I hope everyone is looking forward to it as much as I =
am. <span
style=3D'font-family:Wingdings'>J</span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks!<o:p></o:p></p>

<p class=3DMsoNormal>,Wil<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9A8EC.31511F36--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 20 Jan 2010 17:02:55 +0100
From: Giorgio Sironi <[email-masked]>
To: Mihai Bojin <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend_Grid component proposal

--0016e6d64b1838e8a4047d9ab8fa
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 20, 2010 at 2:55 PM, Mihai Bojin <[email-masked]> wrote:

> Hello Everyone,
>
> I submitted a proposal for review and right now I'm waiting for any
> suggestions, advice, opinions and so on :)
>
> You can check out the proposal here:
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin
>
> Any feedback will be greatly appreciated !
>
>
Do you intend to take advantage of Zend_Dojo? There is a dojo component
named Datagrid which takes a lot of work to integrate currently, and that
would be a nice feature.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d64b1838e8a4047d9ab8fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jan 20, 2010 at 2:55 PM, Mihai Bojin <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">mihai.bojin@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddi=
ng-left: 1ex;">
Hello Everyone,<br>
<br>
I submitted a proposal for review and right now I&#39;m waiting for any sug=
gestions, advice, opinions and so on :)<br>
<br>
You can check out the proposal here:<br>
<a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+=
Bojin" target=3D"_blank">http://framework.zend.com/wiki/display/ZFPROP/Zend=
_Grid+-+Mihai+Bojin</a><br>
<br>
Any feedback will be greatly appreciated !<br>
<br></blockquote><br>Do you intend to take advantage of Zend_Dojo? There is=
 a dojo component named Datagrid which takes a lot of work to integrate cur=
rently, and that would be a nice feature.<br></div><br>-- <br>Giorgio Siron=
i<br>
Piccolo Principe &amp; Web Engineer<br><a href=3D"http://giorgiosironi.blog=
spot.com">http://giorgiosironi.blogspot.com</a><br><a href=3D"http://twitte=
r.com/giorgiosironi">http://twitter.com/giorgiosironi</a><br>

--0016e6d64b1838e8a4047d9ab8fa--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Cc: [email-masked]
Date: Mon, 15 Mar 2010 17:55:19 +0100
From: [email-masked]
To: till <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 option classes for methods

> I think these are used to do cover __get() (and well, __set()
> with @property-write).

@Till

Ups, it should be @property and yes it is to cover __get() and __set().

Michael Rasmussen

--=20
GRATIS f=FCr alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 26 Oct 2009 13:55:42 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.9.5 sanity check packages available

Greetings!

The ZF 1.9.5 sanity check packages are now available for testing:

 * Full packages:
   http://framework.zend.com/releases/preview/ZendFramework-1.9.5/ZendFramework-1.9.5.tar.gz
   http://framework.zend.com/releases/preview/ZendFramework-1.9.5/ZendFramework-1.9.5.zip

 * Minimal packages:
   http://framework.zend.com/releases/preview/ZendFramework-1.9.5/ZendFramework-1.9.5-minimal.tar.gz
   http://framework.zend.com/releases/preview/ZendFramework-1.9.5/ZendFramework-1.9.5-minimal.zip

Alternately, you may also simply point to the release tag and test from
there:

   http://framework.zend.com/svn/framework/standard/tags/release-1.9.5

Please let me or someone else on the team know ASAP if you notice any
issues. We plan on releasing during the day tomorrow, 27 Oct 2009.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:06 2010
Subject: Re: [zf-contributors] Discussion about Quality/Review Process -
	Community RM proposal
From: Carlton Gibson <[email-masked]>
Date: Wed, 23 Sep 2009 15:20:51 +0100
Cc: [email-masked]
To: "Matthew Weier O'Phinney" <[email-masked]>

--Apple-Mail-2-530544926
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes

On 23 Sep 2009, at 15:16, Matthew Weier O'Phinney wrote:

> -- Carlton Gibson <[email-masked]> wrote
> (on Wednesday, 23 September 2009, 02:29 PM +0100):
>> P draic makes many fine points. I just want to pause on one:
>> On 23 Sep 2009, at 13:52, P draic Brady wrote:
>>
>>
>>    Documentation is the least of the worries. Mostly it's accurate,  
>> but it
>>    does need a fuller review at some point, or a deliberate restart  
>> for Zend
>>    Framework 2.0. It's main problem is that it's written by  
>> developers (that
>>    will not change ;)) but also that it seems impervious to any  
>> form of
>>    iterative improvement. Once written, documentation rarely  
>> changes and any
>>    of its flaws become permanent problems that will very rarely  
>> ever reach the
>>    issue tracker.
>>
>>
>> [snip]
>>
>>
>>    Of course all of my meandering has one simple problem - how to
>>    motivate the community to actively take part and contribute their
>>    time and skill.  Without that, it would all be doomed to failure
>>    anyway.
>>
>>
>> I know I've mentioned it before but having a wiki for the
>> documentation would (I think) make _many_ more people contribute.
>>
>> The response previously was that we can't have a Wiki because of the
>> need to use Docbook. Having pondered this response I can't see that  
>> it
>> follows. Wikis are about collaborative editing, Docbook is a
>> markup/storage format; surely the wiki could write to Docbook? (Does
>> the software for this not already exist? I'm sure we could knock it  
>> up
>> in Rails in no time :-)
>
> DocBook is the holy grail of documentation formats. It allows for easy
> transformation of markup from XML to HTML, PDF, LaTeX, and much, much
> more (I've even seen DocBook -> OO.o). Currently, we actually use
> targets for HTML, PDF, and CHM (which is really just HTML zipped up
> specially).
>
> Additionally, having the documentation in docbook allows us to do  
> things
> such as easily version the documentation, do fallbacks from  
> translations
> to English, programmatically verify programlistings, etc.
>
> Finally, having the docbook versioned ensures that only those who have
> signed a CLA have rights to edit the documentation -- which is an
> important part of the contribution process.
>
> Is it possible to do wiki -> docbook conversions? Yes. But then we  
> lose
> many of the benefits already mentioned, add an extra step to the
> process, and lose any sort of review process for ensuring good  
> structure
> and translations, AND we open up the very real possiblity of people
> adding erroneous information without having peer review.
>
> Yes, some of these issues exist in the existing documentation.  
> However,
> Thomas and Mikael have already spearheaded an effort to tighten up the
> documentation process in terms of ensuring good document structure and
> translation review. These facets very much hinge on using DocBook. On
> top of this, since taking over as project lead, I've been reviewing
> documentation prior to inclusion in trunk, in an attempt to ensure
> better quality. Additionally, one part of the documentation effort  
> is to
> provide the ability to add comments within the manual. Once this
> functionality is added, we can periodically review comments to see  
> where
> changes need to be made in the manual.
>
> BTW, Rails *used* to use a wiki for documentation, but has since moved
> to docbook. New documentation or community-contributed docs are in a
> wiki, but migrated to docbook once they mature. The reasons for  
> doing so
> are very similar to those I've outlined above.
>
> We will not be using the wiki for the official documentation, period.

Fair enough. Perhaps the ability to comment will be enough --- my  
concern is simply that of lowering the barrier to entry... :-)
--Apple-Mail-2-530544926
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 23 Sep 2009, at 15:16, Matthew Weier O'Phinney =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>-- Carlton Gibson &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]=
k</a>&gt; wrote<br>(on Wednesday, 23 September 2009, 02:29 PM =
+0100):<br><blockquote type=3D"cite">P draic makes many fine points. I =
just want to pause on one: <br></blockquote><blockquote type=3D"cite">On =
23 Sep 2009, at 13:52, P draic Brady wrote:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;Documentation is the least of the worries. Mostly it's =
accurate, but it<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;does need a fuller review at some point, or a =
deliberate restart for Zend<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;Framework 2.0. It's main problem is that it's written =
by developers (that<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;will not change ;)) but also that it seems impervious =
to any form of<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;iterative improvement. Once written, documentation =
rarely changes and any<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;of its flaws become permanent problems that will very =
rarely ever reach the<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;issue tracker.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">[snip]<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;Of course all of my meandering has one simple problem =
- how to<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;motivate the community to actively take part and =
contribute their<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;time and skill. &nbsp;Without that, it would all be =
doomed to failure<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;anyway.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I know I've =
mentioned it before but having a wiki for =
the<br></blockquote><blockquote type=3D"cite">documentation would (I =
think) make _many_ more people contribute. <br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The response =
previously was that we can't have a Wiki because of =
the<br></blockquote><blockquote type=3D"cite">need to use Docbook. =
Having pondered this response I can't see that =
it<br></blockquote><blockquote type=3D"cite">follows. Wikis are about =
collaborative editing, Docbook is a<br></blockquote><blockquote =
type=3D"cite">markup/storage format; surely the wiki could write to =
Docbook? (Does<br></blockquote><blockquote type=3D"cite">the software =
for this not already exist? I'm sure we could knock it =
up<br></blockquote><blockquote type=3D"cite">in Rails in no time :-) =
<br></blockquote><br>DocBook is the holy grail of documentation formats. =
It allows for easy<br>transformation of markup from XML to HTML, PDF, =
LaTeX, and much, much<br>more (I've even seen DocBook -&gt; OO.o). =
Currently, we actually use<br>targets for HTML, PDF, and CHM (which is =
really just HTML zipped up<br>specially).<br><br>Additionally, having =
the documentation in docbook allows us to do things<br>such as easily =
version the documentation, do fallbacks from translations<br>to English, =
programmatically verify programlistings, etc.<br><br>Finally, having the =
docbook versioned ensures that only those who have<br>signed a CLA have =
rights to edit the documentation -- which is an<br>important part of the =
contribution process.<br><br>Is it possible to do wiki -&gt; docbook =
conversions? Yes. But then we lose<br>many of the benefits already =
mentioned, add an extra step to the<br>process, and lose any sort of =
review process for ensuring good structure<br>and translations, AND we =
open up the very real possiblity of people<br>adding erroneous =
information without having peer review.<br><br>Yes, some of these issues =
exist in the existing documentation. However,<br>Thomas and Mikael have =
already spearheaded an effort to tighten up the<br>documentation process =
in terms of ensuring good document structure and<br>translation review. =
These facets very much hinge on using DocBook. On<br>top of this, since =
taking over as project lead, I've been reviewing<br>documentation prior =
to inclusion in trunk, in an attempt to ensure<br>better quality. =
Additionally, one part of the documentation effort is to<br>provide the =
ability to add comments within the manual. Once this<br>functionality is =
added, we can periodically review comments to see where<br>changes need =
to be made in the manual.<br><br>BTW, Rails *used* to use a wiki for =
documentation, but has since moved<br>to docbook. New documentation or =
community-contributed docs are in a<br>wiki, but migrated to docbook =
once they mature. The reasons for doing so<br>are very similar to those =
I've outlined above.<br><br>We will not be using the wiki for the =
official documentation, period.<font class=3D"Apple-style-span" =
color=3D"#000000"><font class=3D"Apple-style-span" =
color=3D"#144FAE"><br></font></font></div></blockquote><br></div><div>Fair=
 enough. Perhaps the ability to comment will be enough --- my concern is =
simply that of lowering the barrier to entry... :-)</div></body></html>=

--Apple-Mail-2-530544926--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 21 Sep 2009 12:59:31 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code freeze for 1.9.3 is in place

Hey, all --

We're preparing to package 1.9.3. Please refrain from merging changesets
to the 1.9 release branch until we lift the freeze.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 11 Apr 2009 08:57:16 -0700
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] [[email-masked]: Re: [zf-contributors] 
	Proposal to update Abstract/Interface Naming Conventions]

--001485f791ce0d11f20467498926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

"There have been a TON of debates amongst ZF contributors about naming,
and making the names meaningful. I would expect that this proposal would
probably be very welcome to those individuals. (Matt R., I'm looking at
you...)"
Meaningful names are great!  It just depends on what you mean by
"meaningful".  For me, it mean clearly communicating the role of a class, so
that users can instantly determine how classes are interrelated, even if
they're navigating the code online.  Right now we have that: it is clear
that Zend_Controller_Request_Http extends Zend_Controller_Request_Abstract,
even before you open either, and even if you aren't using an IDE.
 Zend_Controller_Request_Http extending Zend_Controller_Request would also
communicate that.  I would like to retain that quality of the file
organization.

With the following names...

 * Zend\Controller\Request\RequestEnvironment, RequestObject
   (interface, abstract)
 * Zend\Controller\Response\ResponsePayload, ResponseObject
   (interface, abstract)
 * Zend\Controller\Dispatcher\DispatchMapper (interface)

...excepting this one...

 * Zend\Validate\Validatible, Validator (interface, abstract)

...it is not really apparent what relates to what.  RequestEnvironment does
not communicate Interface to me, and RequestObject does not communicate
abstract.  While you may say that that's irrelevant because we have IDEs, I
would say that these names have the potential to be more confusing, because
there are no rules for how environments and objects and payloads and mappers
are related.  If I'm looking to extend one of these classes (which happens
frequently), I have to study a few classes to figure out how everything
interacts.  Today I can open the abstract or interface and get right to
work.

One other thing.  There are going to be cases where these names are going to
be really awkward.  One of the great things about frameworks in general is
that they remove choices so that you can focus on getting the job done.
 IRequest, IResponse--there is no thought required for these names.  But in
the other scenario contributors must determine whether RequestEnvironment,
RequestObject, Requestable, or whatever most effectively communicates its
role.

If we go this route, I also think we're going to end up standardizing on
some things simply in an effort to avoid the above.  I think Object will
become a stand-in for Abstract, for example (RequestObject).  I think
standardization of this kind results in a clear API, but in effect, it is a
form of limited Hungarian notation through the back door.  If we are
ultimately going to go that route, we should just do it up front.  Honestly,
I would even be OK with AbstractRequest and RequestInterface, although I
know you would hate that idea.  :-)

-Matt

On Fri, Apr 10, 2009 at 4:13 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> -- Matthew Weier O'Phinney <[email-masked]> wrote
> (on Friday, 10 April 2009, 04:39 PM -0400):
> > Forwarding from Ben, who intended to copy the list...
> >
> > ----- Forwarded message from Benjamin Eberlei <[email-masked]>
> -----
> >
> > From: Benjamin Eberlei <[email-masked]>
> > To: Matthew Weier O'Phinney <[email-masked]>
> > Date: Fri, 10 Apr 2009 18:58:02 +0000
> > Subject: Re: [zf-contributors] Proposal to update Abstract/Interface
> Naming
> >       Conventions
> >
> >
> > moving to this new namespace implementation and breaking all old ones is
> a
> > serious BC,
> > so why do we only allow slight changes for everything else? I thought we
> > would just go to "change the serious technical debt, but as BC as
> > possible", changing the name of an interface is the exact difference of
> > that.
>
> It is, but we're going to need to do it once we move to namespaces
> anyways -- because our CS were written before namespaces were even
> proposed for inclusion in PHP.
>
> This is also why I propose the gradual changes over a series of
> versions. This allows us to provide migration instructions that users
> can gradually implement, making their code more future-proof. If the
> new versions of the interfaces and abstract classes extend the
> originals, there is no BC break until we finally drop the old classes --
> which, as I mentioned, will not happen until 2.0.
>
> > additionally, the generic name one seems strange in my eyes. How would
> you
> > do that for
> > the example of request, response, dispatcher? Validation interface?
>
> First off, the request and response objects need interfaces, and then
> potentially abstract implementations. Either way, this is easy:
>
>  * Zend\Controller\Request\RequestEnvironment, RequestObject
>    (interface, abstract)
>  * Zend\Controller\Response\ResponsePayload, ResponseObject
>    (interface, abstract)
>  * Zend\Controller\Dispatcher\DispatchMapper (interface)
>  * Zend\Validate\Validatible, Validator (interface, abstract)
>
> The names take a little creativity, but they also make it clearer in
> your code what you're doing:
>
>    namespace Zend\Controller\Request;
>
>    class HttpEnvironment implements RequestEnvironment
>    {
>    }
>
>    // or
>    namespace Zend\Validate;
>
>    class Alpha extends Validator
>    {
>     }
>
> > i don't seem to find good ones. ResponseObject, RequestObject,
> > Validatable are ok, but from the typehints its very hard to suggest
> > that these are interfaces in contrast to concrete implementation.
>
> Typehints should typically be to interfaces anyways...
>
> > furthermore, why break with the ways of java, python, and .net? this is
> > what many programmers are used to.
>
> Because Java and .Net are strongly typed languages, and PHP isn't.
> Because just because a convention worked for one language doesn't mean
> it's appropriate for another. Because PHP is not Java, is not Python, is
> not .NET.
>
> There have been a TON of debates amongst ZF contributors about naming,
> and making the names meaningful. I would expect that this proposal would
> probably be very welcome to those individuals. (Matt R., I'm looking at
> you...)
>
> > As a last point, having implementation and interface in different
> > packages is actually the single most important issue about having an
> > interface anyways and a huge benefit for object oriented design.  this
> > separates the concerns and reduces dependencies, so I would love to
> > see this in a 2.0 version.
>
> There's a difference between using an interface in userland code, and
> using one within a framework or library. In your userland code, you
> *will* have the interface in a different package:
>
>    namespace Foo\Controller\Request;
>    import Zend\Controller\Request as ZfRequest;
>
>    CustomHttpRequest extends ZfRequest\HttpEnvironment
>    {
>    }
>
> *Within* the framework, it's better for them to be in the same
> namespace, to allow selectively packaging components for distribution or
> deployment.
>
> > That is what i am greatly missing in ZF, that for example the
> > controller is implemented with several very large abstract classes
> > only and the dependencies are so hard-wired that its impossible to
> > exchange just one part of the controller to add specific functionality
> > without having to change considerable other parts also.
>
> This has nothing to do with naming conventions, and is a topic we
> already plan to address for (or before) 2.0. (Please search for
> "Zend_Controller 2.0" on the wiki for some of the plans.)
>
> > On Fri, 10 Apr 2009 14:24:34 -0400, Matthew Weier O'Phinney
> > <[email-masked]> wrote:
> > > Greetings, all --
> > >
> > > Below is a proposal I am making to modify the Zend Framework Coding
> > > Standards conventions for the naming of Interfaces and Abstract
> classes.
> > >
> > > This decision is basically already made, but I'd appreciate any
> feedback
> > > that you may have on the matter.
> > >
> > > Thanks!
> > >
> > > The problem
> > > ===========
> > > PHP 5.3 introduces namespaces to the PHP language. While this won't
> have
> > > an
> > > impact much on userland code, it will have an impact on library and
> > > framework
> > > code, as it provides a useful paradigm for organizing components as
> well
> > > as
> > > simplifying syntax. Instead of having to say things like:
> > >
> > >     $analyzer = new
> > Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> > >
> > > we can instead do something like this:
> > >
> > >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > >
> > >     $analyzer = new Common_TextNum();
> > >
> > > or even:
> > >
> > >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > >
> > >     class Common_TextNum extends Common
> > >     {
> > >     }
> > >
> > > The problem that arises for Zend Framework has to do with how we name
> > > abstract
> > > classes and interfaces. Currently, the final segment of such classes
> are
> > > expected to end with _Abstract and _Interface, respectively. This will
> > not
> > > work
> > > when we migrate to utilize namespaces, for two reasons.
> > >
> > > First, and most obviously, 'abstract' and 'interface' are reserved PHP
> > > keywords.
> > > As such, in situations such as the following:
> > >
> > >     namespace Zend\Controller\Request;
> > >
> > >     class Abstract
> > >     {
> > >     }
> > >
> > >     // or:
> > >
> > >     namespace Zend\Controller\Dispatcher;
> > >
> > >     interface Interface
> > >     {
> > >     }
> > >
> > > we'll run into issues.
> > >
> > > Second, and less obvious, is that perhaps the easiest solution breaks
> one
> > > of the
> > > key principles of namespaces (which are designed to help encapsulate
> > > components). This one's harder to explain, so let's look at examples.
> > > Consider a
> > > component such as Zend_Controller_Request. The simplest solution would
> be
> > > to
> > > name the abstract class or interface Zend\Controller\Request, and then
> > > have the
> > > various concrete implementations under that namespace:
> > >
> > >     namespace Zend\Controller;
> > >
> > >     interface Request
> > >     {
> > >     }
> > >
> > >     // and concrete ones:
> > >
> > >     namespace Zend\Controller\Request;
> > >
> > >     class Http
> > >     {
> > >     }
> > >
> > > What's the problem here? The interface is not in the same namespace as
> > the
> > > concrete implementations.
> > >
> > > Potential solutions and recommendation
> > > ======================================
> > > So, how should Zend Framework "solve" these issues? A number of
> proposals
> > > and
> > > recommendations have been floated around, both within ZF circles and in
> > > the
> > > greater PHP community.
> > >
> > > Considerations include:
> > >
> > >  * Avoiding the use of PHP reserved keywords (already noted).
> > >  * Avoiding Hungarian Notation (i.e., having the name or a portion of
> the
> > > name
> > >    describe its type -- which, to a degree, the current naming
> > conventions
> > >    already violate). (See
> > http://en.wikipedia.org/wiki/Hungarian_Notation,
> > > the
> > >    sections "Disadvantages of Systems Hungarian" and "Notable Opinions"
> > > for some
> > >    of the arguments against using Hungarian Notation.)
> > >
> > > Approaches that have been considered include:
> > >
> > >  * Using 'I' to prefix interfaces. This derives from standards in other
> > >    programming languages (.Net and python, in particular). This is just
> > > another
> > >    form of Hungarian Notation, however.
> > >
> > >  * Using "Interface" or "Abstract" as a class name suffix:
> > > RequestInterface,
> > >    RequestAbstract. Again, however this is Hungarian Notation.
> > >
> > >  * Using the term "Base" for abstract classes: BaseRequest,
> RequestBase,
> > > Base.
> > >    This is just substituting the word Base for Abstract, however, and
> is
> > > really
> > >    not much different than the above.
> > >
> > >  * Use generic, descriptive names indicative of functionality or
> > behavior.
> > > As
> > >    examples from the SPL, "Countable", "Iterator", "ArrayObject".
> > >
> > > My recommendation is to use the latter, as it solves all
> considerations.
> > > It will
> > > take more thought when naming, but will ensure that components can live
> > in
> > > a
> > > self-contained namespace, do not use reserved keywords, and avoid
> > > Hungarian
> > > Notation.
> > >
> > > Plan for implementation
> > > =======================
> > > I recommend that the Coding Standards documentation be updated to
> reflect
> > > this
> > > approach.
> > >
> > > All new components going into 1.8 and onwards should adopt these
> > > standards. In
> > > releases 1.9 and forward, we will begin migrating existing
> > > interfaces/abstract
> > > classe. First, new classes/interfaces will be created that follow these
> > > conventions and which extend the originals; later, any type-hinting
> based
> > > on the
> > > original class/interface names will be updated to point to the new
> names;
> > > and
> > > finally, in 2.0, we will remove the old interfaces/abstract classes
> > > entirely.
> > >
> > > --
> > > Matthew Weier O'Phinney
> > > Software Architect      | [email-masked]
> > > Zend Framework          | http://framework.zend.com/
> >
> >
> > ----- End forwarded message -----
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> >
>
> --
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--001485f791ce0d11f20467498926
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

&quot;There have been a TON of debates amongst ZF contributors about naming=
,<br>and making the names meaningful. I would expect that this proposal wou=
ld<br>probably be very welcome to those individuals. (Matt R., I&#39;m look=
ing at<br>
you...)&quot;<div><br></div><div>Meaningful names are great! =C2=A0It just =
depends on what you mean by &quot;meaningful&quot;. =C2=A0For me, it mean c=
learly communicating the role of a class, so that users can instantly deter=
mine how classes are interrelated, even if they&#39;re navigating the code =
online. =C2=A0Right now we have that: it is clear that Zend_Controller_Requ=
est_Http extends Zend_Controller_Request_Abstract, even before you open eit=
her, and even if you aren&#39;t using an IDE. =C2=A0Zend_Controller_Request=
_Http extending Zend_Controller_Request would also communicate that. =C2=A0=
I would like to retain that quality of the file organization.</div>
<div><br></div><div>With the following names...</div><div><br></div><div>=
=C2=A0* Zend\Controller\Request\RequestEnvironment, RequestObject<br>=C2=A0=
 =C2=A0(interface, abstract)<br>=C2=A0* Zend\Controller\Response\ResponsePa=
yload, ResponseObject<br>
=C2=A0 =C2=A0(interface, abstract)<br>=C2=A0* Zend\Controller\Dispatcher\Di=
spatchMapper (interface)</div><div><br></div><div>...excepting this one...<=
/div><div><br>=C2=A0* Zend\Validate\Validatible, Validator (interface, abst=
ract)</div><div>
<br></div><div>...it is not really apparent what relates to what. =C2=A0Req=
uestEnvironment does not communicate Interface to me, and RequestObject doe=
s not communicate abstract. =C2=A0While you may say that that&#39;s irrelev=
ant because we have IDEs, I would say that these names have the potential t=
o be more confusing, because there are no rules for how environments and ob=
jects and payloads and mappers are related. =C2=A0If I&#39;m looking to ext=
end one of these classes (which happens frequently), I have to study a few =
classes to figure out how everything interacts. =C2=A0Today I can open the =
abstract or interface and get right to work.</div>
<div><br></div><div>One other thing. =C2=A0There are going to be cases wher=
e these names are going to be really awkward. =C2=A0One of the great things=
 about frameworks in general is that they remove choices so that you can fo=
cus on getting the job done. =C2=A0IRequest, IResponse--there is no thought=
 required for these names. =C2=A0But in the other scenario contributors mus=
t determine whether RequestEnvironment, RequestObject, Requestable, or what=
ever most effectively communicates its role.</div>
<div><br></div><div>If we go this route, I also think we&#39;re going to en=
d up standardizing on some things simply in an effort to avoid the above. =
=C2=A0I think Object will become a stand-in for Abstract, for example (Requ=
estObject). =C2=A0I think standardization of this kind results in a clear A=
PI, but in effect, it is a form of limited Hungarian notation through the b=
ack door. =C2=A0If we are ultimately going to go that route, we should just=
 do it up front. =C2=A0Honestly, I would even be OK with AbstractRequest an=
d RequestInterface, although I know you would hate that idea. =C2=A0:-)</di=
v>
<div><br></div><div>-Matt</div><div><br><div class=3D"gmail_quote">On Fri, =
Apr 10, 2009 at 4:13 PM, Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;=
<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">-- Matthew Weier O&#39;Phinney &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote<br>
(on Friday, 10 April 2009, 04:39 PM -0400):<br>
<div class=3D"im">&gt; Forwarding from Ben, who intended to copy the list..=
.<br>
&gt;<br>
&gt; ----- Forwarded message from Benjamin Eberlei &lt;<a href=3D"mailto:ko=
[email-masked]">[email-masked]</a>&gt; -----<br>
&gt;<br>
&gt; From: Benjamin Eberlei &lt;<a href=3D"mailto:[email-masked]">kont=
[email-masked]</a>&gt;<br>
&gt; To: Matthew Weier O&#39;Phinney &lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt;<br>
&gt; Date: Fri, 10 Apr 2009 18:58:02 +0000<br>
&gt; Subject: Re: [zf-contributors] Proposal to update Abstract/Interface N=
aming<br>
&gt; =C2=A0 =C2=A0 =C2=A0 Conventions<br>
&gt;<br>
&gt;<br>
&gt; moving to this new namespace implementation and breaking all old ones =
is a<br>
&gt; serious BC,<br>
&gt; so why do we only allow slight changes for everything else? I thought =
we<br>
&gt; would just go to &quot;change the serious technical debt, but as BC as=
<br>
&gt; possible&quot;, changing the name of an interface is the exact differe=
nce of<br>
&gt; that.<br>
<br>
</div>It is, but we&#39;re going to need to do it once we move to namespace=
s<br>
anyways -- because our CS were written before namespaces were even<br>
proposed for inclusion in PHP.<br>
<br>
This is also why I propose the gradual changes over a series of<br>
versions. This allows us to provide migration instructions that users<br>
can gradually implement, making their code more future-proof. If the<br>
new versions of the interfaces and abstract classes extend the<br>
originals, there is no BC break until we finally drop the old classes --<br=
which, as I mentioned, will not happen until 2.0.<br>
<div class=3D"im"><br>
&gt; additionally, the generic name one seems strange in my eyes. How would=
 you<br>
&gt; do that for<br>
&gt; the example of request, response, dispatcher? Validation interface?<br=
<br>
</div>First off, the request and response objects need interfaces, and then=
<br>
potentially abstract implementations. Either way, this is easy:<br>
<br>
 =C2=A0* Zend\Controller\Request\RequestEnvironment, RequestObject<br>
 =C2=A0 =C2=A0(interface, abstract)<br>
 =C2=A0* Zend\Controller\Response\ResponsePayload, ResponseObject<br>
 =C2=A0 =C2=A0(interface, abstract)<br>
 =C2=A0* Zend\Controller\Dispatcher\DispatchMapper (interface)<br>
 =C2=A0* Zend\Validate\Validatible, Validator (interface, abstract)<br>
<br>
The names take a little creativity, but they also make it clearer in<br>
your code what you&#39;re doing:<br>
<br>
 =C2=A0 =C2=A0namespace Zend\Controller\Request;<br>
<br>
 =C2=A0 =C2=A0class HttpEnvironment implements RequestEnvironment<br>
 =C2=A0 =C2=A0{<br>
 =C2=A0 =C2=A0}<br>
<br>
 =C2=A0 =C2=A0// or<br>
 =C2=A0 =C2=A0namespace Zend\Validate;<br>
<br>
 =C2=A0 =C2=A0class Alpha extends Validator<br>
 =C2=A0 =C2=A0{<br>
<div class=3D"im"> =C2=A0 =C2=A0}<br>
<br>
&gt; i don&#39;t seem to find good ones. ResponseObject, RequestObject,<br>
&gt; Validatable are ok, but from the typehints its very hard to suggest<br=
&gt; that these are interfaces in contrast to concrete implementation.<br>
<br>
</div>Typehints should typically be to interfaces anyways...<br>
<div class=3D"im"><br>
&gt; furthermore, why break with the ways of java, python, and .net? this i=
s<br>
&gt; what many programmers are used to.<br>
<br>
</div>Because Java and .Net are strongly typed languages, and PHP isn&#39;t=
.<br>
Because just because a convention worked for one language doesn&#39;t mean<=
br>
it&#39;s appropriate for another. Because PHP is not Java, is not Python, i=
s<br>
not .NET.<br>
<br>
There have been a TON of debates amongst ZF contributors about naming,<br>
and making the names meaningful. I would expect that this proposal would<br=
probably be very welcome to those individuals. (Matt R., I&#39;m looking at=
<br>
you...)<br>
<div class=3D"im"><br>
&gt; As a last point, having implementation and interface in different<br>
&gt; packages is actually the single most important issue about having an<b=
r>
&gt; interface anyways and a huge benefit for object oriented design. =C2=
=A0this<br>
&gt; separates the concerns and reduces dependencies, so I would love to<br=
&gt; see this in a 2.0 version.<br>
<br>
</div>There&#39;s a difference between using an interface in userland code,=
 and<br>
using one within a framework or library. In your userland code, you<br>
*will* have the interface in a different package:<br>
<br>
 =C2=A0 =C2=A0namespace Foo\Controller\Request;<br>
 =C2=A0 =C2=A0import Zend\Controller\Request as ZfRequest;<br>
<br>
 =C2=A0 =C2=A0CustomHttpRequest extends ZfRequest\HttpEnvironment<br>
 =C2=A0 =C2=A0{<br>
 =C2=A0 =C2=A0}<br>
<br>
*Within* the framework, it&#39;s better for them to be in the same<br>
namespace, to allow selectively packaging components for distribution or<br=
deployment.<br>
<div class=3D"im"><br>
&gt; That is what i am greatly missing in ZF, that for example the<br>
&gt; controller is implemented with several very large abstract classes<br>
&gt; only and the dependencies are so hard-wired that its impossible to<br>
&gt; exchange just one part of the controller to add specific functionality=
<br>
&gt; without having to change considerable other parts also.<br>
<br>
</div>This has nothing to do with naming conventions, and is a topic we<br>
already plan to address for (or before) 2.0. (Please search for<br>
&quot;Zend_Controller 2.0&quot; on the wiki for some of the plans.)<br>
<div><div></div><div class=3D"h5"><br>
&gt; On Fri, 10 Apr 2009 14:24:34 -0400, Matthew Weier O&#39;Phinney<br>
&gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote=
:<br>
&gt; &gt; Greetings, all --<br>
&gt; &gt;<br>
&gt; &gt; Below is a proposal I am making to modify the Zend Framework Codi=
ng<br>
&gt; &gt; Standards conventions for the naming of Interfaces and Abstract c=
lasses.<br>
&gt; &gt;<br>
&gt; &gt; This decision is basically already made, but I&#39;d appreciate a=
ny feedback<br>
&gt; &gt; that you may have on the matter.<br>
&gt; &gt;<br>
&gt; &gt; Thanks!<br>
&gt; &gt;<br>
&gt; &gt; The problem<br>
&gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; &gt; PHP 5.3 introduces namespaces to the PHP language. While this won=
&#39;t have<br>
&gt; &gt; an<br>
&gt; &gt; impact much on userland code, it will have an impact on library a=
nd<br>
&gt; &gt; framework<br>
&gt; &gt; code, as it provides a useful paradigm for organizing components =
as well<br>
&gt; &gt; as<br>
&gt; &gt; simplifying syntax. Instead of having to say things like:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 $analyzer =3D new<br>
&gt; Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();<br>
&gt; &gt;<br>
&gt; &gt; we can instead do something like this:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 namespace Zend\Search\Lucene\Analysis\Analyzer;<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 $analyzer =3D new Common_TextNum();<br>
&gt; &gt;<br>
&gt; &gt; or even:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 namespace Zend\Search\Lucene\Analysis\Analyzer;<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 class Common_TextNum extends Common<br>
&gt; &gt; =C2=A0 =C2=A0 {<br>
&gt; &gt; =C2=A0 =C2=A0 }<br>
&gt; &gt;<br>
&gt; &gt; The problem that arises for Zend Framework has to do with how we =
name<br>
&gt; &gt; abstract<br>
&gt; &gt; classes and interfaces. Currently, the final segment of such clas=
ses are<br>
&gt; &gt; expected to end with _Abstract and _Interface, respectively. This=
 will<br>
&gt; not<br>
&gt; &gt; work<br>
&gt; &gt; when we migrate to utilize namespaces, for two reasons.<br>
&gt; &gt;<br>
&gt; &gt; First, and most obviously, &#39;abstract&#39; and &#39;interface&=
#39; are reserved PHP<br>
&gt; &gt; keywords.<br>
&gt; &gt; As such, in situations such as the following:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 namespace Zend\Controller\Request;<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 class Abstract<br>
&gt; &gt; =C2=A0 =C2=A0 {<br>
&gt; &gt; =C2=A0 =C2=A0 }<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 // or:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 namespace Zend\Controller\Dispatcher;<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 interface Interface<br>
&gt; &gt; =C2=A0 =C2=A0 {<br>
&gt; &gt; =C2=A0 =C2=A0 }<br>
&gt; &gt;<br>
&gt; &gt; we&#39;ll run into issues.<br>
&gt; &gt;<br>
&gt; &gt; Second, and less obvious, is that perhaps the easiest solution br=
eaks one<br>
&gt; &gt; of the<br>
&gt; &gt; key principles of namespaces (which are designed to help encapsul=
ate<br>
&gt; &gt; components). This one&#39;s harder to explain, so let&#39;s look =
at examples.<br>
&gt; &gt; Consider a<br>
&gt; &gt; component such as Zend_Controller_Request. The simplest solution =
would be<br>
&gt; &gt; to<br>
&gt; &gt; name the abstract class or interface Zend\Controller\Request, and=
 then<br>
&gt; &gt; have the<br>
&gt; &gt; various concrete implementations under that namespace:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 namespace Zend\Controller;<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 interface Request<br>
&gt; &gt; =C2=A0 =C2=A0 {<br>
&gt; &gt; =C2=A0 =C2=A0 }<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 // and concrete ones:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 namespace Zend\Controller\Request;<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 class Http<br>
&gt; &gt; =C2=A0 =C2=A0 {<br>
&gt; &gt; =C2=A0 =C2=A0 }<br>
&gt; &gt;<br>
&gt; &gt; What&#39;s the problem here? The interface is not in the same nam=
espace as<br>
&gt; the<br>
&gt; &gt; concrete implementations.<br>
&gt; &gt;<br>
&gt; &gt; Potential solutions and recommendation<br>
&gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; &gt; So, how should Zend Framework &quot;solve&quot; these issues? A n=
umber of proposals<br>
&gt; &gt; and<br>
&gt; &gt; recommendations have been floated around, both within ZF circles =
and in<br>
&gt; &gt; the<br>
&gt; &gt; greater PHP community.<br>
&gt; &gt;<br>
&gt; &gt; Considerations include:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0* Avoiding the use of PHP reserved keywords (already noted)=
.<br>
&gt; &gt; =C2=A0* Avoiding Hungarian Notation (i.e., having the name or a p=
ortion of the<br>
&gt; &gt; name<br>
&gt; &gt; =C2=A0 =C2=A0describe its type -- which, to a degree, the current=
 naming<br>
&gt; conventions<br>
&gt; &gt; =C2=A0 =C2=A0already violate). (See<br>
&gt; <a href=3D"http://en.wikipedia.org/wiki/Hungarian_Notation" target=3D"=
_blank">http://en.wikipedia.org/wiki/Hungarian_Notation</a>,<br>
&gt; &gt; the<br>
&gt; &gt; =C2=A0 =C2=A0sections &quot;Disadvantages of Systems Hungarian&qu=
ot; and &quot;Notable Opinions&quot;<br>
&gt; &gt; for some<br>
&gt; &gt; =C2=A0 =C2=A0of the arguments against using Hungarian Notation.)<=
br>
&gt; &gt;<br>
&gt; &gt; Approaches that have been considered include:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0* Using &#39;I&#39; to prefix interfaces. This derives from=
 standards in other<br>
&gt; &gt; =C2=A0 =C2=A0programming languages (.Net and python, in particula=
r). This is just<br>
&gt; &gt; another<br>
&gt; &gt; =C2=A0 =C2=A0form of Hungarian Notation, however.<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0* Using &quot;Interface&quot; or &quot;Abstract&quot; as a =
class name suffix:<br>
&gt; &gt; RequestInterface,<br>
&gt; &gt; =C2=A0 =C2=A0RequestAbstract. Again, however this is Hungarian No=
tation.<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0* Using the term &quot;Base&quot; for abstract classes: Bas=
eRequest, RequestBase,<br>
&gt; &gt; Base.<br>
&gt; &gt; =C2=A0 =C2=A0This is just substituting the word Base for Abstract=
, however, and is<br>
&gt; &gt; really<br>
&gt; &gt; =C2=A0 =C2=A0not much different than the above.<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0* Use generic, descriptive names indicative of functionalit=
y or<br>
&gt; behavior.<br>
&gt; &gt; As<br>
&gt; &gt; =C2=A0 =C2=A0examples from the SPL, &quot;Countable&quot;, &quot;=
Iterator&quot;, &quot;ArrayObject&quot;.<br>
&gt; &gt;<br>
&gt; &gt; My recommendation is to use the latter, as it solves all consider=
ations.<br>
&gt; &gt; It will<br>
&gt; &gt; take more thought when naming, but will ensure that components ca=
n live<br>
&gt; in<br>
&gt; &gt; a<br>
&gt; &gt; self-contained namespace, do not use reserved keywords, and avoid=
<br>
&gt; &gt; Hungarian<br>
&gt; &gt; Notation.<br>
&gt; &gt;<br>
&gt; &gt; Plan for implementation<br>
&gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D<br>
&gt; &gt; I recommend that the Coding Standards documentation be updated to=
 reflect<br>
&gt; &gt; this<br>
&gt; &gt; approach.<br>
&gt; &gt;<br>
&gt; &gt; All new components going into 1.8 and onwards should adopt these<=
br>
&gt; &gt; standards. In<br>
&gt; &gt; releases 1.9 and forward, we will begin migrating existing<br>
&gt; &gt; interfaces/abstract<br>
&gt; &gt; classe. First, new classes/interfaces will be created that follow=
 these<br>
&gt; &gt; conventions and which extend the originals; later, any type-hinti=
ng based<br>
&gt; &gt; on the<br>
&gt; &gt; original class/interface names will be updated to point to the ne=
w names;<br>
&gt; &gt; and<br>
&gt; &gt; finally, in 2.0, we will remove the old interfaces/abstract class=
es<br>
&gt; &gt; entirely.<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Matthew Weier O&#39;Phinney<br>
&gt; &gt; Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:matthe=
[email-masked]">[email-masked]</a><br>
&gt; &gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"htt=
p://framework.zend.com/" target=3D"_blank">http://framework.zend.com/</a><b=
r>
&gt;<br>
&gt;<br>
&gt; ----- End forwarded message -----<br>
&gt;<br>
&gt; --<br>
&gt; Matthew Weier O&#39;Phinney<br>
&gt; Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:matthew@zen=
d.com">[email-masked]</a><br>
&gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://f=
ramework.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt;<br>
<br>
</div></div>--<br>
<div><div></div><div class=3D"h5">Matthew Weier O&#39;Phinney<br>
Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:[email-masked]=
">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
</div></div></blockquote></div><br></div>

--001485f791ce0d11f20467498926--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 08 Oct 2009 15:40:44 -0500
From: Ralph Schindler <[email-masked]>
To: "Whitcraft, Jon" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: [zf-contributors] Code Review

Ok, I'm gonna throw out something I've been thinking for a while.

I think we should have a list of projects, sites, and dedicated 
contributors (it can be a google spreadsheet for that matter) that have 
no problem keeping their project up to date with the latest ZF branch 
version.  What this would allow us to do is say "here is the latest zf 
1.9.x, please try it in your project".  Then, we have at least 5 days 
where we collect feedback before actually publishing the version.  This 
will provide us with plenty enough time to catch any 
unknown/undocumented usage case breaks.

Having more time between the actual building of a release package, and 
the actual publishing of that release package.  Perhaps we call it a 
ReleaseCandidate, but if we do, we at least have to alert the 
aforementioned list that we'd like them to try it out on their project.

Call this "QA from the field".

-ralph

Whitcraft, Jon wrote:
> Hello,
> 
>  
> 
> I have been thinking about the problem that ZF ran into right after 
> 1.9.3 was release a few weeks ago and then we had to rush a 1.9.3pl1 
> into release.  Would using a tool such as Crucible from Atlassian help 
> with this problem?
> 
>  
> 
> What does everyone else think?
> 
>  
> 
> http://www.whitcraftconsulting.com/images/php5_zce_logo_new.gif 
> <http://zend.com/zce.php?c=ZEND002524&r=219549271>
> 
> 	
> 
> Jon Whitcraft
> Indianapolis Motor Speedway
> [email-masked] <mailto:[email-masked]>
> 
> P: (317) 492-8623 - F: (317) 492-6419
> 
> 
>  
> 
> 
> ********************
> ********************
> This E-mail (and attachments) may contain confidential/privileged 
> information intended only for the named addressee(s). If you are not an 
> intended recipient, do not read, copy, disseminate or take any action 
> based on the content of this E-mail. Please notify the sender by reply 
> E-mail and erase this E-mail from your system. Your assistance is 
> appreciated. E-mail transmission may not be secure or error-free. The 
> company is not responsible for any loss/damage arising from any virus 
> transmitted.
> ********************
> ********************

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 7 Dec 2009 08:34:12 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Nico Edtinger <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

--0-1986206263-1260203652=:74194
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>I'm missing the most important thing: write a unit =0Atest with known atta=
ck vectors. If I'd want an improvement as important =0Aas security I'd writ=
e a unit test to prove that it works (or fails). =0A>Putting the burden on =
someone else by hiding testable examples in a blog post or email leaves a b=
ad aftertaste.=0A=0AI apologise for exposing the stupidity of relying on Ze=
nd_Filter_StripTags to prevent XSS, or even, like, strip tags. Truly. Sorry=
.=0A=0ANow read the blog and see where I three frigging times make it absol=
utely clear that at the time I wrote this I did NOT consider this a securit=
y issue for the Zend Framework. I am ENTITLED to change my mind after over =
a day of discussing it which is exactly what I did. In the future, however,=
 I will keep my mouth shut. When I see something wrong, I will remain silen=
t.=0A=0AYeah, like that will happen...:P. I rant - live with it.=0A=0APaddy=
=0A=0A=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www=
.survivethedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=
=0A=0A=0A=0A=0A________________________________=0AFrom: Nico Edtinger <zf-c=
[email-masked]>=0ATo: P=E1draic Brady <[email-masked]>=
=0ASent: Mon, December 7, 2009 4:10:04 PM=0ASubject: Re: [zf-contributors] =
XSS And Malformed HTML Vulnerabilities In Zend_Filter_StripTags=0A=0A=0AAm =
07.12.2009 um 15:26 schrieb P=E1draic Brady:=0AI would also suggest the fol=
lowing:=0A>=0A>a) Rework the filter's current four lines of documentation (=
http://framework.zend.com/manual/en/zend.filter.set.html#zend.filter.set.st=
riptags) to cover the component in greater detail clarifying its use cases,=
 potential for misuse, and clarifying it is not XSS  or malformed HTML safe=
.=0A>b) Immediately deprecate in 1.9 branch (and remove in 2.0 - preferably=
 1.10 given its significance) its ability to flexibly allow some HTML/comme=
nts thus preserving its only truly worthwhile feature - stripping ALL HTML.=
=0A>c) Do this ASAP.=0A>=0A=0AI'm missing the most important thing: write a=
 unit test with known attack vectors. If I'd want an improvement as importa=
nt as security I'd write a unit test to prove that it works (or fails). Put=
ting the burden on someone else by hiding testable examples in a blog post =
or email leaves a bad aftertaste.=0A=0Anico
--0-1986206263-1260203652=:74194
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">&gt;I'm missing the most important thing: write a unit =0Atest=
 with known attack vectors. If I'd want an improvement as important =0Aas s=
ecurity I'd write a unit test to prove that it works (or fails). =0A<br>&gt=
;Putting the burden on someone else by hiding testable examples in a blog=
=0A post or email leaves a bad aftertaste.<br><br>I apologise for exposing =
the stupidity of relying on Zend_Filter_StripTags to prevent XSS, or even, =
like, strip tags. Truly. Sorry.<br><br>Now read the blog and see where I th=
ree frigging times make it absolutely clear that at the time I wrote this I=
 did NOT consider this a security issue for the Zend Framework. I am ENTITL=
ED to change my mind after over a day of discussing it which is exactly wha=
t I did. In the future, however, I will keep my mouth shut. When I see some=
thing wrong, I will remain silent.<br><br>Yeah, like that will happen...:P.=
 I rant - live with it.<br><br>Paddy<br><br><br><div>&nbsp;</div><span styl=
e=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: times new roman,ne=
w york,times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1drai=
c Brady<br><br></span></font><span style=3D"font-style: italic;"><font styl=
e=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><a rel=
=3D"nofollow"
 target=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blog.astrum=
futura.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.=
survivethedeepend.com">http://www.survivethedeepend.com</a><br><a rel=3D"no=
follow" target=3D"_blank" href=3D"http://www.openideurope.eu/">OpenID Europ=
e Foundation Irish Representative</a><br></font></span></span><div><br></di=
v><div style=3D"font-family: times new roman,new york,times,serif; font-siz=
e: 12pt;"><br><div style=3D"font-family: times new roman,new york,times,ser=
if; font-size: 12pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><s=
pan style=3D"font-weight: bold;">From:</span></b> Nico Edtinger &lt;zf-cont=
[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">To:</s=
pan></b> P=E1draic Brady &lt;[email-masked]&gt;<br><b><span style=
=3D"font-weight: bold;">Sent:</span></b> Mon, December 7, 2009 4:10:04 PM<b=
r><b><span style=3D"font-weight: bold;">Subject:</span></b> Re: [zf-contrib=
utors] XSS And Malformed HTML
 Vulnerabilities In Zend_Filter_StripTags<br></font><br>=0A<meta http-equiv=
=3D"x-dns-prefetch-control" content=3D"off"><base><div><div>Am 07.12.2009 u=
m 15:26 schrieb P=E1draic Brady:</div><blockquote type=3D"cite"><span class=
=3D"Apple-style-span" style=3D"border-collapse: separate; font-family: Helv=
etica; font-size: medium; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text=
-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-sp=
acing: 0px;"><div><div style=3D"margin: 0px; font-family: 'times new roman'=
,'new york',times,serif; font-size: 12pt;">I would also suggest the followi=
ng:<br><br><span><span>a) Rework the filter's current four lines of documen=
tation (<a target=3D"_blank" href=3D"http://framework.zend.com/manual/en/ze=
nd.filter.set.html#zend.filter.set.striptags">http://framework.zend.com/man=
ual/en/zend.filter.set.html#zend.filter.set.striptags</a>) to cover the com=
ponent in greater detail clarifying its use cases, potential for
 misuse, and clarifying it is not XSS&nbsp; or malformed HTML safe.</span><=
/span><br>b) Immediately deprecate in 1.9 branch (and remove in 2.0 - prefe=
rably 1.10 given its significance) its ability to flexibly allow some HTML/=
comments thus preserving its only truly worthwhile feature - stripping ALL =
HTML.<br>c) Do this ASAP.<font class=3D"Apple-style-span" color=3D"#000000"=
 face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"font-size: me=
dium;"><font class=3D"Apple-style-span" color=3D"#144fae" face=3D"'times ne=
w roman', 'new york', times, serif" size=3D"4"><span class=3D"Apple-style-s=
pan" style=3D"font-size: 16px;"><br></span></font></span></font></div></div=
></span></blockquote><br></div><div>I'm missing the most important thing: w=
rite a unit test with known attack vectors. If I'd want an improvement as i=
mportant as security I'd write a unit test to prove that it works (or fails=
). Putting the burden on someone else by hiding testable examples in a blog=
 post or email
 leaves a bad aftertaste.</div><div><br></div><div>nico</div><meta http-equ=
iv=3D"x-dns-prefetch-control" content=3D"on"></div></div>=0A<!-- cg2.c902.m=
ail.ac4.yahoo.com compressed/chunked Mon Dec  7 03:29:14 PST 2009 -->=0A</d=
iv></body></html>
--0-1986206263-1260203652=:74194--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 5 Jul 2009 12:22:25 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Two Proposals Ready for Review

--0-291157178-1246821745=:55641
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

How far away is a 2.0 release? It seems reasonable to assume the current re=
lease frequency will continue until 2.0 is ready for release. Even then, th=
ere is scope for fixing 1.x release bugs and security issues into the futur=
e. I always assumed we'd see 1.11, 1.12, ..., 1.34 until support was offici=
ally ended for 1.x. Matthew stated a few weeks ago to another query that 2.=
0 was in early planning.=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.=
astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundat=
ion Irish Representative=0A=0A=0A=0A=0A=0A________________________________=
=0AFrom: Ralf Eggert <[email-masked]>=0ATo: Benjamin Eberlei <kontakt=
@beberlei.de>=0ACc: [email-masked]=0ASent: Sunday, July 5, =
2009 4:56:21 PM=0ASubject: Re: [zf-contributors] Two Proposals Ready for Re=
view=0A=0AThanks Benjamin,=0A=0ABenjamin Eberlei schrieb am 05.07.2009 17:3=
1:=0A> to my knowledge there will definately be a 1.10, and even a slight c=
hance that =0A> there will be a 1.11=0A=0AOk, but will 2.0 be published aft=
er 1.10 or 1.11. or will be both major=0Arelease be managed parallel?=0A=0A=
Thanks and best regards,=0A=0ARalf=0A
--0-291157178-1246821745=:55641
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">How far away is a 2.0 release? It seems reasonable to assume t=
he current release frequency will continue until 2.0 is ready for release. =
Even then, there is scope for fixing 1.x release bugs and security issues i=
nto the future. I always assumed we'd see 1.11, 1.12, ..., 1.34 until suppo=
rt was officially ended for 1.x. Matthew stated a few weeks ago to another =
query that 2.0 was in early planning.<br><br>Paddy<br><div>&nbsp;</div><spa=
n style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: times new ro=
man,new york,times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=
=E1draic Brady<br><br></span></font><span style=3D"font-style: italic;"><fo=
nt style=3D"font-family: times new roman,new york,times,serif;" size=3D"3">=
<a rel=3D"nofollow" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font =
size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><span style=3D"font-weight: bo=
ld;">From:</span></b> Ralf Eggert &lt;[email-masked]&gt;<br><b><span =
style=3D"font-weight: bold;">To:</span></b> Benjamin Eberlei &lt;kontakt@be=
berlei.de&gt;<br><b><span style=3D"font-weight: bold;">Cc:</span></b> zf-co=
[email-masked]<br><b><span style=3D"font-weight: bold;">Sent:</s=
pan></b> Sunday, July 5, 2009 4:56:21 PM<br><b><span style=3D"font-weight: =
bold;">Subject:</span></b>
 Re: [zf-contributors] Two Proposals Ready for Review<br></font><br>=0AThan=
ks Benjamin,<br><br>Benjamin Eberlei schrieb am 05.07.2009 17:31:<br>&gt; t=
o my knowledge there will definately be a 1.10, and even a slight chance th=
at <br>&gt; there will be a 1.11<br><br>Ok, but will 2.0 be published after=
 1.10 or 1.11. or will be both major<br>release be managed parallel?<br><br=
>Thanks and best regards,<br><br>Ralf<br></div></div></div></body></html>
--0-291157178-1246821745=:55641--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 17:21:29 -0800
From: Christoph Dorn <[email-masked]>
Reply-To: [email-masked]
To: Tommy Smith <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

Tommy Smith wrote:
> I have nothing of value to add - but, I want to say that being on this 
> mailing list is super educational! 
>
> Here at the office, developers make the svn/git arguments daily. My 
> argument arsenal in this battle (and many others) gets filled by all 
> of the emails that flow through this mailing list.
>
> Thanks for making me smarter everybody!
More inspiration: http://nvie.com/git-model

Christoph

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 20 Mar 2009 14:10:10 -0700
From: "Wil Sinclair" <[email-masked]>
To: "till" <[email-masked]>
Cc: "Thomas Weidner" <[email-masked]>, <[email-masked]>
Subject: RE: [zf-contributors] Release Policies and Conventions

You can add new API's and new features that don't affect API's much in
mini releases. They have to be BC, however. I'm pretty sure that's
called out in the document, but let me know if it's not.

Thanks.
,Wil

-----Original Message-----
From: till [mailto:[email-masked]]=20
Sent: Friday, March 20, 2009 2:07 PM
To: Wil Sinclair
Cc: Thomas Weidner; [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

What if I added a "feature" to an existing component.

I mean, from what I understand -- the mini releases shouldn't break BC
-- that's all. But if I add to the api that's allowed? (asking)

On Fri, Mar 20, 2009 at 10:02 PM, Wil Sinclair <[email-masked]> wrote:
> OK, I changed it. There will inevitably be some hand-waving around
what
> is a new feature and what is a functionality enhancement. I'd rather
> confine this thread to the issue of release policies and conventions.
:)
>
> New components pretty clearly fall under the category of 'new
features'
> in my mind. If others are confused, we should further clarify it.
>
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 1:42 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> "A mini release may contain only bug fixes. Note that no new features
or
> API
> changes are allowed whatsoever."
>
> This sentence could imply that new features are not allowed, but
> improvments
> of existing features are allowed as long as they don't change existing
> API.
> The word "only" could be overseen.
>
> The question is also what's for us the difference between a feature
> enhancement and a new feature.
> Feature Enhancement could be for example to add a new option. It would
> not
> change API. So a textual clearification would be great :-)
>
> Also to note: Are new components allowed within minor releases or only
> within major releases? Should also be defined.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>;
> <[email-masked]>
> Sent: Friday, March 20, 2009 9:31 PM
> Subject: RE: [zf-contributors] Release Policies and Conventions
>
>
> Hey Thomas, I'm not quite sure what you are referring to. Your
> understanding is correct, and the wiki page seems to reflect it
> perfectly. Can you tell me exactly what needs to be updated? Maybe
with
> the string that you're referring to?
>
> Thanks.
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 12:57 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> In my understanding also "feature enhancements" are actually not
allowed
> to
> be integrated within mini-releases.
> Only "Bug fixes" which do not add additional API are allowed.
>
> Maybe you should also add a definition for what's a bug fix, a
> improvement
> and a new feature to get that also defined, and we can all speak of
the
> same
> in future.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, March 20, 2009 8:47 PM
> Subject: [zf-contributors] Release Policies and Conventions
>
>
> Over the 2 years that I've been involved with the project, there have
> been many questions about what can go in to a given release and if
there
> are any guidelines for the release schedules. While many of you have
> pieced the picture together from different mails, IRC chats, etc. I've
> owed you a document for a long time now. Here it is:
>
>
>
>
http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
> tions
>
>
>
> I ask all contributors to review this and reply with any question or
> edits- especially if I missed something- in this forum.
>
>
>
> As always, thanks for all the time and effort. Also, go 1.8!
>
>
>
> ,Wil
>
>

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 07 Feb 2010 00:49:56 +0100
From: Maghiel Dijksman <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] New Proposal: Change of
	ZendX_JQuery_View_Helper_AjaxLink
	(ZendX_JQuery_View_Helper_AjaxRequest etc)

This is my first idea for a proposal that i submit to the mailing list, 
so pardon me if i take the wrong steps
(and please correct me ;))

I think it's a bit, ehm, weird that theres Zend_View_Helper_Url, which 
returns a url as string,
and ZendX_JQuery_View_Helper_AjaxLink, which can only return a complete 
HTML hyperlink (although
the naming DOES cleary state what you get).

But what if a user wants to only have the JQuery function declaration 
returned as string, by example
for usage in a onclick attribute of an element? 
ZendX_JQuery_View_Helper_AjaxLink has the inline option,
but this makes the helper return a hyperlink with the function declared 
in the onclick attribute of that hyperlink.
So the only option the user has in my use case is to either create 
his/her own view helper, or declare the function
him/herself in the view.

So I thought the following might be useful:
Drop: ZendX_JQuery_View_Helper_AjaxLink
Add:
ZendX_JQuery_View_Helper_AjaxRequest_Abstract
ZendX_JQuery_View_Helper_AjaxRequest (probably needs a better name :p)
ZendX_JQuery_View_Helper_AjaxRequest_Link

Something like:
abstract class ZendX_JQuery_View_Helper_AjaxRequest_Abstract
     extends Zend_View_Helper_HtmlElement
{
     protected $_jQuery;
     protected $_jQHandler;

     /**
      * Set JQuery view helper and JQuery Handler
      */
     public function __construct()
     {
         $this->_jQuery = $this->view->jQuery();
         $this->_jQuery->enable();

         $this->_jQHandler = true === 
ZendX_JQuery_View_Helper_JQuery::getNoConflictMode() ? '$j' : '$';
     }

     /**
      * Get js string for the given effect (example: $this->_jQHandler . 
'(this).fadeOut();')
      *
      * @return string
      */
     protected function getEffect()
     {
     }

}

class ZendX_JQuery_View_Helper_AjaxRequest extends 
ZendX_JQuery_View_Helper_AjaxRequest_Abstract
{

     /**
      * Create inline JQuery function that enables ajax-based requests 
and handling of the response.
      * @see ZendX_JQuery_View_Helper_AjaxLink
      *
      * @param string url
      * @param array $options (optional)
      * @param array $params (optional)
      * @return string
      */
     public function ajaxRequest($url, array $options = null, array 
$params = null)
     {
     }

     /**
      * Determine which request method (GET or POST) should be used.
      *
      * Normally the request method is determined implicitly by the rule,
      * if addiotional params are sent, POST, if not GET. You can overwrite
      * this behaviiour by implicitly setting $options['method'] = 
"POST|GET";
      *
      * @param  Array   $options
      * @param  Boolean $hasParams
      * @return String
      */
     protected function _determineRequestHandler($options, $hasParams)
     {
     }

}

class ZendX_JQuery_View_Helper_AjaxRequest_Link extends 
ZendX_JQuery_View_Helper_AjaxRequest
{

     private static $currentLinkCallbackId = 1;

     public function ajaxLink($label, $url, $options=null, $params=null)
     {
         $js = parent::ajaxRequest($url, $options, $params);

         // Etc

         return $js;
     }

     private function _getAttributes(array $attrib = array())
     {
     }

}

What do you guys think?
If i'm coming up with a stupid proposal please flame me (although useful 
critics are more welcome ;))

Regards,
Maghiel

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Vincent de Lau" <[email-masked]>
To: "'till'" <[email-masked]>,
	"'Ralph Schindler'" <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 20 May 2009 22:22:01 +0200
Subject: RE: [zf-contributors] Zend_Session

> So question is, do we really need exceptions here at all costs or
> could we utilize PHP's error handler (e.g. E_NOTICE, E_USER_WARNING)
> etc.. Point taken, it may be harder to grasp for the novice developer
> but display_errors, log_errors etc. are all sort of no-brainers and I
> see them as beginners stuff when it comes to developing PHP. I'd be
> very much in favor of ditching exceptions all together in this
> package.
> 
> (This is more or less a RFC, of course.)

I don't think the biggest problem lies within the session package itself.
Exceptions can be raised by external components, like Zend_Db. These must
also be available at save time.

Vincent de Lau
 [email-masked]

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Vincent de Lau" <[email-masked]>
To: "'Juozas'" <[email-masked]>,
	"'Zend Framework Contributors'" <[email-masked]>
Date: Sat, 5 Dec 2009 17:17:19 +0100
Subject: RE: [zf-contributors] Zend Framework modularity and application
	structure

This is a multi-part message in MIME format.

------=_NextPart_000_022E_01CA75CE.CF10D4E0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

In addition to the large mail I sent to this list a week or two ago, =
I=E2=80=99ll expand on your specific question:

=20

We have created several libraries to support all sites:

-          Our company extentions (big, see my previous mail)

-          A seperate backoffice library (mostly reusable view and form =
components)

-          An project specific library (model, public view components)

=20

Our public and private (admin, backoffice) sites are two distinct =
applications that share libraries and a database. The company library is =
shared across all sites, the backoffice library is shared among all =
backoffice application to create common look and feel.

=20

At the moment, only one of our Zend sites required a third party login. =
That is completely integrated in the existing website and controlled =
using an ACL (real access control, ACL based menu=E2=80=99s and =
widgets).=20

=20

We don=E2=80=99t use modules very much, although I think that we should =
use them more. I suppose there are two reasons for splitting things up =
in modules:

-          Organization of components, just to make developers live =
easier

-          Making parts of the application reusable, which requires =
little to none dependencies on other modules

=20

The organization element is pretty trivial and would be easy to do if =
required.

=20

Problem with reusing modules is that although controllers can usually be =
shared across projects, views might require local modification. For this =
reason, I=E2=80=99m considering moving some controller code to libraries =
and then have the actual called controller just plain extend it. =
I=E2=80=99ve done this for our error controller which resides in the =
company library. The actual error controller in the site just extends =
this Our_Error_ActionController. This way, all sites enjoy the benefits =
of an improved controller, while still allowing a local defined view.

=20

Our backoffices would probably be a better candidate for re-using =
modules and actually we do in part. However, adding new modules to the =
backoffice applications currently requires manual configuration (adding =
to a menu, setting up our ORM/model layer) which isn=E2=80=99t updates =
automatically. When we start using Zend_Application, I=E2=80=99d like to =
be able to call a bootstrap on all available modules, to that they can =
(for instance) register routes and add themselves to the navigation. =
When an action in a module is called, a second stage bootstrap would =
have to be called to setup the ORM.

=20

Vincent de Lau

 [email-masked]

=20

From: Juozas [mailto:[email-masked]]=20
Sent: Saturday, December 05, 2009 4:59 AM
To: Zend Framework Contributors ([email-masked])
Subject: [zf-contributors] Zend Framework modularity and application =
structure

=20

Hello everyone,

=20

as you know, Zend Framework 2.0 is having a major rewrite in some parts =
and a lot things can be arranged to make development easier/more =
flexible/etc.

=20

After discussing this with Matthew, I'm asking you to:

=20

Write in short, how do you use Zend Framework

=20

What interests us is how you work with modules (blog, products, news, =
users), how you divide your applications in to parts (admin, public, =
something else) and how other parts of code (acl, configuration, =
resources) comes into play here.=20

=20

The reason why I'm asking this, is because I'm using Zend Framework for =
quote big applications and for me it's important to have ability to =
create application with self-contained modules and sub-applications. For =
example I have e-commerce products having admin, public and supplier =
sub-applications, but everything is still nicely divided into modules =
(products, warehouse, orders, customers etc.) and App_Application and =
FrontController plugins does some work to make one application code to =
be divided in these parts.=20

=20

However, I know that some people use applications completely based on =
acl - there is one site and only depending on what your permissions are, =
you see data, can edit or delete if you want to. Here again somewhat =
different structure comes into play. Also quite popular thing to do is =
to have admin/default modules. Even though I completely don't understand =
this approach, some people like it and use everyday, hence it should =
also be possible to use.=20

=20

So please write what you think about such things, I will try to read =
them all, generalize into a comparison table and make it into a proposal =
of what functions from core are needed to support it (without any =
hacking, which I done quite a lot)

--
Juozas Kaziuk=C4=97nas ([email-masked])
A=C5=A1 internete - JuoKaz (http://www.juokaz.com)

------=_NextPart_000_022E_01CA75CE.CF10D4E0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.E-mailStijl17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1428963954;
	mso-list-type:hybrid;
	mso-list-template-ids:2137531372 -1347917628 68354051 68354053 68354049 =
68354051 68354053 68354049 68354051 68354053;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DNL link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In addition to the large mail I sent to this list a week =
or two
ago, I=E2=80=99ll expand on your specific =
question:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We have created several libraries to support all =
sites:<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Our company extentions =
(big, see
my previous mail)<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>A seperate backoffice =
library
(mostly reusable view and form components)<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>An project specific =
library
(model, public view components)<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Our public and private (admin, backoffice) sites are two
distinct applications that share libraries and a database. The company =
library
is shared across all sites, the backoffice library is shared among all
backoffice application to create common look and =
feel.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>At the moment, only one of our Zend sites required a =
third party
login. That is completely integrated in the existing website and =
controlled using
an ACL (real access control, ACL based menu=E2=80=99s and widgets). =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We don=E2=80=99t use modules very much, although I think =
that we should
use them more. I suppose there are two reasons for splitting things up =
in
modules:<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Organization of =
components,
just to make developers live easier<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Making parts of the =
application
reusable, which requires little to none dependencies on other =
modules<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The organization element is pretty trivial and would be =
easy to
do if required.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Problem with reusing modules is that although controllers =
can usually
be shared across projects, views might require local modification. For =
this
reason, I=E2=80=99m considering moving some controller code to libraries =
and then have the
actual called controller just plain extend it. I=E2=80=99ve done this =
for our error
controller which resides in the company library. The actual error =
controller in
the site just extends this Our_Error_ActionController. This way, all =
sites enjoy
the benefits of an improved controller, while still allowing a local =
defined
view.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Our backoffices would probably be a better candidate for =
re-using
modules and actually we do in part. However, adding new modules to the
backoffice applications currently requires manual configuration (adding =
to a
menu, setting up our ORM/model layer) which isn=E2=80=99t updates =
automatically. When
we start using Zend_Application, I=E2=80=99d like to be able to call a =
bootstrap on all
available modules, to that they can (for instance) register routes and =
add themselves
to the navigation. When an action in a module is called, a second stage
bootstrap would have to be called to setup the =
ORM.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vincent de Lau<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=C2=[email-masked]<o:p></o:p></span></p>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span=
></a></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Juozas
[mailto:[email-masked]] <br>
<b>Sent:</b> Saturday, December 05, 2009 4:59 AM<br>
<b>To:</b> Zend Framework Contributors =
([email-masked])<br>
<b>Subject:</b> [zf-contributors] Zend Framework modularity and =
application
structure<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Hello everyone,<o:p></o:p></p>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>as you know, Zend Framework 2.0 is having a major =
rewrite in
some parts and a lot things can be arranged to make development =
easier/more
flexible/etc.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>After discussing this with Matthew, I'm asking you =
to:<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal><b>Write in short, how do you use Zend =
Framework</b><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>What&nbsp;interests us is how you work with modules =
(blog,
products, news, users), how you divide your applications in to parts =
(admin,
public, something else)&nbsp;and how other parts of code (acl, =
configuration,
resources) comes into play here.&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>The reason why I'm asking this, is because I'm =
using Zend
Framework for quote big applications and for me it's important to have =
ability
to create application with self-contained modules and sub-applications. =
For
example I have e-commerce products having admin, public and supplier
sub-applications, but everything is still nicely divided into modules
(products, warehouse, orders, customers etc.) and App_Application and
FrontController plugins does some work to make one application code to =
be
divided in these parts.&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>However, I know that some people use applications =
completely
based on acl - there is one site and only depending on what your =
permissions
are, you see data, can edit or delete if you want to. Here again =
somewhat
different structure comes into play.&nbsp;Also quite popular thing to do =
is to
have admin/default modules. Even though I completely don't understand =
this
approach, some people like it and use everyday, hence it should also be =
possible
to use.&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>So please write what you think about such things, I =
will try
to read them all, generalize into a comparison table and make it into a
proposal of what functions from core are needed to support it (without =
any
hacking, which I done quite a lot)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br clear=3Dall>
--<br>
Juozas Kaziuk=C4=97nas (<a =
href=3D"mailto:[email-masked]">[email-masked]</a>)<br>
A=C5=A1 internete - JuoKaz (<a =
href=3D"http://www.juokaz.com">http://www.juokaz.com</a>)<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_022E_01CA75CE.CF10D4E0--

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 23:00:46 +0200
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

+1

I like it to have the magic method only as an addition because:

1. Some users don't like to use objects as methods and would call them
with a clean OOP style method
    anyhow its a nice feature to call the plugin object directly
function like.

2. Additional nobody implement the magic method "__toString" without the
real method "toString"

Greetings

Am 31.03.2010 22:04, schrieb Thomas Weidner:
> -1 from me
>
> I see no benefit of having 2 methods doing the same work
>
> Additionally forcing __invoke() means that ZF does no longer work
> below PHP 5.3.
> Even if we limit ZF 2.0 to 5.3 it does not mean that single components
> are not able to work below 5.3.
>
> And working with OOP I see no benefit of using objects by calling them
> as function. It's like a step backwards from OOP.
>
> my 3 cents
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "Lukas K=F6ll" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, March 31, 2010 9:38 PM
> Subject: Re: [zf-contributors] Plugin implementations
>
>
> -1 from me, too - I'm totally agreeing with Renan.
> Additionally I don't think design decisions should be based on how
> much work it
> is to write the corresponding unit tests. Don't get me wrong, of
> course the code
> must be testable. But especially for framework code I think that a low
> overhead
> should be preferred against easier testability - infact framework code =
is
> written (or changed) far more seldom than executed.
>
> If, however you decide to use __invoke as proxy, I would recommend to
> somehow
> prevent the proxied methods (filter, validate) to be called from
> outside or at least mark them as deprecated
> so client code _must_ use invoke and we could then remove the proxies
> later on if
> it should be decided that the tests are rewritten.
>
> best regards
>
> Lukas K=F6ll
>
>> -1
>>
>> Talking to my coworkers, a big piece of people take a little more time
>> to understand something when there is more than one way to do what
>> they want to do. I think that when we start a new project with
>> unnecessary duplicated features it's not good. This usually happens
>> after years, we should get this situations away. Obviously sometimes
>> it's interesting we provide alternative ways to achieve a goal, but
>> for those situations  (filter, validator...) it's not.
>>
>>>> The benefits:
>>>>
>>>> * Fewer changes necessary to existing unit tests
>>
>> time is the solution ;-)
>>
>>>> * interface method names may be more descriptive of intent
>>
>> they should pick a better name for their variables, like $filterFloat,
>> $filterAlpha
>>
>>>> Problems:
>>>>
>>>> * Using __invoke() introduces overhead -- 2 method calls instead of
>>>> one
>>>> * Redundancy (two methods doing the same thing)
>>
>> that's my point! this extra way is not relevant, this one adds no new
>> feature
>>
>>>> * A few extra tests to write (to ensure __invoke works as expecte)
>>
>> my 1 cent ;-)
>>
>> --=20
>> Renan de Lima Barbosa
>> gtalk/msn: [email-masked]
>> skype: renandelima
>> +55 61 8166-7755
>> renandelima.com
>>
>>
>>
>> On 31 March 2010 11:38, Dennis Winter
>> <[email-masked]> wrote:
>>> +1 on this! It's ok to have two methods for the same thing! And the
>>> benefit
>>> of clearer interfaces is overwhelming the disadvantages!
>>> Just my 2 cents!
>>>
>>> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney
>>> <[email-masked]>:
>>>
>>>> Greetings, all --
>>>>
>>>> Per the roadmap, one change we're planning on making is making plugi=
n
>>>> usage consistent across components: plugins will implement __invoke(=
),
>>>> which makes them inherently callable.
>>>>
>>>> In our refactoring branch, I've done this now with Zend_Filter.
>>>> However,
>>>> it required a ton of refactoring on the unit tests (had to either ca=
ll
>>>> __invoke() directly, or $filter($value)), and it got me to thinking:
>>>>
>>>> Would it make sense to keep the original interfaces (filter, isValid=
,
>>>> render, etc.), but also implement __invoke() -- having it proxy to t=
he
>>>> appropriate interface method?
>>>>
>>>> As an example:
>>>>
>>>>   interface Filter
>>>>   {
>>>>       public function filter($value);
>>>>       public function __invoke($value);
>>>>   }
>>>>
>>>>   class Digits implements Filter
>>>>   {
>>>>       public function filter($value)
>>>>       {
>>>>           // ... logic...
>>>>       }
>>>>
>>>>       public function __invoke($value)
>>>>       {
>>>>           return $this->filter($value);
>>>>       }
>>>>   }
>>>>
>>>> The benefits:
>>>>
>>>> * Fewer changes necessary to existing unit tests
>>>> * interface method names may be more descriptive of intent
>>>>
>>>> Problems:
>>>>
>>>> * Using __invoke() introduces overhead -- 2 method calls instead of
>>>> one
>>>> * Redundancy (two methods doing the same thing)
>>>> * A few extra tests to write (to ensure __invoke works as expecte)
>>>>
>>>> After discussion with Ralph and Alex, I'm leaning towards having
>>>> __invoke() as an _additional_ method, instead of replacing existing
>>>> methods.
>>>>
>>>> Any thoughts or comments?
>>>>
>>>> --=20
>>>> Matthew Weier O'Phinney
>>>> Project Lead            | [email-masked]
>>>> Zend Framework          | http://framework.zend.com/
>>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>>
>
>

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 10 Feb 2010 13:27:05 +0200
From: Shahar Evron <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Mail

I am not the Zend_Mail maintainer but as a side note it sounds like
there is no need to wait for 2.0 if you'd like to help implementing the
current missing parts, as long as there is no backwards compatibility
breakage in the process (and I'm guessing, without knowing the details,
that for the most part there shouldn't be).

Shahar.

On 10/2/10 2:53 AM, [email-masked] wrote:
> Hi,
> 
> in the roadmap for 2.0 you called for participation in the discussion,
> so here are my thoughts for Zend_Mail. First at all, the most important
> thing is to complete the existing code. For instance, in the imap
> component there are many features in the api but marked "not
> implemented". I'm trying to write an email webclient and found many
> things which just aren't implemented. Things like search in imap and
> fetching only contents parts of emails instead of all, aren't working.
> I also think, that content encoding should be integrated automatically.
> 
> To keep it short, at the moment the imap layer in zend is only (too) basic.
> I would like to help the Zend_Mail maintainer (whoever that is) and hear
> your thoughts.
> 
> Regards,
> Otto

-- 
Shahar Evron <[email-masked]>

Product Manager
Zend Technologies

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
To: [email-masked]
Date: Sat, 21 Mar 2009 22:03:57 +0000
Subject: [zf-contributors] Recording items for 1.8's readme?

Hi,

How is the list of features that goes into the README done?

Zend_Config_Xml now supports loading an XML string directly (e.g. from  
a database) which may just be useful enough to enough people to  
warrant a mention. But I don't know where to record this / who to tell.

What's the process that I no doubt should already be aware of ?!

Regards,

Rob...

nFrom nobody Wed Apr  7 08:46:06 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 17 Apr 2009 16:58:11 +0200
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] Code Freeze starts Monday

Hey Matthew,

Shouldn't that mid-week release be called RC instead of beta? Beta
usually comes before a PR. And well, I'll get the documentation for
Zend_Tag done this weekend, so you can promote it to trunk on monday.
Also trying to get a screencast about Zend_Tag done for the 1.8 release,
but that's another story.

Ben
...................................
:  ___   _   ___ ___ ___ _ ___    :
: |   \ /_\ / __| _ \ _ (_)   \   :
: | |) / _ \\__ \  _/   / | |) |  :
: |___/_/:\_\___/_| |_|_\_|___/   :
:........:........................:
: Web    : http://www.dasprids.de :
: E-mail : [email-masked]       :
: Jabber : [email-masked]     :
: ICQ    : 105677955              :
:........:........................:

Matthew Weier O'Phinney schrieb:
> Greetings, all!
> 
> 1.8 is shaping up nicely! We've had a lot of good feedback since the
> preview release last week, and a number of other components have become
> stable since then and have either been pushed to trunk or are ready to
> review for inclusion in trunk.
> 
> We are considering doing a beta release mid-week next week. This will
> ensure that the API stabilizes, and give developers and reviewers a real
> feel for the final 1.8 product. 
> 
> As such, I'm announcing a code freeze, effective 14:00 UTC on Monday, 
> 20 April 2009. (This is when we have our daily internal meeting.)
> 
> If you have components that you have completed in incubator and want
> reviewed for inclusion, please get them in before then. Please be aware
> that if the component test coverage or documentation are deemed
> incomplete or unsatisfactory at that time, they will *NOT* be included
> in the final 1.8 release. 
> 
> If you are working on a new component in the trunk, please have the
> public API for those components stable by that time.
> 
> Again, code freeze is at 14:00 UTC on Monday, 20 April 2009.
> 
> Thanks again, and keep up the great work!
> 

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Renan de Lima <[email-masked]>
Date: Wed, 31 Mar 2010 12:58:28 -0300
To: "[email-masked]" <[email-masked]>
Subject: Re: [zf-contributors] Plugin implementations

-1

Talking to my coworkers, a big piece of people take a little more time
to understand something when there is more than one way to do what
they want to do. I think that when we start a new project with
unnecessary duplicated features it's not good. This usually happens
after years, we should get this situations away. Obviously sometimes
it's interesting we provide alternative ways to achieve a goal, but
for those situations  (filter, validator...) it's not.

>> The benefits:
>>
>> * Fewer changes necessary to existing unit tests

time is the solution ;-)

>> * interface method names may be more descriptive of intent

they should pick a better name for their variables, like $filterFloat,
$filterAlpha

>> Problems:
>>
>> * Using __invoke() introduces overhead -- 2 method calls instead of one
>> * Redundancy (two methods doing the same thing)

that's my point! this extra way is not relevant, this one adds no new featu=
re

>> * A few extra tests to write (to ensure __invoke works as expecte)

my 1 cent ;-)

--
Renan de Lima Barbosa
gtalk/msn: [email-masked]
skype: renandelima
+55 61 8166-7755
renandelima.com

On 31 March 2010 11:38, Dennis Winter <[email-masked]> wro=
te:
> +1 on this! It's ok to have two methods for the same thing! And the benef=
it
> of clearer interfaces is overwhelming the disadvantages!
> Just my 2 cents!
>
> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney <[email-masked]>=
:
>
>> Greetings, all --
>>
>> Per the roadmap, one change we're planning on making is making plugin
>> usage consistent across components: plugins will implement __invoke(),
>> which makes them inherently callable.
>>
>> In our refactoring branch, I've done this now with Zend_Filter. However,
>> it required a ton of refactoring on the unit tests (had to either call
>> __invoke() directly, or $filter($value)), and it got me to thinking:
>>
>> Would it make sense to keep the original interfaces (filter, isValid,
>> render, etc.), but also implement __invoke() -- having it proxy to the
>> appropriate interface method?
>>
>> As an example:
>>
>> =C2=A0 interface Filter
>> =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 public function filter($value);
>> =C2=A0 =C2=A0 =C2=A0 public function __invoke($value);
>> =C2=A0 }
>>
>> =C2=A0 class Digits implements Filter
>> =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 public function filter($value)
>> =C2=A0 =C2=A0 =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... logic...
>> =C2=A0 =C2=A0 =C2=A0 }
>>
>> =C2=A0 =C2=A0 =C2=A0 public function __invoke($value)
>> =C2=A0 =C2=A0 =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return $this->filter($value);
>> =C2=A0 =C2=A0 =C2=A0 }
>> =C2=A0 }
>>
>> The benefits:
>>
>> * Fewer changes necessary to existing unit tests
>> * interface method names may be more descriptive of intent
>>
>> Problems:
>>
>> * Using __invoke() introduces overhead -- 2 method calls instead of one
>> * Redundancy (two methods doing the same thing)
>> * A few extra tests to write (to ensure __invoke works as expecte)
>>
>> After discussion with Ralph and Alex, I'm leaning towards having
>> __invoke() as an _additional_ method, instead of replacing existing
>> methods.
>>
>> Any thoughts or comments?
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
>> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend=
.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 1 Apr 2010 16:30:48 +0200
From: till <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

On Mon, Mar 22, 2010 at 1:36 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> Greetings, all --
>
> Based on the wiki and the poll on this list, it looks like it makes
> sense to move forward with git. We're still trying to iron on some
> details about how this will work, but some details are falling into
> place.
>
> First, the things we plan:
>
> =A0* Git will be hosted on the ZF servers. This is so that we can have
> =A0 full control over hooks (i.e., no network latency from web hooks),
> =A0 integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
> =A0 will offer both anonymous access as well as selective writable
> =A0 access.
>
> =A0 Some will say, "why not just use Github?" The above does not preclude
> =A0 using github in any way; git allows you to specify multiple remotes
> =A0 from your repository. I already plan to have a mirror of my personal
> =A0 repo on github, as well as push to the ZF repo from the same
> =A0 location. This will allow people to use some of githubs powerful
> =A0 features such as pull queues while still allowing us to retain some
> =A0 control over the repository. (It also insulates us from githubs
> =A0 growing pains a bit -- I love github, but they are certainly
> =A0 suffering from rapid growth the last few months!)
>
> =A0* We plan to have a read-only subversion mirror of the git repository.
> =A0 This will allow those using svn:externals to continue to do so, as
> =A0 well as allow folks more familiar with svn to continue to provide
> =A0 patches.
>
> Next, things we're still researching:
>
> =A0* How to handle contributions. Since we require a signed CLA, we need
> =A0 some way of verifying that a patch came from an author who has signed
> =A0 the CLA. There have been some suggestions that this may be possible
> =A0 with some sort of pre-commit verifications when committing to the
> =A0 master repository (or when someone with commit privileges commits to
> =A0 their own repository). We're still researching how this might be
> =A0 implemented.
>
> =A0* Submodules...
> =A0 For those unfamiliar with git submodules, they are roughly equivalent
> =A0 to svn:externals. I say "roughly", because they differ in many ways:
> =A0 they have to be manually initialized on each person's repository
> =A0 (though they can be defined in the master repository); they need to
> =A0 be manually updated periodically (unlike svn:externals, where anytime
> =A0 you do an "svn up", it also syncs the external); etc.

http://github.com/blog/626-announcing-svn-support

I know Zend will do their own git, but since it's trivial to make a
mirror on Github, this might be something interesting for everyone who
misses svn:externals. ;-)

Till

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 9 Mar 2010 08:07:52 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 8 Mar 2010

-- Giorgio Sironi <[email-masked]> wrote
(on Tuesday, 09 March 2010, 11:48 AM +0100):
> On Tue, Mar 9, 2010 at 12:04 AM, Ben Scholzen 'DASPRiD' <[email-masked]>
> wrote:
> 
>     Matthew Weier O'Phinney wrote on 08.03.2010 22:41:
>     >     # from tests/ directory
>     >     % phpunit --group Zend_Acl .
> 
>     Why not just do phpunit --filter Zend_Acl instead? That makes the @group
>     stuff obsolete.
> 
> 
> You can even do:
> $ phpunit Zend/Acl

Using @group annotations allows us to run multiple component suites
simultaneously, as well as to group test cases across multiple
components. It also allows us to specify a given test case as belonging
to multiple groups; this can be particularly useful for testing things
such as view helpers (which are under Zend_View_Helper,
Zend_Dojo_View_Helper, and ZendX_Jquery_View_Helper), action helpers
(Zend_Controller_Action_Helper, Zend_Layout, etc.), and more.

Basically, group annotations give us more structure and benefits.

Most importantly to me, it provides an _explicit_ semantic meaning to the
various test suites. We need to favor explicitness over implicitness for
ZF 2.0.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 20 Mar 2009 22:06:48 +0100
From: till <[email-masked]>
To: Wil Sinclair <[email-masked]>
Cc: Thomas Weidner <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

What if I added a "feature" to an existing component.

I mean, from what I understand -- the mini releases shouldn't break BC
-- that's all. But if I add to the api that's allowed? (asking)

On Fri, Mar 20, 2009 at 10:02 PM, Wil Sinclair <[email-masked]> wrote:
> OK, I changed it. There will inevitably be some hand-waving around what
> is a new feature and what is a functionality enhancement. I'd rather
> confine this thread to the issue of release policies and conventions. :)
>
> New components pretty clearly fall under the category of 'new features'
> in my mind. If others are confused, we should further clarify it.
>
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 1:42 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> "A mini release may contain only bug fixes. Note that no new features or
> API
> changes are allowed whatsoever."
>
> This sentence could imply that new features are not allowed, but
> improvments
> of existing features are allowed as long as they don't change existing
> API.
> The word "only" could be overseen.
>
> The question is also what's for us the difference between a feature
> enhancement and a new feature.
> Feature Enhancement could be for example to add a new option. It would
> not
> change API. So a textual clearification would be great :-)
>
> Also to note: Are new components allowed within minor releases or only
> within major releases? Should also be defined.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>;
> <[email-masked]>
> Sent: Friday, March 20, 2009 9:31 PM
> Subject: RE: [zf-contributors] Release Policies and Conventions
>
>
> Hey Thomas, I'm not quite sure what you are referring to. Your
> understanding is correct, and the wiki page seems to reflect it
> perfectly. Can you tell me exactly what needs to be updated? Maybe with
> the string that you're referring to?
>
> Thanks.
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 12:57 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> In my understanding also "feature enhancements" are actually not allowed
> to
> be integrated within mini-releases.
> Only "Bug fixes" which do not add additional API are allowed.
>
> Maybe you should also add a definition for what's a bug fix, a
> improvement
> and a new feature to get that also defined, and we can all speak of the
> same
> in future.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, March 20, 2009 8:47 PM
> Subject: [zf-contributors] Release Policies and Conventions
>
>
> Over the 2 years that I've been involved with the project, there have
> been many questions about what can go in to a given release and if there
> are any guidelines for the release schedules. While many of you have
> pieced the picture together from different mails, IRC chats, etc. I've
> owed you a document for a long time now. Here it is:
>
>
>
> http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
> tions
>
>
>
> I ask all contributors to review this and reply with any question or
> edits- especially if I missed something- in this forum.
>
>
>
> As always, thanks for all the time and effort. Also, go 1.8!
>
>
>
> ,Wil
>
>

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 3 May 2009 09:25:29 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend_Session

-- till <[email-masked]> wrote
(on Saturday, 02 May 2009, 09:34 PM +0200):
> has anyone started on a rewrite of Zend_Session yet? The issues are
> piling up on Jira and no one seems to be responsible while the general
> consensus seems to be that it's gonna be re-done in 2.0. So anyway, if
> anyone is working on this, I'd like to offer my help here.

Please *do* start working on a rewrite. Use a user branch for now.

What I'd like to see:

 * separation of setting PHP's session.* INI values into a single
   component
 * Ability to specify the source array to which the session object will
   proxy (i.e., allowing specifying a different array than $_SESSION);
   most likely, this will need to be by reference.  This will be
   necessary to allow easy testing.
   * __destruct() should then write the source array
 * Keeping Zend_Session_Namespace as BC as possible with the above
   guidelines

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 22 Jan 2010 11:58:17 +0000
From: Juozas <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Doctrine 1 Integration Ideas

--001485f726c0fa76c6047dbf88c6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

have been busy myself lately. I'll write more today what are the problems
with 1.X and how I fixed them/hacked something.

--
Juozas Kaziuk=C4=97nas ([email-masked])
A=C5=A1 internete - JuoKaz (http://www.juokaz.com)

On Fri, Jan 22, 2010 at 11:57 AM, Benjamin Eberlei <[email-masked]>wro=
te:

>
> Hello everyone,
>
> there hasn't been much news on this front lately, me was kinda busy with
> work and such.
>
> Yesterday I reviewed all the stuff i found on ZF and Doctrine 1
> integration and came to
> the conclusion that while single modular generation is supported by
> Doctrine 1.2's new
> PEAR style model generation you still have to hack lots around.
>
> Therefore my idea is, two-fold:
>
> I. Single ZF Module (Default)
>
> Support Single-Default-Module Scenario more easily by providing a
> config-option
> that automatically sets all the model-generation options correctly. This
> would
>  be something along the lines of:
>
> $import->setOptions(array(
>    'pearStyle' =3D> true,
>    'baseClassesDirectory' =3D> null,
>    'baseClassPrefix' =3D> 'Base_',
>    'classPrefix' =3D> 'Model_',
>    'classPrefixFiles' =3D> true
> ));
>
> This allows for models of the Style "Model_User", "Model_Foo",
> "Model_Bar".
>
> HOWEVER: Can someone explain to me how that relates to the class name tha=
t
> you can
> specifiy in the YAML config file?
>
> No upgrade mechanism from single module to multiple module will be
> provided.
>
> II. Doctrine + Multiple ZF MOdules:
>
> Circumvent Doctrine_Core::loadModels() completely by introducing a new
> auto-loading
> mechanism and slightly modifying the Doctrine_Import_Schema class.
>
> This style would do no magic, it would require you to use class names of
> the kind:
>
> <ModuleName>_Model_<ModelName>
>
> Doctrine would auto-load all the classes of the kind in all
> <moduleName>/models through
> a Module Resource Loader.
>
> For the CLI tasks in Zend Tool there would be a dection of all models by
> the mechanism.
>
> 1. Get Front Controller module/controller directory
> 2. Iteratore over them and find all models directories.
> 3. Recursively scan all models directories for
> <ModuleName>_Model_<ModelName> classes.
>
> For the YAML to Model Generation task the mechanism would be.
>
> 1. Detect Module name by checking the first result of explode("_",
> $className)
> 2. If the first is "Model", grab default module from Front-Controller,
> otherwise Check that second result is "Model"
> 3. Write record, base-record and optionally table classes into the module=
s
> model directory.
>
> This requires a Doctrine + Zend Modular Application to follow strict clas=
s
> naming standards,
> but makes the implementation very robust in terms of both frameworks and
> avoids any
> additional magic (Looking at the Doctrine 1 code, there is already too
> much magic!)
>
> Any ideas?
>
> My plan is to get this into 1.11, I'll colaborate with Matthew Lurz also
> to get the
> Doctrine application resource ready for this then.
>
> Also my plan is that this integration will require Doctrine 1.2
>
> greetings,
> Benjamin
>

--001485f726c0fa76c6047dbf88c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>have been busy myself lately. I&#39;ll write more to=
day what are the problems with 1.X and how I fixed them/hacked something.</=
div><div><br clear=3D"all">--<br>Juozas Kaziuk=C4=97nas (<a href=3D"mailto:=
[email-masked]">[email-masked]</a>)<br>
A=C5=A1 internete - JuoKaz (<a href=3D"http://www.juokaz.com">http://www.ju=
okaz.com</a>)<br>
<br><br><div class=3D"gmail_quote">On Fri, Jan 22, 2010 at 11:57 AM, Benjam=
in Eberlei <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">kon=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class=3D"h5"><br>
Hello everyone,<br>
<br>
there hasn&#39;t been much news on this front lately, me was kinda busy wit=
h<br>
work and such.<br>
<br>
Yesterday I reviewed all the stuff i found on ZF and Doctrine 1<br>
integration and came to<br>
the conclusion that while single modular generation is supported by<br>
Doctrine 1.2&#39;s new<br>
PEAR style model generation you still have to hack lots around.<br>
<br>
Therefore my idea is, two-fold:<br>
<br>
I. Single ZF Module (Default)<br>
<br>
Support Single-Default-Module Scenario more easily by providing a<br>
config-option<br>
that automatically sets all the model-generation options correctly. This<br=
would<br>
=C2=A0be something along the lines of:<br>
<br>
$import-&gt;setOptions(array(<br>
 =C2=A0 =C2=A0&#39;pearStyle&#39; =3D&gt; true,<br>
 =C2=A0 =C2=A0&#39;baseClassesDirectory&#39; =3D&gt; null,<br>
 =C2=A0 =C2=A0&#39;baseClassPrefix&#39; =3D&gt; &#39;Base_&#39;,<br>
 =C2=A0 =C2=A0&#39;classPrefix&#39; =3D&gt; &#39;Model_&#39;,<br>
 =C2=A0 =C2=A0&#39;classPrefixFiles&#39; =3D&gt; true<br>
));<br>
<br>
This allows for models of the Style &quot;Model_User&quot;, &quot;Model_Foo=
&quot;,<br>
&quot;Model_Bar&quot;.<br>
<br>
HOWEVER: Can someone explain to me how that relates to the class name that<=
br>
you can<br>
specifiy in the YAML config file?<br>
<br>
No upgrade mechanism from single module to multiple module will be<br>
provided.<br>
<br>
II. Doctrine + Multiple ZF MOdules:<br>
<br>
Circumvent Doctrine_Core::loadModels() completely by introducing a new<br>
auto-loading<br>
mechanism and slightly modifying the Doctrine_Import_Schema class.<br>
<br>
This style would do no magic, it would require you to use class names of<br=
the kind:<br>
<br>
&lt;ModuleName&gt;_Model_&lt;ModelName&gt;<br>
<br>
Doctrine would auto-load all the classes of the kind in all<br>
&lt;moduleName&gt;/models through<br>
a Module Resource Loader.<br>
<br>
For the CLI tasks in Zend Tool there would be a dection of all models by<br=
the mechanism.<br>
<br>
1. Get Front Controller module/controller directory<br>
2. Iteratore over them and find all models directories.<br>
3. Recursively scan all models directories for<br>
&lt;ModuleName&gt;_Model_&lt;ModelName&gt; classes.<br>
<br>
For the YAML to Model Generation task the mechanism would be.<br>
<br>
1. Detect Module name by checking the first result of explode(&quot;_&quot;=
,<br>
$className)<br>
2. If the first is &quot;Model&quot;, grab default module from Front-Contro=
ller,<br>
otherwise Check that second result is &quot;Model&quot;<br>
3. Write record, base-record and optionally table classes into the modules<=
br>
model directory.<br>
<br>
This requires a Doctrine + Zend Modular Application to follow strict class<=
br>
naming standards,<br>
but makes the implementation very robust in terms of both frameworks and<br=
avoids any<br>
additional magic (Looking at the Doctrine 1 code, there is already too<br>
much magic!)<br>
<br>
Any ideas?<br>
<br>
</div></div>My plan is to get this into 1.11, I&#39;ll colaborate with Matt=
hew Lurz also<br>
to get the<br>
Doctrine application resource ready for this then.<br>
<br>
Also my plan is that this integration will require Doctrine 1.2<br>
<br>
greetings,<br>
<font color=3D"#888888">Benjamin<br>
</font></blockquote></div><br></div>

--001485f726c0fa76c6047dbf88c6--

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 14 Jan 2010 16:55:18 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] 1.10 has been branched!

Greetings, all!

I've just created the official 1.10 branch, and will be tagging the beta
off of this branch momentarily.

>From this point forward, no API changes are allowed in the release-1.10
branch -- but DO please assist in fixing bugs, translating, etc.!

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 14:58:43 -0600
From: Ralph Schindler <[email-masked]>
To: Diego Henrique Oliveira <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

I am not sure I see a lot of value here.  What kind of bottleneck are 
you seeing?  Considering this function should only be run once during 
the lifespan of a user's session, I am not sure why it would be that big 
of an issue.

Returning 20 vs. 4 columns generally has no consequence on the result at 
all, what vendor DB are you using where this is a concern?

Furthermore, perhaps you should break out authentication information 
from the user table itself and instead use a join with the select 
object? Just a thought.

-ralph

Diego Henrique Oliveira wrote:
> In the adapter DbTable, the generated query to the database is a 'select 
> *', and as it was being a bottleneck in my application (users table with 
> many fields), i made these changes in the component 
> Zend_Auth_Adapter_DbTable.
> 
> 
> class Zend_Auth_Adapter_DbTable
> {
>    
>     protected $_returnedFields;
>    
>     public function setReturnedFields( array $fields )
>     {
>         $this->_returnedFields = $fields;
>     }
>    
>     public function getReturnedFields()
>     {
>         if (is_null($this->_returnedFields))
>         {
>             return array('*');
>         }
>         return $this->_returnedFields;
>     }
>    
>     /**
>      * _authenticateCreateSelect() - This method creates a 
> Zend_Db_Select object that
>      * is completely configured to be queried against the database.
>      *
>      * @return Zend_Db_Select
>      */
>     protected function _authenticateCreateSelect()
>     {
>         // build credential expression
>         if (empty($this->_credentialTreatment) || 
> (strpos($this->_credentialTreatment, '?') === false)) {
>             $this->_credentialTreatment = '?';
>         }
> 
>         $credentialExpression = new Zend_Db_Expr(
>             '(CASE WHEN ' .
>             $this->_zendDb->quoteInto(
>                 
> $this->_zendDb->quoteIdentifier($this->_credentialColumn, true)
>                 . ' = ' . $this->_credentialTreatment, $this->_credential
>                 )
>             . ' THEN 1 ELSE 0 END) AS '
>             . $this->_zendDb->quoteIdentifier(
>                 $this->_zendDb->foldCase('zend_auth_credential_match')
>                 )
>             );
> 
>         // get select
>         $fields   = $this->getReturnedFields();
>         array_push( $fields, $credentialExpression );
>         $dbSelect = clone $this->getDbSelect();
>         $dbSelect->from($this->_tableName, $fields)
>                  
> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . 
> ' = ?', $this->_identity);
> 
>         return $dbSelect;
>     }
>    
> }
> 
> 
> 
> What you guys think about these changes? And should I submit them to the 
> project?
> 
> 
> Cheers
> 
> Diego
> http://diegoholiveira.com
> 

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: David Abdemoulaie <[email-masked]>
Date: Mon, 15 Mar 2010 16:15:57 -0500
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

--Apple-Mail-15-470264824
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I too prefer Abstract to Base. I often use Base in my applications for =
non-abstract super classes which extend the abstract ZF classes. To me =
Abstract means I can't instantiate it, but Base means I *could* if I =
wanted.

On Mar 15, 2010, at 4:03 PM, P=E1draic Brady wrote:

> I agree with Matthew on the rest, except that, as with Court, I prefer =
Abstract to Base. Longer term albeit, it makes more sense than Base =
which can suggest a broader use meaning (e.g. a non-Abstract super =
class). Under that meaning, Base can be any parent class so the =
indication of a class being Abstract is no longer a certainty without =
referring to API docs (or the code itself).
>=20
> Paddy
> =20
> P=E1draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>=20

--Apple-Mail-15-470264824
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head><base href=3D"x-msg://356/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div>I too prefer Abstract to Base. I often use =
Base in my applications for non-abstract super classes which extend the =
abstract ZF classes. To me Abstract means I can't instantiate it, but =
Base means I *could* if I wanted.</div><br><div><div>On Mar 15, 2010, at =
4:03 PM, P=E1draic Brady wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
font-family: 'times new roman', 'new york', times, serif; font-size: =
12pt; ">I agree with Matthew on the rest, except that, as with Court, I =
prefer Abstract to Base. Longer term albeit, it makes more sense than =
Base which can suggest a broader use meaning (e.g. a non-Abstract super =
class). Under that meaning, Base can be any parent class so the =
indication of a class being Abstract is no longer a certainty without =
referring to API docs (or the code itself).<br><br>Paddy<br><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">&nbsp;</div><span style=3D"color: rgb(0, 0, 191); =
"><font size=3D"3" style=3D"font-family: 'times new roman', 'new york', =
times, serif; "><span style=3D"font-weight: bold; ">P=E1draic =
Brady<br><br></span></font><span style=3D"font-style: italic; "><font =
size=3D"3" style=3D"font-family: 'times new roman', 'new york', times, =
serif; "><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com=
</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish =
Representative</a><br></font></span></span><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
"><br></div></div></div></span></blockquote></div><br></body></html>=

--Apple-Mail-15-470264824--

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 28 Nov 2009 06:30:04 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Zend_Feed_Reader Assistance Needed (Or I'll Go
	Crazy)

--0-1603841984-1259418604=:95126
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Bit of an odd reason for this ;). I'm getting a fatal error (see bottom) wh=
en running the unit tests for Zend_Feed_Reader (via trunk/tests/Zend/Feed/A=
llTests.php). After two hours of staring at gedit without the slightest clu=
e or knock of inspiration - I've just about exhausted my supply of patience=
.=0A=0AIf someone is doing any ZF development over the weekend, would truly=
 appreciate any insight on resolving this. It has me completely stumped.=0A=
=0AA bit of background. The fatal error only occurs from revisions r19280/1=
. At that time I added a new class Zend_Feed_Reader_Feed_Atom_Source which =
extends from Zend_Feed_Reader_Feed_Atom. As far as I can tell all classes a=
re named and included correctly - but that damn fatal error about not findi=
ng the class Zend_Feed_Reader_FeedAbstract persists. I've verified that r19=
279 is free of all errors and all unit tests at that time pass.=0A=0AMy fin=
al thoughts are that a) I'm overlooking the obvious or b) it's a PHP bug. I=
'm running PHP 5.2.10 at the moment on Ubuntu Karmic - no access to another=
 version until Monday (not at home). Oh, and for those on Ubuntu the new PH=
P update made no difference when I applied it last night.=0A=0AI half expec=
t this to be an embarrassing revelation that I've spent the last day being =
a total idiot ;).=0A=0APaddy=0A=0A=0AFatal error: Class 'Zend_Feed_Reader_F=
eedAbstract' not found in /home/padraic/projects/zf/trunk/library/Zend/Feed=
/Reader/Feed/Atom.php on line 38=0A=0ACall Stack:=0A    0.0009     110120  =
 1. {main}() /usr/bin/phpunit:0=0A    0.2302    7197488   2. PHPUnit_TextUI=
_Command::main() /usr/bin/phpunit:52=0A    0.2302    7198832   3. PHPUnit_T=
extUI_Command->run() /usr/share/php/PHPUnit/TextUI/Command.php:147=0A    0.=
2322    7203088   4. PHPUnit_Runner_BaseTestRunner->getTest() /usr/share/ph=
p/PHPUnit/TextUI/Command.php:168=0A    0.2322    7203496   5. PHPUnit_Runne=
r_BaseTestRunner->loadSuiteClass() /usr/share/php/PHPUnit/Runner/BaseTestRu=
nner.php:112=0A    0.2322    7204640   6. PHPUnit_Runner_StandardTestSuiteL=
oader->load() /usr/share/php/PHPUnit/Runner/BaseTestRunner.php:170=0A    0.=
2324    7267184   7. PHPUnit_Util_Fileloader::checkAndLoad() /usr/share/php=
/PHPUnit/Runner/StandardTestSuiteLoader.php:102=0A    0.2324    7267680   8=
. PHPUnit_Util_Fileloader::load() /usr/share/php/PHPUnit/Util/Fileloader.ph=
p:91=0A    0.2331    7311400   9. include_once('/home/padraic/projects/zf/t=
runk/tests/Zend/Feed/AllTests.php') /usr/share/php/PHPUnit/Util/Fileloader.=
php:113=0A    0.6806   11464144  10. require_once('/home/padraic/projects/z=
f/trunk/tests/Zend/Feed/ReaderTest.php') /home/padraic/projects/zf/trunk/te=
sts/Zend/Feed/AllTests.php:48=0A    0.7001   11727944  11. require_once('/h=
ome/padraic/projects/zf/trunk/library/Zend/Feed/Reader.php') /home/padraic/=
projects/zf/trunk/tests/Zend/Feed/ReaderTest.php:24=0A    0.7180   11966176=
  12. require_once('/home/padraic/projects/zf/trunk/library/Zend/Feed/Reade=
r/Feed/Rss.php') /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader.p=
hp:30=0A    0.7188   12045672  13. require_once('/home/padraic/projects/zf/=
trunk/library/Zend/Feed/Reader/FeedAbstract.php') /home/padraic/projects/zf=
/trunk/library/Zend/Feed/Reader/Feed/Rss.php:25=0A    0.7200   12176712  14=
. require_once('/home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/En=
try/Atom.php') /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Fee=
dAbstract.php:30=0A    0.7277   12490040  15. require_once('/home/padraic/p=
rojects/zf/trunk/library/Zend/Feed/Reader/Extension/Atom/Entry.php') /home/=
padraic/projects/zf/trunk/library/Zend/Feed/Reader/Entry/Atom.php:40=0A    =
0.9154   17272344  16. require_once('/home/padraic/projects/zf/trunk/librar=
y/Zend/Feed/Reader/Feed/Atom/Source.php') /home/padraic/projects/zf/trunk/l=
ibrary/Zend/Feed/Reader/Extension/Atom/Entry.php:50=0A    0.9166   17404288=
  17. require_once('/home/padraic/projects/zf/trunk/library/Zend/Feed/Reade=
r/Feed/Atom.php') /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/=
Feed/Atom/Source.php:25=0A=0ANote: Just be aware that Zend_Feed_Reader uses=
 no code from Zend_Feed (the original component). ZFR uses its own interfac=
es and abstracts.=0A=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.co=
m=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Repre=
sentative
--0-1603841984-1259418604=:95126
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Bit of an odd reason for this ;). I'm getting a fatal error (s=
ee bottom) when running the unit tests for Zend_Feed_Reader (via trunk/test=
s/Zend/Feed/AllTests.php). After two hours of staring at gedit without the =
slightest clue or knock of inspiration - I've just about exhausted my suppl=
y of patience.<br><br>If someone is doing any ZF development over the weeke=
nd, would truly appreciate any insight on resolving this. It has me complet=
ely stumped.<br><br>A bit of background. The fatal error only occurs from r=
evisions r19280/1. At that time I added a new class Zend_Feed_Reader_Feed_A=
tom_Source which extends from Zend_Feed_Reader_Feed_Atom. As far as I can t=
ell all classes are named and included correctly - but that damn fatal erro=
r about not finding the class Zend_Feed_Reader_FeedAbstract persists.
 I've verified that r19279 is free of all errors and all unit tests at that=
 time pass.<br><br>My final thoughts are that a) I'm overlooking the obviou=
s or b) it's a PHP bug. I'm running PHP 5.2.10 at the moment on Ubuntu Karm=
ic - no access to another version until Monday (not at home). Oh, and for t=
hose on Ubuntu the new PHP update made no difference when I applied it last=
 night.<br><br>I half expect this to be an embarrassing revelation that I'v=
e spent the last day being a total idiot ;).<br><br>Paddy<br><br><br>Fatal =
error: Class 'Zend_Feed_Reader_FeedAbstract' not found in /home/padraic/pro=
jects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom.php on line 38<br><br>Cal=
l Stack:<br>&nbsp;&nbsp;&nbsp; 0.0009&nbsp;&nbsp;&nbsp;&nbsp; 110120&nbsp;&=
nbsp; 1. {main}() /usr/bin/phpunit:0<br>&nbsp;&nbsp;&nbsp; 0.2302&nbsp;&nbs=
p;&nbsp; 7197488&nbsp;&nbsp; 2. PHPUnit_TextUI_Command::main() /usr/bin/php=
unit:52<br>&nbsp;&nbsp;&nbsp; 0.2302&nbsp;&nbsp;&nbsp;
 7198832&nbsp;&nbsp; 3. PHPUnit_TextUI_Command-&gt;run() /usr/share/php/PHP=
Unit/TextUI/Command.php:147<br>&nbsp;&nbsp;&nbsp; 0.2322&nbsp;&nbsp;&nbsp; =
7203088&nbsp;&nbsp; 4. PHPUnit_Runner_BaseTestRunner-&gt;getTest() /usr/sha=
re/php/PHPUnit/TextUI/Command.php:168<br>&nbsp;&nbsp;&nbsp; 0.2322&nbsp;&nb=
sp;&nbsp; 7203496&nbsp;&nbsp; 5. PHPUnit_Runner_BaseTestRunner-&gt;loadSuit=
eClass() /usr/share/php/PHPUnit/Runner/BaseTestRunner.php:112<br>&nbsp;&nbs=
p;&nbsp; 0.2322&nbsp;&nbsp;&nbsp; 7204640&nbsp;&nbsp; 6. PHPUnit_Runner_Sta=
ndardTestSuiteLoader-&gt;load() /usr/share/php/PHPUnit/Runner/BaseTestRunne=
r.php:170<br>&nbsp;&nbsp;&nbsp; 0.2324&nbsp;&nbsp;&nbsp; 7267184&nbsp;&nbsp=
; 7. PHPUnit_Util_Fileloader::checkAndLoad() /usr/share/php/PHPUnit/Runner/=
StandardTestSuiteLoader.php:102<br>&nbsp;&nbsp;&nbsp; 0.2324&nbsp;&nbsp;&nb=
sp; 7267680&nbsp;&nbsp; 8. PHPUnit_Util_Fileloader::load() /usr/share/php/P=
HPUnit/Util/Fileloader.php:91<br>&nbsp;&nbsp;&nbsp;
 0.2331&nbsp;&nbsp;&nbsp; 7311400&nbsp;&nbsp; 9. include_once('/home/padrai=
c/projects/zf/trunk/tests/Zend/Feed/AllTests.php') /usr/share/php/PHPUnit/U=
til/Fileloader.php:113<br>&nbsp;&nbsp;&nbsp; 0.6806&nbsp;&nbsp; 11464144&nb=
sp; 10. require_once('/home/padraic/projects/zf/trunk/tests/Zend/Feed/Reade=
rTest.php') /home/padraic/projects/zf/trunk/tests/Zend/Feed/AllTests.php:48=
<br>&nbsp;&nbsp;&nbsp; 0.7001&nbsp;&nbsp; 11727944&nbsp; 11. require_once('=
/home/padraic/projects/zf/trunk/library/Zend/Feed/Reader.php') /home/padrai=
c/projects/zf/trunk/tests/Zend/Feed/ReaderTest.php:24<br>&nbsp;&nbsp;&nbsp;=
 0.7180&nbsp;&nbsp; 11966176&nbsp; 12. require_once('/home/padraic/projects=
/zf/trunk/library/Zend/Feed/Reader/Feed/Rss.php') /home/padraic/projects/zf=
/trunk/library/Zend/Feed/Reader.php:30<br>&nbsp;&nbsp;&nbsp; 0.7188&nbsp;&n=
bsp; 12045672&nbsp; 13. require_once('/home/padraic/projects/zf/trunk/libra=
ry/Zend/Feed/Reader/FeedAbstract.php')
 /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Rss.php:25<b=
r>&nbsp;&nbsp;&nbsp; 0.7200&nbsp;&nbsp; 12176712&nbsp; 14. require_once('/h=
ome/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Entry/Atom.php') /ho=
me/padraic/projects/zf/trunk/library/Zend/Feed/Reader/FeedAbstract.php:30<b=
r>&nbsp;&nbsp;&nbsp; 0.7277&nbsp;&nbsp; 12490040&nbsp; 15. require_once('/h=
ome/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Extension/Atom/Entry=
.php') /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Entry/Atom.=
php:40<br>&nbsp;&nbsp;&nbsp; 0.9154&nbsp;&nbsp; 17272344&nbsp; 16. require_=
once('/home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom/So=
urce.php') /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Extensi=
on/Atom/Entry.php:50<br>&nbsp;&nbsp;&nbsp; 0.9166&nbsp;&nbsp; 17404288&nbsp=
; 17. require_once('/home/padraic/projects/zf/trunk/library/Zend/Feed/Reade=
r/Feed/Atom.php')
 /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom/Source.=
php:25<br><br>Note: Just be aware that Zend_Feed_Reader uses no code from Z=
end_Feed (the original component). ZFR uses its own interfaces and abstract=
s.<br><br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font sty=
le=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><span =
style=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span sty=
le=3D"font-style: italic;"><font style=3D"font-family: times new roman,new =
york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D=
"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a rel=
=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com">h=
ttp://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_blank=
" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Repre=
sentative</a><br></font></span></span><div><br></div>=0A<!-- cg3.c902.mail.=
ac4.yahoo.com compressed/chunked Tue Nov 24 14:20:52 PST 2009 -->=0A</div><=
/body></html>
--0-1603841984-1259418604=:95126--

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 13:41:59 -0800
From: Kevin McArthur <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

This is a multi-part message in MIME format.
--------------070304040603060504000207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Reply inline.

Matthew Weier O'Phinney wrote:
> <snip>
>
> That makes sense, and I'm open to that. 
>
> That said, if a component has dependencies on other components or makes
> use of other components, I think the pattern should be mandatory.
> Dependency Injection -- note, I'm NOT saying DI containers -- is much
> simpler with this pattern.
>
>   
Can we define components? Classes within their own namespace? If so, I'm cool with that. Off the top of my head my main thinking is like PDF Points, Rects, Cirlces etc... these make no sense to be 'configurable'. But they all exist within their own namespace.  Configuration standards when crossing namespaces... that makes sense.

> The rationale is because it allows us to catch either based on the SPL
> exception type OR the component exception type. It's more flexible.
>
> Each component Exception would inherit from the zend\Exception marker
> interface -- so, again, there'd still be the Exception inheritance
> hierarchy, but also a hierarchy for general purpose exceptions.
>
> Finally, the paradigm encourages creating exceptions for each type of
> exceptional situation, instead of having a generic exception per
> component. This will make debugging easier, as well as 
>
> As an example, using an SPL-based exception:
>
>     try {
>         throw new InvalidArgumentException();
>     } catch (\zend\foo\Exception $e) {        // or
>     } catch (\zend\Exception $e) {            // or
>     } catch (\InvalidArgumentException $e) {  // or
>     } catch (\Exception $e) {
>     }
>
> All are viable - it gives you, the developer, more choices in how you
> handle exceptions.
>   
So we're trying to add an extra catch-case for zend specific exceptions? 
If so dont we already have Zend_Exception? I don't see any reason not to 
do this, but then, I'm not sure its really necessary? With autoloading 
the overhead should be relatively small (classes arent computed till 
needed)... so... whatever?

>
> Ummmmm.... I don't think we're talking about the same thing here.
>   
We are.
> Design by contract, in its most simplified form, refers to the idea of
> programming to interfaces. This simply means that we'll be ensuring that
> we have solid, concise interfaces for each component, which will allow
> developers to create their own implementations when they're needs
> deviate from those shipped.
>
>   
The issue is that programming by contract adds little value when applied 
universally (i've got some really nasty db-binding interfaces growing 
around here)

Interfaces are useful sure, but like tests, they're only useful when 
written from a different perspective than the implementation. My attempt 
to fix a bug in zend's wildfire layer only to run into a case where a 
test checked for not implemented as a response being a prime example. 
The same will happen with rigid interfaces as with rigid tests.

I strongly suggest only using interfaces where there are actual points 
of interoperability, instead of for each public method for example.
> This actually will have some substantial benefits. First, we can have a
> more conventions based approach, which allows us to develop more
> targetted, performant code since we're no longer worrying about edge
> cases created by configurability. This brings me to my second point: it
> pushes the burden of custom and fringe use cases onto individual
> developers instead of the framework -- which allows us to focus on
> maintaining the core functionality. This will lead to a better product
> with fewer open issues. Third, it makes testing much easier,
> particularly when considering components with adapters -- you can
> implement a given interface in order to test the functionality instead
> of needing to override an existing class.
>   
I agree that it makes testing easier, but disagree that it leads to 
performance. Loading large interfaces (picture the size of an interface 
for Zend_Pdf or Zend_Db for examples) .... really adds to loading 
overhead.  Also, if you start really talking about interfaces and DI, 
you get into a lot of runtime use of the instanceof operator -- and that 
saps performance too.
> In terms of contribution overhead, it means that part of any component
> design will be ascertaining the basic, essential functionality and
> creating an interface that encapsulates it; this is just good
> programming.
>   
This is where it will get in the way. Now not only do you have to write 
the code you want to contribute (something many of us do as an ancillary 
benefit to 'Actually Getting Stuff Done') but also an Interface, Tests, 
Documentation and probably some ZF tracker stuff. Wow, overhead. I don't 
have time for it -- and I'm not alone in that, I assure you. Don't get 
me wrong, its nice to have all those things, but not at the expense of 
the actual functionality getting checked in. Maybe I'm ****ing in the 
wind, but can we try to lower the contribution overhead? I'm willing to 
send in commented, code-level patches as I go about my normal dev, but 
those who sponsor that work aren't willing to pay for me to write tests 
and docs for the stuff I improve. This leads to most of my zfw 
improvements going uncontributed, or when they encompass major libs, 
forked off from the core and released independently where they don't do 
as many people as good as they could if they were part of zfw.

> Basically, everything you cite as potential problems are actually
> addressed with this decision
>   
>> 4) Getting rid of singletons.
>>
>> Why does it make more sense to access the front controller via a registry?
>> Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier
>> to pick up the framework.
>>     
>
> We're not accessing the front controller via a registry. It's simply not
> going to be a singleton. The ideas posted use injection to pass objects
> around, and do so in a very simple manner. Take a look at the
> proof-of-concept I posted before jumping to conclusions.
>
> Singletons have been the source of a ton of pain in testing and
> bugfixing -- and there's very little reason for most of them to exist.
>
>   
I'm poking around in it, but I'm not sure I see how 'the' front 
controller will be accessed. Whats the equivilent call to 
Zend_Controller_Front::getInstance().... somewhere's gonna have to be a 
registry (or at least a responsible object) if thats not singleton-ized.

I'm looking at
http://github.com/weierophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php
for example, and I definitely don't think this is easier to grasp than 
the singleton fc approach.
>> The Ugly:
>>
>> The proposed changes to the core api (and to a large extent the framework
>> additions since 1.0) really add complexity to the framework to the benefit of
>> testing and other 'advanced' use. 
>>     
>
> We're getting rid of complexity and focussing on a simplified,
> consistent API. I fail to see how you're reaching your conclusions.
>   
Maybe you see it that way... I'm not sure I do. The DI stuff is 
definitely not straightforward compared to whats there now. The comment 
refers to the new things since 1.0 really that haven't helped make
things better. See the end of (a) below. The <=1.0 line was dead simple, 
wasn't much use of helpers, plugins, brokers, registries etc... 
everything kinda flowed from a->b->c and it was more mvc-ish in its code 
separation. now its definitely a lot more RDMVCHP.. 
(router-dispatcher-model-view-controller-helper-plugin) ... add a few 
layers of Zend_Application+Zend_Config integration and the like and it 
gets even worse.

>   
>> These changes do little, if anything to advance three goals I see as
>> core requirements for 2.0:
>>
>> a) Can a skilled PHP developer read and understand Zend Framework application
>> code without more than an hour's primer on ZFW? Could they trace execution of
>> the framework logically without a debugger? Jumps like GOTO's, fancy routers,
>> registries, helpers, plugins, and DI models all work against this goal. Keep it
>> simple.
>>     
>
> Please, please, please read the code and examples before you make these
> assumptions.
>   
I have read what is linked from that page you posted. So some of this 
might be assumption, but im not sure much is.
> The new MVC design is not going to be something a developer will need to
> understand in order to use it; they will simply need to *use* it.
I don't agree with this. IMHO, If you can't trace it under the hood -- 
it's too complicated. I can't stress enough how important it is for 
people working with ZFW to actually
understand how ZFW works, and to be able to trace their application's 
execution conceptually. PHP isn't an SDK language and ZFW shouldn't aim 
to be a SDK framework. The whole execution process should follow an 
easily traced path from start to finish.

>  They won't need to know that it uses a finite state machine under the hood --
> they'll only need to know what events and states are available (and
> there's *ahem* a finite number of them). Tracing the code execution
> should rarely be necessary, but the new prototype is actually far, far
> simpler than the current Zend_Controller execution cycle.
>   
I disagree. I think its important that the average user can _easily_ 
understand how the application works through all phases of execution.

>> b) Can a skilled PHP developer contribute a change to the framework easily
>> without being involved in the ZFW core politics, contribution processes,
>> proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for
>> this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to
>> reduce the contribution overhead and encourage community participation?
>>     
>
> Please elaborate on how "ZFW sucks for this."
> Our policy has been that contributions require unit tests and
> documentation, plain and simple. Yes, it's a barrier to entry -- but it
> also helps to ensure the quality of the code and that users have the
> information they need to use it. If we don't require that level of
> contribution, we'll be doing everyone a dis-service.
> Right now, there really are no "core politics". Everything goes through
> the contribution process. Yes, myself and my team help determine the
> roadmap -- but even the roadmap is open for discussion. This is open
> source.
>
>   

See previous comments on the interface stuff. Same stuff applies.

>> c) Can a ZFW developer create products and services that leverage ZFW in an
>> ecosystem of components? Is there a financial incentive for this? Currently,
>> there's very little going on in terms of commercialized redistributable
>> components -- How will ZFW 2.0 create, and integrate itself into a marketplace
>> for ZFW apps, components, and tools? Official ZFW app/component store? ZFW
>> cloud services?
>>     
>
> My team has had zero time to focus on a forge-like site for components,
> though it's something we'd all like to see.  A large part of the reason
> for our lack of time is due to the amount of maintenance required on ZF.
> Most of the changes proposed for 2.0 are intended to lighten that
> burden, which would make the above much more possible in the future.
>   
Fair enough, though, I'm less concerned with the 'forge' site and more 
concerned about flushing out the component model (packs, modules, 
phars?, plugins... what are we calling an encapsulated archive of zfw 
'stuff' now). That should definitely be considered pre-2.0 as it will 
require considerations on everything from routers, dispatchers, layouts, 
controllers and views.
>   
>> The Atrocious:
>>
>> Still nothing about an upgrading / security patches system. 
>>     
>
> This is my bad -- I meant to include information on this as part of the
> proposal. A big effort for 2.0 will be creating resources to aid in
> migration. A big part of the MVC proof of concept was creating something
> that could live side-by-side the current implementation and potentially
> even make use of it (the demo uses a number of existing components).
> We're taking that very seriously.
>   
:) Glad to hear this.
> As for security patches, the plan is to patch existing stable code, as
> well as the previous 2 minor branches, and make releases of each.
>   
A good first step as I said below, but we need the USN's, the 'is this 
site afflicted' data. (Eg does line x of /library/zend/whatever.php = 
this, if so, vuln)... we need this type of data on an ongoing basis to 
build out the tools -> see below..

>   
>> Still no components for detecting if an application is vulnerable,
>> notifying system admins, or shutting down an installed base of
>> vulnerable apps dependent on the framework.  If the problems of the
>> other major framework and cms vendors continue to be ignored, there
>> will almost certainly be some sort of incident that will tarnish the
>> frameworks reputation for security. At some point the framework is
>> going to have to take version management more seriously than
>> publishing patches to the website (a good first step, but miles away
>> from where it needs to be).
>>     
>
> If you're interested in such components, then please help make them a
> possibility. Don't expect everyone else to do the work for you. As
> noted, my team is small and our resources spread thin. Help us and the
> rest of the community out.
>   
I don't expect them to, and I've been trying to help get this done for 
some time. That said, theres no tool I can make without vulnerability 
data. There's no disclosure list, no feed or web service that we could 
script against. This has to come from the release management side of 
things. I've had some productive discussions about doing the scripting 
within the Zend_Tool framework -- but thats as far as it gets.

If you publish the data, I'll write the tools (though, i'll leave it to 
your team to write the tests <grin>)

Ideally a csv (or xml) like....

ZFV (zend framework vulnerability) Number  | File | Line | Match | Patch 
| Remarks
ZFV-123 | library/Zend/Whatever.php | 12 | if($this->somethingIsBad) | 
ZFV-123.patch | You'll have to also change your bootstrap from this to 
that.

Given that, we can write sites, and potentially tools that would check 
themselves automatically.

I've previously proposed adding this to Zend_Version, but maybe theres a 
more appropriate place?  IMHO this should be a 2.0 line build requirement.

>> --
>>
>> I'd also add that there's probably an opportunity to look at phar-ization
>> within the 2.0 line. Will the new loader support phar'd components, and how
>> will that look? Zend_Tool? Configurable site images?
>>     
>
> I've already experimented with Phar and ZF 1.X. It requires minimal
> changes to the autoloader for it to work out of the box.
>   
OooOOo gimme gimme.... Docs, blog post? How does it work with overlaying 
views, layouts, controllers, models, extending/replacing core zend 
libraries, etc?

Anyway, hope that elaborates and is more helpful than it is not =P

Kevin

--------------070304040603060504000207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Reply inline.<br>
<br>
Matthew Weier O'Phinney wrote:
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">&lt;snip&gt;<br>
  <pre wrap=""><!---->
That makes sense, and I'm open to that. 

That said, if a component has dependencies on other components or makes
use of other components, I think the pattern should be mandatory.
Dependency Injection -- note, I'm NOT saying DI containers -- is much
simpler with this pattern.

  </pre>
</blockquote>
<pre wrap="">Can we define components? Classes within their own namespace? If so, I'm cool with that. Off the top of my head my main thinking is like PDF Points, Rects, Cirlces etc... these make no sense to be 'configurable'. But they all exist within their own namespace.  Configuration standards when crossing namespaces... that makes sense.
</pre>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
The rationale is because it allows us to catch either based on the SPL
exception type OR the component exception type. It's more flexible.

Each component Exception would inherit from the zend\Exception marker
interface -- so, again, there'd still be the Exception inheritance
hierarchy, but also a hierarchy for general purpose exceptions.

Finally, the paradigm encourages creating exceptions for each type of
exceptional situation, instead of having a generic exception per
component. This will make debugging easier, as well as 

As an example, using an SPL-based exception:

    try {
        throw new InvalidArgumentException();
    } catch (\zend\foo\Exception $e) {        // or
    } catch (\zend\Exception $e) {            // or
    } catch (\InvalidArgumentException $e) {  // or
    } catch (\Exception $e) {
    }

All are viable - it gives you, the developer, more choices in how you
handle exceptions.
  </pre>
</blockquote>
So we're trying to add an extra catch-case for zend specific
exceptions? If so dont we already have Zend_Exception? I don't see any
reason not to do this, but then, I'm not sure its really necessary?
With autoloading the overhead should be relatively small (classes arent
computed till needed)... so... whatever?<br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap=""><!---->
Ummmmm.... I don't think we're talking about the same thing here.
  </pre>
</blockquote>
We are.<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">Design by contract, in its most simplified form, refers to the idea of
programming to interfaces. This simply means that we'll be ensuring that
we have solid, concise interfaces for each component, which will allow
developers to create their own implementations when they're needs
deviate from those shipped.

  </pre>
</blockquote>
The issue is that programming by contract adds little value when
applied universally (i've got some really nasty db-binding interfaces
growing around here)<br>
<br>
Interfaces are useful sure, but like tests, they're only useful when
written from a different perspective than the implementation. My
attempt to fix a bug in zend's wildfire layer only to run into a case
where a test checked for not implemented as a response being a prime
example. The same will happen with rigid interfaces as with rigid tests.<br>
<br>
I strongly suggest only using interfaces where there are actual points
of interoperability, instead of for each public method for example.<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">This actually will have some substantial benefits. First, we can have a
more conventions based approach, which allows us to develop more
targetted, performant code since we're no longer worrying about edge
cases created by configurability. This brings me to my second point: it
pushes the burden of custom and fringe use cases onto individual
developers instead of the framework -- which allows us to focus on
maintaining the core functionality. This will lead to a better product
with fewer open issues. Third, it makes testing much easier,
particularly when considering components with adapters -- you can
implement a given interface in order to test the functionality instead
of needing to override an existing class.
  </pre>
</blockquote>
I agree that it makes testing easier, but disagree that it leads to
performance. Loading large interfaces (picture the size of an interface
for Zend_Pdf or Zend_Db for examples) .... really adds to loading
overhead.&nbsp; Also, if you start really talking about interfaces and DI,
you get into a lot of runtime use of the instanceof operator -- and
that saps performance too.<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
In terms of contribution overhead, it means that part of any component
design will be ascertaining the basic, essential functionality and
creating an interface that encapsulates it; this is just good
programming.
  </pre>
</blockquote>
This is where it will get in the way. Now not only do you have to write
the code you want to contribute (something many of us do as an
ancillary benefit to 'Actually Getting Stuff Done') but also an
Interface, Tests, Documentation and probably some ZF tracker stuff.
Wow, overhead. I don't have time for it -- and I'm not alone in that, I
assure you. Don't get me wrong, its nice to have all those things, but
not at the expense of the actual functionality getting checked in.
Maybe I'm ****ing in the wind, but can we try to lower the contribution
overhead? I'm willing to send in commented, code-level patches as I go
about my normal dev, but those who sponsor that work aren't willing to
pay for me to write tests and docs for the stuff I improve. This leads
to most of my zfw improvements going uncontributed, or when they
encompass major libs, forked off from the core and released
independently where they don't do as many people as good as they could
if they were part of zfw. <br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
Basically, everything you cite as potential problems are actually
addressed with this decision
  </pre>
</blockquote>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <blockquote type="cite">
    <pre wrap="">4) Getting rid of singletons.

Why does it make more sense to access the front controller via a registry?
Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier
to pick up the framework.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
We're not accessing the front controller via a registry. It's simply not
going to be a singleton. The ideas posted use injection to pass objects
around, and do so in a very simple manner. Take a look at the
proof-of-concept I posted before jumping to conclusions.

Singletons have been the source of a ton of pain in testing and
bugfixing -- and there's very little reason for most of them to exist.

  </pre>
</blockquote>
I'm poking around in it, but I'm not sure I see how 'the' front
controller will be accessed. Whats the equivilent call to
Zend_Controller_Front::getInstance().... somewhere's gonna have to be a
registry (or at least a responsible object) if thats not singleton-ized.<br>
<br>
I'm looking at <br>
<a class="moz-txt-link-freetext" href="http://github.com/weierophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php">http://github.com/weierophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php</a><br>
for example, and I definitely don't think this is easier to grasp than
the singleton fc approach.<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">The Ugly:

The proposed changes to the core api (and to a large extent the framework
additions since 1.0) really add complexity to the framework to the benefit of
testing and other 'advanced' use. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
We're getting rid of complexity and focussing on a simplified,
consistent API. I fail to see how you're reaching your conclusions.
  </pre>
</blockquote>
Maybe you see it that way... I'm not sure I do. The DI stuff is
definitely not straightforward compared to whats there now. The comment
refers to the new things since 1.0 really that haven't helped make<br>
things better. See the end of (a) below. The &lt;=1.0 line was dead
simple, wasn't much use of helpers, plugins, brokers, registries etc...
everything kinda flowed from a-&gt;b-&gt;c and it was more mvc-ish in
its code separation. now its definitely a lot more RDMVCHP..
(router-dispatcher-model-view-controller-helper-plugin) ... add a few
layers of Zend_Application+Zend_Config integration and the like and it
gets even worse.<br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">These changes do little, if anything to advance three goals I see as
core requirements for 2.0:

a) Can a skilled PHP developer read and understand Zend Framework application
code without more than an hour's primer on ZFW? Could they trace execution of
the framework logically without a debugger? Jumps like GOTO's, fancy routers,
registries, helpers, plugins, and DI models all work against this goal. Keep it
simple.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Please, please, please read the code and examples before you make these
assumptions.
  </pre>
</blockquote>
I have read what is linked from that page you posted. So some of this
might be assumption, but im not sure much is.<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
The new MVC design is not going to be something a developer will need to
understand in order to use it; they will simply need to *use* it.</pre>
</blockquote>
I don't agree with this. IMHO, If you can't trace it under the hood --
it's too complicated. I can't stress enough how important it is for
people working with ZFW to actually <br>
understand how ZFW works, and to be able to trace their application's
execution conceptually. PHP isn't an SDK language and ZFW shouldn't aim
to be a SDK framework. The whole execution process should follow an
easily traced path from start to finish.<br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap=""> They won't need to know that it uses a finite state machine under the hood --
they'll only need to know what events and states are available (and
there's *ahem* a finite number of them). Tracing the code execution
should rarely be necessary, but the new prototype is actually far, far
simpler than the current Zend_Controller execution cycle.
  </pre>
</blockquote>
I disagree. I think its important that the average user can _easily_
understand how the application works through all phases of execution.<br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">b) Can a skilled PHP developer contribute a change to the framework easily
without being involved in the ZFW core politics, contribution processes,
proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for
this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to
reduce the contribution overhead and encourage community participation?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Please elaborate on how "ZFW sucks for this."</pre>
</blockquote>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
Our policy has been that contributions require unit tests and
documentation, plain and simple. Yes, it's a barrier to entry -- but it
also helps to ensure the quality of the code and that users have the
information they need to use it. If we don't require that level of
contribution, we'll be doing everyone a dis-service.</pre>
</blockquote>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">Right now, there really are no "core politics". Everything goes through
the contribution process. Yes, myself and my team help determine the
roadmap -- but even the roadmap is open for discussion. This is open
source.

  </pre>
</blockquote>
<pre wrap="">
</pre>
See previous comments on the interface stuff. Same stuff applies.<br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <blockquote type="cite">
    <pre wrap="">c) Can a ZFW developer create products and services that leverage ZFW in an
ecosystem of components? Is there a financial incentive for this? Currently,
there's very little going on in terms of commercialized redistributable
components -- How will ZFW 2.0 create, and integrate itself into a marketplace
for ZFW apps, components, and tools? Official ZFW app/component store? ZFW
cloud services?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
My team has had zero time to focus on a forge-like site for components,
though it's something we'd all like to see.  A large part of the reason
for our lack of time is due to the amount of maintenance required on ZF.
Most of the changes proposed for 2.0 are intended to lighten that
burden, which would make the above much more possible in the future.
  </pre>
</blockquote>
Fair enough, though, I'm less concerned with the 'forge' site and more
concerned about flushing out the component model (packs, modules,
phars?, plugins... what are we calling an encapsulated archive of zfw
'stuff' now). That should definitely be considered pre-2.0 as it will
require considerations on everything from routers, dispatchers,
layouts, controllers and views.<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">The Atrocious:

Still nothing about an upgrading / security patches system. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This is my bad -- I meant to include information on this as part of the
proposal. A big effort for 2.0 will be creating resources to aid in
migration. A big part of the MVC proof of concept was creating something
that could live side-by-side the current implementation and potentially
even make use of it (the demo uses a number of existing components).
We're taking that very seriously.
  </pre>
</blockquote>
:) Glad to hear this.<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
As for security patches, the plan is to patch existing stable code, as
well as the previous 2 minor branches, and make releases of each.
  </pre>
</blockquote>
A good first step as I said below, but we need the USN's, the 'is this
site afflicted' data. (Eg does line x of /library/zend/whatever.php =
this, if so, vuln)... we need this type of data on an ongoing basis to
build out the tools -&gt; see below..<br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">Still no components for detecting if an application is vulnerable,
notifying system admins, or shutting down an installed base of
vulnerable apps dependent on the framework.  If the problems of the
other major framework and cms vendors continue to be ignored, there
will almost certainly be some sort of incident that will tarnish the
frameworks reputation for security. At some point the framework is
going to have to take version management more seriously than
publishing patches to the website (a good first step, but miles away
from where it needs to be).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
If you're interested in such components, then please help make them a
possibility. Don't expect everyone else to do the work for you. As
noted, my team is small and our resources spread thin. Help us and the
rest of the community out.
  </pre>
</blockquote>
I don't expect them to, and I've been trying to help get this done for
some time. That said, theres no tool I can make without vulnerability
data. There's no disclosure list, no feed or web service that we could
script against. This has to come from the release management side of
things. I've had some productive discussions about doing the scripting
within the Zend_Tool framework -- but thats as far as it gets.<br>
<br>
If you publish the data, I'll write the tools (though, i'll leave it to
your team to write the tests &lt;grin&gt;)<br>
<br>
Ideally a csv (or xml) like....<br>
<br>
ZFV (zend framework vulnerability) Number&nbsp; | File | Line | Match |
Patch | Remarks<br>
ZFV-123 | library/Zend/Whatever.php | 12 | if($this-&gt;somethingIsBad)
| ZFV-123.patch | You'll have to also change your bootstrap from this
to that. <br>
<br>
Given that, we can write sites, and potentially tools that would check
themselves automatically.<br>
<br>
I've previously proposed adding this to Zend_Version, but maybe theres
a more appropriate place?&nbsp; IMHO this should be a 2.0 line build
requirement. <br>
<br>
<br>
<blockquote cite="mid:20091112194129.GV8321@localhost" type="cite">
  <blockquote type="cite">
    <pre wrap="">--

I'd also add that there's probably an opportunity to look at phar-ization
within the 2.0 line. Will the new loader support phar'd components, and how
will that look? Zend_Tool? Configurable site images?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I've already experimented with Phar and ZF 1.X. It requires minimal
changes to the autoloader for it to work out of the box.
  </pre>
</blockquote>
OooOOo gimme gimme.... Docs, blog post? How does it work with
overlaying views, layouts, controllers, models, extending/replacing
core zend libraries, etc?<br>
<br>
Anyway, hope that elaborates and is more helpful than it is not =P<br>
<br>
Kevin<br>
<br>
<br>
</body>
</html>

--------------070304040603060504000207--

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
Date: Tue, 16 Mar 2010 08:45:04 +0000
Cc: "Zend Framework Contributors" <[email-masked]>
To: Ralph Schindler <[email-masked]>
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

On 16 Mar 2010, at 06:31, Ralph Schindler wrote:

> The question with namespaces is, should we use compound names to =
identify classes separate of the namespace itself.  This can be better =
demonstrated with the following code:
>=20
>=20
> use Zend\Filter as f;
> $filter =3D new f\Int();
>=20
> -- VS --
>=20
> use Zend\Filter as f;
> $filter =3D new f\IntFilter();
>=20
>=20
> In the latter example, the original class name (without the prefix) =
might have been Int, but this class name has been 'suffixed' with a term =
that gives the class name more meaning.  (In english, this means that =
the class name now has the adjective 'Int' and the noun 'Filter', or a =
noun-noun combination).
>=20
> Which is a better route to explore in your opinion? Which has more =
meaning to you as a developer consuming ZF?

Personally I prefer explicitness in my code, so if I actually used =
aliasing, I would be more likely to do:

use Zend as z;
$intFilter =3D new Filter\Int();

The problem from my point of view is that the use statement is likely to =
be right at the top of the file and the instantiation could be 100 lines =
further down. By then, I'll have have forgotten what "f" is. It's a =
certainty that I'll have forgotten in 6 months time when I come back to =
maintain it :)

As a result, I don't like the redundancy of repeating the namespace in =
the class name. It'll be more tying for no benefit. Having said that, =
it's not something I'm especially passionate about as we'll be fully =
qualifying in our code.

Regards,

Rob...

--=20
Rob Allen : http://akrabat.com
Zend Framework Tutorial: http://akrabat.com/zft
Author of Zend Framework in Action: http://www.zendframeworkinaction.com

nFrom nobody Wed Apr  7 08:46:07 2010
From: "Whitcraft, Jon" <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>,
	"[email-masked]" <[email-masked]>
Date: Thu, 8 Oct 2009 15:25:32 -0400
Subject: RE: [zf-contributors] Code Review
Accept-Language: en-US
acceptlanguage: en-US

Matthew,

Sounds good.  I just wanted to throw the idea out there.  I was just lookin=
g around Atlassian's site and noticed that.

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]
Phone: (317) 492-8623 :: Fax: (317) 492-6419

-----Original Message-----
From: Matthew Weier O'Phinney [mailto:[email-masked]]
Sent: Thursday, October 08, 2009 3:19 PM
To: [email-masked]
Subject: Re: [zf-contributors] Code Review

-- Whitcraft, Jon <[email-masked]> wrote
(on Thursday, 08 October 2009, 03:11 PM -0400):
> I have been thinking about the problem that ZF ran into right after 1.9.3=
 was
> release a few weeks ago and then we had to rush a 1.9.3pl1 into release. =
 Would
> using a tool such as Crucible from Atlassian help with this problem?
>
> What does everyone else think?

In this case, it might not have helped.

There were no tests for the original behavior, and it was not documented
in the manual either -- it was only documented in passing within the API
docs.

We may use Crucible in the future (we actually have it setup already),
but I want to explore a few other options as well.

(My personal experience with Crucible has not been great, but I have
hope that it can be configured to work better.)

--
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 15 Apr 2009 21:36:12 +0100
From: Ryan Mauger <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Proposal to add validation and filtering to the
	getParam method of Zend_Controller_Request_Abstract

Good day to you all!

After some discussion on IRC, there is now a proposal to update the
getParam method in the Request object, to allow validation and filtering.

Please comment the proposal  @
http://framework.zend.com/wiki/display/ZFPROP/Zend_Controller_Request+-+Add+validation+and+filtering+to+getParam()

Regards
Ryan Mauger

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 8 Apr 2009 09:29:52 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 1.8 Preview Release is released

-- Tobias Gies <[email-masked]> wrote
(on Wednesday, 08 April 2009, 02:20 PM +0200):
> When will it be announced on fw-general?

This morning. 

> 2009/4/8 Matthew Weier O'Phinney <[email-masked]>:
> > Greetings, all!
> >
> > I've just finished releasing the 1.8 preview release, and you can
> > download it from http://framework.zend.com/download/latest. The manual
> > has also been updated to reflect the new functionality.
> >
> > On that note, there was a snafu when merging in the ZendX documentation.
> > Alex will hit that first thing in the morning so that it's present. If
> > you see any other anomolies, please send an email in reply to this one.
> >
> > Thanks everyone for all the hard work in getting contributions ready for
> > this milestone. Let's work on polishing it and getting additional
> > bugfixes in before the final release later this month!

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 8 Oct 2009 15:15:19 -0700
From: Trevor Johns <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] mailing list for contributors doesn't work on 
	framework.zend.com

On Thu, Oct 8, 2009 at 11:38 AM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Whitcraft, Jon <[email-masked]> wrote
> (on Thursday, 08 October 2009, 02:20 PM -0400):
>> I believe that is because this list is not archived. =C2=A0I may be
>> mistaken with that but Matthew or Ralph should know better than I.
>
> Not sure why it's not; looking into it.
>

FWIW, there's an archive of this list at GMane:

http://dir.gmane.org/gmane.comp.php.zend.framework.contributors

--=20
Trevor Johns

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 29 Jan 2010 09:23:27 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF-8938

--0016e6d7eb68927701047e495935
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 28, 2010 at 11:52 PM, Andy Fowler <[email-masked]> wrote:

> I created http://framework.zend.com/issues/browse/ZF-8938 and added a
> patch (including unit tests), fixing instances where Zend_Form would corrupt
> values and validation messages when a form had a numeric name.
>

Are you sure numeric names should be accepted? I reported a similar issue
and Matthew pointed out that numeric form names would break overloading of
properties:
http://framework.zend.com/issues/browse/ZF-6062
For instance $form->2 when $form has a subform with a numeric name would not
work.
If numeric form names have been re-evaluated I hope also #6062 can be fixed.

Regards,
-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d7eb68927701047e495935
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jan 28, 2010 at 11:52 PM, Andy Fowler <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">lists@andyfowle=
r.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"b=
order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin=
g-left: 1ex;">

I created <a href=3D"http://framework.zend.com/issues/browse/ZF-8938" targe=
t=3D"_blank">http://framework.zend.com/issues/browse/ZF-8938</a> and added =
a patch (including unit tests), fixing instances where Zend_Form would corr=
upt values and validation messages when a form had a numeric name.<br>
</blockquote></div><br clear=3D"all">Are you sure numeric names should be a=
ccepted? I reported a similar issue and Matthew pointed out that numeric fo=
rm names would break overloading of properties:<br><a href=3D"http://framew=
ork.zend.com/issues/browse/ZF-6062">http://framework.zend.com/issues/browse=
/ZF-6062</a><br>
For instance $form-&gt;2 when $form has a subform with a numeric name would=
 not work.<br>If numeric form names have been re-evaluated I hope also #606=
2 can be fixed.<br><br>Regards,<br>-- <br>Giorgio Sironi<br>Piccolo Princip=
e &amp; Web Engineer<br>
<a href=3D"http://giorgiosironi.blogspot.com">http://giorgiosironi.blogspot=
.com</a><br><a href=3D"http://twitter.com/giorgiosironi">http://twitter.com=
/giorgiosironi</a><br>

--0016e6d7eb68927701047e495935--

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 23 Mar 2010 10:51:32 +0100
From: Julien Pauli <[email-masked]>
To: Giorgio Sironi <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] use statements -- usage?

Agree to have strict rules to name namespaces with "use" key word, so
that we can guess them easilly

J.Pauli

On Mon, Mar 22, 2010 at 11:06 PM, Giorgio Sironi
<[email-masked]> wrote:
> This problem does not happen to me very often, because usually are
> more specific components in sub namespaces that. I'm for aliasing them
> all with use statements, since it was decided they must have
> meaningful names (such as use Zend\Filter\Int as IntFilter) which can
> be understood without problems.
>
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Tue, 24 Mar 2009 13:23:45 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.7.8 code freeze period

Hi,

I would like to remind, that ZF 1.7.8 is planned to be launched next
Monday.

So code freeze period will start at end of day Thursday (PST time).

Please do necessary commits and merges into release-1.7 branch before
that or contact me if it's necessary to do such merges during
code-freeze period.

With best regards,
   Alexander Veremyev.

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 14 Sep 2009 13:05:13 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.9.3 scheduled for next week

Greetings, all --

Due to Labor Day in the United States last week throwing my schedule
off, we did not release 1.9.3 last Tuesday as originally scheduled.

Instead of releasing it this week, we have decided to postpone it to the
fourth Tuesday of the month so we can get back into the regular schedule
(second and fourth Tuesdays of the month). As such, code freeze on the
1.9 branch will start Sunday night, and we will announce once we have
tagged and packaged so that you may resume merging commits.

Thanks for your patience!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Eric Clemmons <[email-masked]>
Date: Tue, 16 Mar 2010 14:38:47 -0500
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

I too prefer to not have shorthand assignments using "AS".  You can dig =
through the Dojo codebase and see all sorts of "d., dc., dq., etc." =
shorthand that ultimately is more confusing, even though it's concise.

There's a balance between having a wall of text because of verbose names =
and obfuscating code via shorthand.  We already know the problems with =
nondescript variable names.  Let's not fall into the same bad practices =
because we have a new toy to play with (namespaces).

On Mar 16, 2010, at 2:26 PM, Ralph Schindler wrote:

> Response inline..
>=20
>>> <?php
>>> // this class has a use statement
>>>=20
>>> namespace Foo;
>>> use Qux\Garply as garp;
>>>=20
>>> class Bar
>>> {
>>> // this method accepts an instance of Qux\Garply\Bar
>>> public static function baz(garp\Bar $bar) {}
>>> }
>> And this one too, though you could "use" whole Qux\Garply\Bar as =
QGBar as well :)
>=20
> This is actually pretty close to my point.
>=20
> It's clear to people consuming Zend Framework classes that Bar inside =
the method signature means Foo\Bar.  The question comes in when people =
are consuming a class that has outside dependencies (like the example =
above).
>=20
> How is a developer suppose to know what the QGBar alias is short for? =
Moreover, if we are to use alias in method signatures, what kind of =
naming convention should be in play?
>=20
> Additionally, do we restrict it to importing full namespaces? Or would =
we allow importing of single classes?  Do we allow importing an aliased =
class into a File and use that inside a method signature?
>=20
> Imagine this:
>=20
> <?php
> namespace Zend\Some\NS;
> use \ArrayObject as Container;
>=20
> class Foo
> {
>   public function doSomething(Container $c);
> }
> ?>
>=20
> This is totally possible, and you could argue that its a superb use of =
namespaces.  Some might argue that it borders on runkit functionality =
(the ability to alias names bit). How is a developer suppose to know =
simply by looking at the method signature that he just needs to supply =
an ArrayObject?
>=20
> Do we simply rely on tools to tell us what Container really means?
>=20
> I totally agree with using "namespace resolved names" for method =
signatures, but I am skeptical on whether using "use resolved names" is =
going to produce easy to use APIs.
>=20
>=20
>=20
>>> One thing to notice is that if method signatures contain a fully
>>> qualified name (those starting with a \) for type hints, you don't =
need
>>> to know anything about what namespaces or aliases are in play;
>>> everything you need to know is right in front of you. However, on =
the
>> I have faith that Framework developers actually can remember inside =
which class and namespace they are :)
>=20
>=20
> By "Framework developers" do you mean people writing ZF code? or =
people consuming ZF code?  I actually don't care about the burden put on =
people writing code for ZF, b/c you only need to write it once.  It's =
the burden put on the consumers of the ZF library of code that I feel is =
more important.
>=20
>=20
>>> Should library/framework specific code be more expressive using =
fully
>>> qualified names in method signatures and consequently in docblocks? =
Or
>>> is using unqualified names just as easy to understand and/or more =
readable?
>> Docblocks present interesting challenge, if they are used for typing =
purposes. I guess there some solution might be needed, but maybe smart =
tools can solve it...
>=20
> I am guessing that docblock class names should probably be using the =
same namespace and use rule resolution that classes use.
>=20
> -ralph

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Sat, 23 Jan 2010 17:16:05 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors]
	=?UTF-8?Q?Zend=5FDate=20=26=20build-in=20class=20Da?=

I compare object oriented APIs around mktime, strtotime and date. Both
Zend_Date and DateTime are more or less wrappers around working with
integers or floats that represent time.

It makes no difference if Zend_Date uses mktime or DateTime internally
or mktime. Its supposed to be an OOP interface around dates. 200 methods
and 4000 LOC, are no real arguments either - DateTime has lots of code
also and most of the methods on Zend_Date are just convenience methods
that make a two-line code snippet to a one-liner. Any class that extends
DateTime could implement them aswell and still be faster.

I do acknowledge the constraints of the original proposal, however still
with lots of refactoring you will never get a Zend_Date implementation
in PHP code that is nearly as fast as an implementation based completly
on DateTime and its ascending classes.

Also I know that ZF 1.x will always be based on 5.2.4, however the
original
question was based on what will be done for ZF 2.0, which obviously will
require PHP 5.3.1 at least.

Since many other frameworks or libraries will use DateTime (Doctrine 2 fo=
r
example)
I think it would be a major drawback for ZF not to build upon DateTime
to push integration possiblities to the edge, as well as recognizing that
using a standard API probably helps adoption alot.

greetings,
Benjamin

On Sat, 23 Jan 2010 11:58:16 +0100, "Thomas Weidner"
<[email-masked]> wrote:
> You are comparing apples with oranges.
> A discussion on such a basis is completly useless.
>=20
> Actually Zend_Date uses mktime. So when you want to compare one=20
> implementation to the other you need to compare mktime to DateTime.
>=20
> And of course you already did a real comparison as you reworked
Zend_Date.=20
> Did you?
>=20
> Just for information... the lack of performance is due to the reason ho=
w
I=20
> was forced to implement the class. A class which is 4500 lines long and
> adds=20
> about 200 methods will never be as performant as a extension which has
has=20
> only 15 methods.
>=20
> When I am not forced to do the API within a few days as with 0.7 and am=
=20
> allowed to rework it as it should be done then even the existing mktime=
=20
> implementation would be multiple times faster.
>=20
> PS: Related to mktime DateTime performs also slower. The real benefit i=
s

> only for calculations beside the 32bit unix timestamp.
>=20
> PPS: Again... as said in past... as long as we are limited to 5.2.4
there=20
> will be no rework due to some major problems which has been solved in
> later=20
> releases.
>=20
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>=20
> ----- Original Message -----=20
> From: "Benjamin Eberlei" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, January 23, 2010 1:36 AM
> Subject: Re: [zf-contributors] Zend_Date & build-in class Da
>=20
>=20
>> =3D?UTF-8?Q?teTime?=3D
>>
>>
>> The only thing DateTime can't handle that Zend_Date can as of 5.3 is
>>
>> localized output
>>
>> and maybe some special features.
>>
>>
>>
>>>From the performance point of view, i have tested three use-cases
against
>>
>> each
>>
>> other:
>>
>>
>>
>> 1. Printing the same instance 100 times
>>
>>
>>
>> $s =3D microtime(true);
>>
>> $d =3D new DateTime("now");
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>   $d->format('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> $date =3D new Zend_Date(1234567890, false);
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>    $date->toString('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> Gives:
>>
>> DateTime 0.0004s
>>
>> Zend_Date 0.0599s
>>
>>
>>
>> 2. Changing the date by Unix-Timestamp on each run for 100 times:
>>
>>
>>
>> $d =3D new DateTime("now");
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>   $d->setTimestamp($now + $i * 7200);
>>
>>   $d->format('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> $date =3D new Zend_Date(1234567890, false);
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>    $date->setTimestamp($now + $i * 7200);
>>
>>    $date->toString('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> Gives:
>>
>> DateTime 0.0010s
>>
>> Zend_Date 0.0591s
>>
>>
>>
>> 3. Changing Date on each call by a defined format (MySQL Database) for
>> 100
>>
>> new instances.
>>
>>
>>
>> Now this is the most evil performance hit.
>>
>>
>>
>> $s =3D microtime(true);
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>   $d =3D DateTime::createFromFormat('Y-m-d H:i:s', '2009-04-01
12:12:12');
>>
>>   $d->format('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>    $date =3D new Zend_Date('2009-04-01 12:12:12', Zend_Date::ISO_8601)=
;
>>
>>    $date->toString('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> DateTime: 0.0020s
>>
>> Zend_Date: 0.1982s
>>
>>
>>
>> DateTime is faster than Zend_Date by a magnitute of 60-100!!
>>
>>
>>
>>
>>
>> On Fri, 22 Jan 2010 15:59:32 -0800 (PST), P=C3=A1draic Brady
>>
>> <[email-masked]> wrote:
>>
>>> Personally I don't see DateTime as massively important to Zend_Date.
It
>>
>>> would be nice to have, but the class itself is pretty basic that I'm
not
>>
>>> sure what exactly it would add to Zend_Date other than offer a
>>
>> (measured?)
>>
>>> performance boost and some import/export functionality for
>>
>> interoperability
>>
>>> (would have been nicer to have a DateTime interface).
>>
>>>
>>
>>>  P=C3=A1draic Brady
>>
>>>
>>
>>> http://blog.astrumfutura.com
>>
>>> http://www.survivethedeepend.com
>>
>>> OpenID Europe Foundation Irish Representative
>>
>>>
>>
>>>
>>
>>>
>>
>>>
>>
>>>
>>
>>> ________________________________
>>
>>> From: Marc Bennewitz <[email-masked]>
>>
>>> To: [email-masked]
>>
>>> Sent: Fri, January 22, 2010 10:16:02 PM
>>
>>> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>>
>>>
>>
>>>  Hi all,
>>
>>>
>>
>>> Does is matter that Zend_Date doesn't extends the build-in DateTime
>>
>>> class ?
>>
>>> -> The DateTime class is available since PHP
>>
>>> 5.2.0 and ZF require PHP 5.2.4.
>>
>>>
>>
>>> It would be very nice because than Zend_Date would be compatible to
>>
>>> other php libraries using DateTime and within ZF tests like the
>>
>>> following can simplify:
>>
>>>
>>
>>> if ($date instanceof Zend_Date_DateObject) {
>>
>>>     $timestamp =3D $date->getUnixTimestamp();
>>
>>> } elseif ($date instanceof DateTime) {
>>
>>>     $timestamp =3D $date->getTimestamp();
>>
>>> } else {
>>
>>>     $timestamp =3D (float)$date;
>>
>>> }
>>
>>>
>>
>>> Greetings,
>>
>>> Marc

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 17 Dec 2009 04:54:14 -0600
From: Greg <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] 2.0 Wishlist

- Controllers as resource type so extending another controller doesn't
incur a require statment to the parent class file.

- Tighter integration of Zend_Application throughout rest of other
Zend_ components.

- View class name configurable via config. A couple of places force an
instance of Zend_View unless the view class has already been
instantiated and set.

- Only create a view instance when needed.

- Personal preference In relation to the latter; any assigned
variables in the controller that are not protected or private are then
automatically assigned to the View class when it is instantiated (i.e.
after the execution of the controller Action method).

- Zend Application options as a Zend_Config object, makes working with
nested arrays easier using the chain syntax.

- Zend_Application to be passed to various other components in
replacement (where appropriate) of the config parameter. The Config
can then be retrieved from Zend_Application and Zend_Application would
also have a method for providing single instances of say Service
objects.

- Ability to override the execution of the part of the Action dispatch
that calls the action method only but still keeps the surrounding pre
and post Dispatch methods untouched.

nFrom nobody Wed Apr  7 08:46:07 2010
Subject: Re: [zf-contributors] Zend_Grid component proposal
From: Mihai Bojin <[email-masked]>
Date: Tue, 26 Jan 2010 16:21:44 +0200
Cc: [email-masked]
To: Matthew Weier O'Phinney <[email-masked]>

Hello Matthew,

I wanted to ask you how to further develop the Zend_Grid proposal,=20
to support the Dojo datagrid or not in favor of your ViewHelper proposal =
!?

Also I want to ask you about the issue of supporting multiple Grids per =
page (this issue: =
http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin?focu=
sedCommentId=3D19595387#comment-19595387 )=20

Thank you,
Mihai Bojin
Romanian PHP Web Developer

On Jan 20, 2010, at 6:52 PM, Matthew Weier O'Phinney wrote:

> -- Mihai Bojin <[email-masked]> wrote
> (on Wednesday, 20 January 2010, 06:25 PM +0200):
>> That's subject to a different proposal
>> http://framework.zend.com/wiki/display/ZFPROP/
>> Zend_Dojo+-+dojox.grid.DataGrid+Support+-+Matthew+Weier+O%27Phinney
>>=20
>> that will actually be a View Helper.
>>=20
>>=20
>> My proposal intends to be a Zend Framework component that will be =
able to
>> generate grids of data rendered in HTML. The target is mainly admin =
panels, but
>> I will probably provide a way to render a grid using a partial.
>> That will mean that Zend_Grid will be able to be used for rendering =
any type of
>> two-dimensional data (mostly SQL table data and arrays).
>=20
> Actually, there may be some overlap; I need to review your proposal =
some
> more, and also review the changes to DataGrid in recent Dojo versions
> before I can say for sure, however.
>=20
>=20
>> On Jan 20, 2010, at 6:02 PM, Giorgio Sironi wrote:
>>=20
>>=20
>>    On Wed, Jan 20, 2010 at 2:55 PM, Mihai Bojin =
<[email-masked]> wrote:
>>=20
>>        Hello Everyone,
>>=20
>>        I submitted a proposal for review and right now I'm waiting =
for any
>>        suggestions, advice, opinions and so on :)
>>=20
>>        You can check out the proposal here:
>>        =
http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin
>>=20
>>        Any feedback will be greatly appreciated !
>>=20
>>=20
>>=20
>>    Do you intend to take advantage of Zend_Dojo? There is a dojo =
component
>>    named Datagrid which takes a lot of work to integrate currently, =
and that
>>    would be a nice feature.
>>=20
>>    --
>>    Giorgio Sironi
>>    Piccolo Principe & Web Engineer
>>    http://giorgiosironi.blogspot.com
>>    http://twitter.com/giorgiosironi
>>=20
>>=20
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 01:25:06 -0500
From: Ralph Schindler <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

Hi all-

My 2cents.

> When we made the decisions before, we were looking at the following
> three options for interfaces:
>  2. Suffix interfaces with "Interface" ("FoobarInterface")
>  3. Use adjective/noun names such as "Foobarable", "Foobarist"

A mixture of 2 and 3 are the best options IMO.

In some cases, interfaces represent a way of marking a class (Marker 
interface) with a specific *capability*.  For example, an object that is 
capable of being serialized, or perhaps an object that is capable of 
being counted.  In these cases, it makes sense to go with the naming 
convention of #3.

On the other hand, and more commonly in OO programing.. You define an 
interface that is a contract.  By definition, a contract is a noun, not 
an adjective.  In these cases, it makes more sense to go with naming 
number 2.

For follow-up reasoning on why compound names are important see my email 
(to be posted) on using nouns and adjective-noun combinations for class 
names.

> For abstract classes, we looked at:
>  5. Suffix abstract classes with "Abstract" ("FoobarAbstract")

I would play on number 5 as a better choice, but not completely.  Going 
with the *adjective-noun* paradigm, I think class names that represent 
abstract functionality *should* be in the class name.  I'd opt for 
Abstract as a prefix, let me explain why.

There is the added side benefit of all abstract classes bubbling up to 
the top of a directory list, and/or being grouped together.

But more importantly, it follows the adjective-noun naming.  For 
example: Zend\Filter\AbstractFilter or Zend\Controller\AbstractController.

Why force "ControllerAbstract" when "AbstractController" is more natural 
  in English speech?  Think about the two sentences (I know being an 
english speaker is not a weighted argument, but all of the code written 
in ZF is in english anyway):

"I am talking about the abstract controller."

"I am talking about the controller abstract."

Which has more meaning?

Those names are meaningful, and simply by reading the class, you are 
given a wealth of information about what the intentions of that class 
are.  In addition, it follows a natural naming convention (in english) 
that is easy to replicate across the entire framework of classes.

Thoughts?
Ralph

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 11:07:40 +0100
From: Giorgio Sironi <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

On Mon, Mar 15, 2010 at 11:09 PM, Lukas K=F6ll <[email-masked]> wrote:
> For Zend_Acl_Role I would have thought that Zend_Acl_Role should be the n=
ew Interface, while for the default implementation there should be somethin=
g like Zend_Acl_Role_Default/Text. As I have never needed to implement cust=
om acl-roles myself I also don't know which possible use cases a custom imp=
lementation of a Zend_Acl_Role Interface might have. I also think that an i=
nterface named Zend_Acl_Role is much more reader-friendly than Zend_Acl_Rol=
e_Interface.
> Zend_Captcha_Adapter might from my point of view stay just as-is (because=
, actually, everything that implements Zend_Captcha_Adapter CAN ACT AS an a=
dapter), Zend_Pdf_ElementFactory_Interface should in my opinion also be ren=
amed to Zend_Pdf_ElementFactory and move the default implementation to some=
thing like Zend_Pdf_ElementFactory_Default (maybe someone can come up with =
something better then "Default" ?) - again, reading "instanceof Zend_Pdf_El=
ementFactory" feels at least to me much more natural than "instanceof Zend_=
Pdf_ElementFactory_Interface"

Completely agree.

--=20
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 28 Aug 2009 11:24:33 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in
	Zend_Entity

-- Guilherme Blanco <[email-masked]> wrote
(on Friday, 28 August 2009, 11:40 AM -0300):
> other types.
> There're main places that requires changes. One example is the DQL to
> SQL generation... Against DDBMS, it can't be used SQL, so we'll have
> to move the SqlWalker extended from TreeWalker (which navigates
> through the AST generated by LL(k) parser) to be Platform dependant.
> This means that if we want to choose Tamino (Document-oriented XML DB)
> for example, we'll have to generate the XQL (a kind of XPath) to query
> the DB.

This is the job of a query/criteria builder, though -- to provide an OO
interface for dynamically building the query parts, and then generating
the appropriate markup. I see no conflict here (though I'm not sure if
you were implying there was one).

> Also, if you want to restrict the structure of a DDBMS to always fit
> your Zend_Entity, this means you're loosing the most powerful thing it
> supports (schema-less definitions).

Not necessarily.

The way I look at it, each document presents its own schema within its
structure (the key/value pairs it contains). Zend_Entity (or another ORM
solution) would simply have some knowledge about how to represent
specific keys in a document. For example, in CouchDB, you might have
tags embedded in the document:

    tags: ["foo", "bar", "baz"]

The ORM would then map the individual items in "tags" to a Tag entity,
creating them based on the string value provided. On the flip side, when
persisting back to CouchDB, it would know to create an array of values
based on the Tag entities aggregated.

> Another point to highlight: DDBMS do not support relations natively.
> Except MongoDB, which is the only DDBMS that supports it, you'll have
> to rely on a lazy load of relations all the time to load related data.
> This changes quite a lot the structure of your Collection and Entity.
> We get prepared to afford this type of need, but you may need to think
> correctly based on your structure.
>=20
> Doctrine team is even considering to go into the direction of
> EclipseLink, which supports it by supporting similar projects. That's
> one of the reasons we organized our repository in Common, DBAL and
> ORM. If we can't afford the changes needed to support DDBMS, we may
> need to create a ODM repository.
> Trust me, you like challenges like we all loves. But build a unique
> solution to support RDBMS, DDBMS, OODBMS are not easy.
>=20
>=20
>=20
> Matthew,
>=20
> We'll release Doctrine 2.0 in September 1st. =3D)
> It'll be a preview alpha.=20

I know. :)

What's the schedule for final, though?

> We want people to start testing our new codebase and provide us some
> feedback. We still have lots of development to do, I just finished the
> base of CLI tasks, while Jonathan finished the Optimistic Locking
> strategy.  On schedule we have many other interesting things to come.
> Recently I've been speaking a lot with Steve Ebersole from Hibernate.
> We're planning to support HiLo Id Generator soon.
>=20
> Most of the concepts we're bringing to Doctrine are quite new to PHP
> world, mainly to lack of some tools of language until now. PHP 5.3
> opened a new world of possibilities and we're just taking advantage of
> it.

Understood -- I wasn't intending my language as bashing previously --
it was simply to illustrate that your adoption of 5.3 will predate ours,
which makes integration opportunities a little more tricky.

> Native support to Metadata mapping through Annotations is a rather
> unique thing in PHP, only seen similar in Unit Test tools.

Actually, ZF's various Server classes utilize annotations to build up
method maps and prototypes. :) We're using stock annotations (short/long
descriptions, param, and return), but it's been part of the offerring
since 0.1.0. Zend_Server_Reflection and the newer Zend_Reflection offer
a lot of support for introspecting annotations.

It's a powerful paradigm -- though a little expensive in terms of
computation.

> Let's see how people accept these new ideas, we're open to hear any
> feedback from userland.
>=20
>=20
>=20
> Cheers,
>=20
>=20
> On Fri, Aug 28, 2009 at 8:22 AM, Matthew Weier
> O'Phinney<[email-masked]> wrote:
> > -- Benjamin Eberlei <[email-masked]> wrote
> > (on Thursday, 27 August 2009, 10:06 PM +0200):
> >> i am currently scratching my head on howto abstract the query API fo=
r different
> >> storages and often think about CouchDb which has a fundamently diffe=
rent Query
> >> concept than a RDBMS.
> >>
> >> For clarification to the not so familiar, it the EntityManager is th=
e sole
> >> public API to the user of Zend_Entity and its facilities. It manages=
 the life-
> >> cycle of domain objects.
> >>
> >> Currently, it has the following API for queries:
> >>
> >> EntityManager::load($entityClass, $id);
> >> EntityManager::createNamedQuery($name);
> >> EntityManager::createNativeQuery($input, $resultSetMapping);
> >> EntityManager::createNativeQueryBuilder($entityClass=3Dnull);
> >> EntityManager::createQuery($zql); // not implemented yet
> >> EntityManager::createQueryBuilder(); // not implemented yet
> >>
> >> This is very large and still very RDBMS specific interface. To break=
 that up
> >> I was thinking to go the following way, only have three methods:
> >>
> >> EntityManager::load($entityClass, $id);
> >> EntityManager::createNamedQuery($name);
> >> EntityManager::createNativeQuery($input, $resultSetMapping);
> >>
> >> And all the other Query related stuff is implemented and used explic=
itly by
> >> calling for example:
> >>
> >> $sqlQueryBuilder =3D new Zend_Db_Mapper_SqlQueryBuilder($entityManag=
er);
> >> $queryBuilder =3D new Zend_Db_Mapper_QueryBuilder($entityManager);
> >> $zqlQuery =3D new Zend_Db_Mapper_ZqlQuery($entityManager);
> >>
> >> This way the API can be hinted explicitly in IDEs (since its often q=
uite
> >> complex) and storage specific features can be implemented.
> >
> > This seems like a very good approach to me. It keeps the primary quer=
y
> > types front and center, but offers the flexibility to create your own
> > without needing to inform Zend_Entity of them. I particularly like th=
is
> > because it introduces the idea of a "criteria" object -- which can th=
en
> > be as abstract as you want it, or specific to your particular data
> > storage implementation.
> >
> >> Now you ask yourself, how is this storage independent? It is via the
> >> "createNamedQuery()" method. This method internally uses the plugin
> >> loader to instantiate queries via the command pattern. In a storage
> >> independent database, all operations have to be build as named query
> >> and executed such. =A0For each storage a corresponding implementatio=
n
> >> has to exist.
> >
> > This seems like it would be very compatible with CouchDB views,
> > actually.
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> > Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> >
>=20
>=20
>=20
> --=20
> Guilherme Blanco - Web Developer
> CBC - Certified Bindows Consultant
> Cell Phone: +55 (16) 9215-8480
> MSN: [email-masked]
> URL: http://blog.bisna.com
> S=E3o Paulo - SP/Brazil
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 24 Nov 2009 12:17:27 +0100
To: [email-masked]
From: Lars Kneschke <[email-masked]>
Organization: Metaways Infosystems GmbH
Subject: Re: [zf-contributors] Future of Zend_Db_Schema_Manager

"Sean P. O. MacCath-Moran" <[email-masked]> schrieb:
> Greetings ZF Community,
>=20
> Some time ago I'd began constructing a Zend DB Schema Manager with the
> intention of building up something similar to the database management
suite
> available in RoR. I have a basic version of this running successfully in =
a
> production environment, but it was made quickly and is a bit hackish.
> However, I built on that idea in creating a proposal for an expanded set
of
> components, viewable at:
>=20
http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+Sea=
n+P.+O.+MacCath-Moran?focusedCommentId=3D18219191#comment-18219191
>=20
> ...
>=20
> 1. IYHO, is this a component that the ZF community wants or needs?
We (Tine 2.0) want it.

When we started with Tine 2.0 we also had the problem, how to create and
update tables in a userfriendly way. As there was nothing, we implemented
something what solved our problems.

Now we have something what works but still can be improved. Most of =
features
wanted from the spec above is there already. You can create, drop and =
update
tables. You can alter, updated, drop columns, foreign keys and indexes. =
The
definition comes from a xml file, while update scripts are written in PHP.

The code is here: http://svn.tine20.org/svn/trunk/tine20/Setup/Backend/.
--
Lars Kneschke
Team Leader Business Solutions
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

Tine 2.0 now with Calendar, Email and ActiveSync=3D> =
http://www.tine20.org/

E-Mail: mailto:[email-masked]
Web: http://www.metaways.de
Tel: +49 (0) 40 317031-21
Fax: +49 (0) 40 317031-921
Mobile: +49 (0) 175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsb=C3=BCttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Gesch=C3=A4ftsf=C3=BChrung: Hermann Thaele, L=C3=BCder-H.Thaele

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 10:31:44 +0100
From: drm <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Hi,

It helps me to regress to the point where I started using Zend=20
Framework. One of this first things I found confusing was the grand=20
amount of directories and classes, while ZF in fact is quite a=20
light-weight framework, (I mean, the MVC framework, which is probably=20
what most people talk about anyway, when talking about ZF). It also=20
annoyed me a little bit, since I had to upload large amounts of files=20
(especially Zend_Locale and Zend_GData), which could cost a lot of time=20
in my case, where I build many relatively small websites on both shared=20
and single servers, sometimes only with FTP access.

I was thinking it might be nice to get some packaging done in 2.0, at=20
least in the documentation, and maybe in release packages. The "minimal"=20
package, really isn't that "minimal" (20 MB unpacked, about 2300 files).=20
I was thinking it might be nice to split things up in a few builds that=20
would make ZF a bit simpler for the first-timer, and more effective for=20
repetetive users.

Core components (Config, Loader)
MVC (Core + Controller, Application, View, Layout and all related=20
dependencies)
MVC+ (MVC + Form, Filter, Validate, Db and all related dependencies)
Starter (MVC+ + Tool, CodeGenerator and related dependencies + binscripts=
)
Common libraries (Acl, Auth, Mail, Mime, Cache)
Data libraries (Currency, Locale, Date, Measure)
Utility libraries (All remaining packages from current minimal)

As a beginner, you could start off with the "Starter" package, to get=20
started learning the core of the MVC framework, without being confused=20
by packages like GData and InfoCard, to avoid the "What does this button=20
do?"-effect. I also think, one of the USP's of ZF is that it is usable=20
as a full-stacked framework, and as a code library (or both). I think=20
packaging might reflect (and encourage) this better. All strictly=20
unnessecary dependencies would ideally be eliminated to avoid cascading=20
and recursive dependencies to achieve this. All necessary dependencies=20
could be documented and registered in a package builder, or just=20
documentation.

I think that is one of the issues that will help reel people in getting=20
more involved, because it will help understanding the framework's basic=20
structure, and get them up and running quickly ( < 1MB starter sandbox? )

I am aware of the fact that it might be rather time-consuming to=20
maintain this structure, but we could get started by documenting a=20
dependency tree for each of the directories in the current 1.9 minimal=20
package, and automate some build process for it?

Regards,
Gerard

Matthew Weier O'Phinney wrote:
> -- Jurri=EBn Stutterheim <[email-masked]> wrote
> (on Sunday, 15 November 2009, 08:21 PM +0100):
>  =20
>> The ideas and discussions for ZF 2.0 have been great so far, and I'm
>> really looking forward to the actual release!
>>
>> There's a non-technical issue that ZF 2.0 should try to tackle. This
>> issue is getting beginners up to speed quickly, and to get people more
>> involved in the community.
>>    =20
>
> This is an initiative the Zend team is currently working on, actually.
> We have begun writing a series of tutorials that will be a part of the
> manual:
>
>     http://framework.zend.com/svn/framework/standard/branches/user/zf-d=
evteam/documentation/en/
>
> We're getting some "core" tutorials out there, but then plan to use the
> proposal process to get new content in (either to request new content,
> or submit new content).
>
> That said, it needs to be a core requirement for 2.0 as well,
> particularly since some areas will be changing dramatically.
>
>  =20
>> First off, developers should get the tools and knowledge to get
>> started with developing right away. The Quickstart is doing great with
>> this, but it could probably use a dedicated chapter for setting up a
>> development environment. That is, Zend Server and PDT/ZSfE or
>> Netbeans, with full debugging support etc.
>>    =20
>
> This is a good point. I've had to answer a number of questions regardin=
g
> setting up virtual hosts over the past months -- something I took for
> granted as a basic skill. I'll add this to my current TODO.
>
>  =20
>> What comes next is probably where ZF is currently lacking most.
>> Currently the documentation we have are the quickstart, followed by
>> the reference guide. For me - someone who's been using ZF since around
>> v0.2 - that's perfectly fine, but the step is too big for a beginner.
>>    =20
>
> The tutorials we're creating will be in a "Learning Zend Framework"
> section that follows the introduction; this will be followed by the
> current "Reference Guide" section. The way it will be shown is:
>
>      I. Introduction to Zend Framework
>     II. Learning Zend Framework
>    III. Reference Guide
>     IV. Appendixes
>
>  =20
>> Basically two things need to be made clear to someone who just
>> finished the quickstart: how does the ZF community work (where can I
>> get help, how can I help, etc.), and where do I go from here?=20
>>    =20
>
> Good point on the community stuff. However, that part has traditionally
> been the realm of the main website and wiki -- not the manual.
>
>  =20
>> Paddy has been doing some amazing work on the latter question with his
>> Survive The Deep End book, that's freely available online
>> (http://www.survivethedeepend.com/). Why not make this a permanent
>> link on the ZF homepage, between quickstart and reference guide?  The
>> former ("where can I get help/how can I help") could be made more
>> clear to make links to the mailing lists and #zftalk and #zftalk.dev
>> more visible on the ZF frontpage.=20
>>    =20
>
> There have been a few notes about the mailing list visibility on the
> website, and I'm hoping to address that soon.
>
>  =20
>> Expanding on the community point a bit, it might be a good thing to
>> keep the level of experience of developers in mind on the wiki and the
>> mailing list. Paddy and Kevin touched this topic in their discussion
>> in this thread, and I've read the term "too compsci-y" somewhere in
>> that discussion too. To be perfectly honest, I'm completely fine with
>> discussions and proposals that expect some compsci experience from the
>> reader. That said, it might be a good thing to get people without a
>> compsci degree in on the discussions as well, which is probably
>> actually quite a large group of people in the PHP world. For example,
>> the Zend_Controller 2.0 proposal mentions an FSM. For people that do
>> not know what an FSM is, a reference to an introductory article on
>> FSMs might be interesting. In a discussion I had with a friend we
>> couldn't agree on how this could be achieved best, without dumbing
>> things down too much. I'd be interested to hear your opinions on this.
>>    =20
>
> I can agree with this to a point. Right now, I'm trying to get primaril=
y
> architectural feedback, which really requires a fair bit of discussion
> of design patterns and CS concepts.=20
>
> When it's time for official proposals, we'll be focussing primarily on
> use cases -- and *that* is where we can make things simpler and address
> the full range of ZF developers. I figure the following:
>
>     $application =3D new \zend\Application(
>         APPLICATION_ENV,=20
>         APPLICATION_PATH . '/configs/application.ini'
>     );
>     $application->bootstrap()
>                 ->run();
>
> and:
>
>     // Add a listener for pre-action dispatch:
>     $manager =3D $this->getResource('event_manager');
>     $pubsub  =3D $manager->getPubSub();
>     $pubsub->subscribe('mvc.dispatcher.pre', 'my\plugins\ContextNegotia=
tion');
>
> and:
>
>     // Indicate it's time to send the response:
>     $e->setState('response');
>     return;
>
> are concepts the end-user can easily grasp without needing to know a
> whole lot about how it actually works internally.
>
>
>  =20
>> On Nov 11, 2009, at 19:38 , Matthew Weier O'Phinney wrote:
>>
>>    =20
>>> Hey, all --
>>>
>>> There have been a ton of questions about the ZF 2.0 roadmap, and my
>>> answer has been consistently, "I'm working on it; I'll have something=
 to
>>> publish soon."
>>>
>>> "Soon" is now:
>>>
>>>    http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+R=
oadmap
>>>
>>> I'd like you, as contributors, to look over it, and start discussing =
the
>>> various ramifications; we can do that either in comments to the pages=
 or
>>> on this list.
>>>
>>> The roadmap is primarily a conceptual one right now, though a
>>> proof-of-concept has been created for the proposed MVC. I'd like to s=
tay
>>> fairly high-level for now, and then start getting a flow of proposals
>>> into the system for specific migration-related tasks.
>>>
>>> Thanks everyone who has provided me input over the past many months, =
and
>>> let's get started on the next generation of ZF!
>>>
>>> --=20
>>> Matthew Weier O'Phinney
>>> Project Lead            | [email-masked]
>>> Zend Framework          | http://framework.zend.com/
>>>      =20
>
>  =20

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 27 Feb 2010 05:11:43 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Ben Scholzen 'DASPRiD' <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--0-1384839025-1267276303=:87907
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Unless the tests are broken we could specify this going forward - little po=
int re-editing old tests if they remain functional. Besides there may be so=
me debate later on about how exactly we intend using Exceptions - the curre=
nt class based exception usage ignores SPL for example (I've grown to like =
the standard types).=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.co=
m=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Repre=
sentative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Ben Sch=
olzen 'DASPRiD' <[email-masked]>=0ATo: [email-masked]; Ma=
tthew Weier O'Phinney <[email-masked]>=0ASent: Sat, February 27, 2010 12:=
45:09 PM=0ASubject: Re: [zf-contributors] ZF 2.0 development begins!=0A=0A-=
----BEGIN PGP SIGNED MESSAGE-----=0AHash: SHA1=0A=0AMatthew Weier O'Phinney=
 wrote on 25.02.2010 00:05:=0A>  * Updating the test suite:=0A>    * Removi=
ng the AllTests suites (these are not necessary with newer=0A>      version=
s of PHPUnit, and we have already established @group=0A>      annotations t=
hroughout the framework)=0A>    * Usage of TestHelper.php as a PHPUnit boot=
strap; this will allow=0A>      stripping out the require_once calls in eac=
h test class file.=0A=0AWe should also replace those blown try/catch blocks=
 which currently test=0Afor expected exceptions with the new functionallity=
 in PHPUnit. There is=0Aeither the function $this->setExpectedException('Ex=
ceptionName'); and=0Athe docblock annotation @expectedException ExceptionNa=
me, of which I=0Apersonally prefer the method-call one. The only thing whic=
h is currently=0Anot possible through this is to specify a string which is =
contained=0Awithin the exception message, but I already raised an issue tic=
ket for that:=0A=0Ahttp://www.phpunit.de/ticket/1012=0A-----BEGIN PGP SIGNA=
TURE-----=0AVersion: GnuPG v1.4.9 (GNU/Linux)=0AComment: Using GnuPG with M=
ozilla - http://enigmail.mozdev.org=0A=0AiEYEARECAAYFAkuJE9UACgkQ0HfT5Ws789=
CO5QCeOncSwugsizLzSwRN7UHN6icA=0AIgIAn0WA1+JF7VST9D/2fPfztn0soSNz=0A=3Do4WD=
=0A-----END PGP SIGNATURE-----=0A
--0-1384839025-1267276303=:87907
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Unless the tests are broken we could specify this going forwar=
d - little point re-editing old tests if they remain functional. Besides th=
ere may be some debate later on about how exactly we intend using Exception=
s - the current class based exception usage ignores SPL for example (I've g=
rown to like the standard types).<br><div>&nbsp;</div><span style=3D"color:=
 rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new york,time=
s,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br>=
<br></span></font><span style=3D"font-style: italic;"><font style=3D"font-f=
amily: times new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow=
" target=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blog.astru=
mfutura.com</a><br><a rel=3D"nofollow" target=3D"_blank"
 href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com=
</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideuro=
pe.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span>=
</span><div><br></div><div style=3D"font-family: times new roman,new york,t=
imes,serif; font-size: 12pt;"><br><div style=3D"font-family: tahoma,new yor=
k,times,serif; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"><hr size=
=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Ben Scholzen =
'DASPRiD' &lt;[email-masked]&gt;<br><b><span style=3D"font-weight: bold;"=
>To:</span></b> [email-masked]; Matthew Weier O'Phinney &lt=
;[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">Sent:</span>=
</b> Sat, February 27, 2010 12:45:09 PM<br><b><span style=3D"font-weight: b=
old;">Subject:</span></b> Re: [zf-contributors] ZF 2.0 development begins!<=
br></font><br>=0A-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Ma=
tthew Weier O'Phinney wrote on 25.02.2010 00:05:<br>&gt;&nbsp; * Updating t=
he test suite:<br>&gt;&nbsp; &nbsp; * Removing the AllTests suites (these a=
re not necessary with newer<br>&gt;&nbsp; &nbsp; &nbsp; versions of PHPUnit=
, and we have already established @group<br>&gt;&nbsp; &nbsp; &nbsp; annota=
tions throughout the framework)<br>&gt;&nbsp; &nbsp; * Usage of TestHelper.=
php as a PHPUnit bootstrap; this will allow<br>&gt;&nbsp; &nbsp; &nbsp; str=
ipping out the require_once calls in each test class file.<br><br>We should=
 also replace those blown try/catch blocks which currently test<br>for expe=
cted exceptions with the new functionallity in PHPUnit. There is<br>either =
the function $this-&gt;setExpectedException('ExceptionName'); and<br>the do=
cblock annotation @expectedException ExceptionName, of which I<br>personall=
y prefer the method-call one. The only thing which is currently<br>not poss=
ible
 through this is to specify a string which is contained<br>within the excep=
tion message, but I already raised an issue ticket for that:<br><br><span><=
a target=3D"_blank" href=3D"http://www.phpunit.de/ticket/1012">http://www.p=
hpunit.de/ticket/1012</a></span><br>-----BEGIN PGP SIGNATURE-----<br>Versio=
n: GnuPG v1.4.9 (GNU/Linux)<br><span>Comment: Using GnuPG with Mozilla - <a=
 target=3D"_blank" href=3D"http://enigmail.mozdev.org">http://enigmail.mozd=
ev.org</a></span><br><br>iEYEARECAAYFAkuJE9UACgkQ0HfT5Ws789CO5QCeOncSwugsiz=
LzSwRN7UHN6icA<br>IgIAn0WA1+JF7VST9D/2fPfztn0soSNz<br>=3Do4WD<br>-----END P=
GP SIGNATURE-----<br></div></div>=0A</div></body></html>
--0-1384839025-1267276303=:87907--

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 11:04:32 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

-- Josh Butts <[email-masked]> wrote
(on Monday, 22 March 2010, 08:07 AM -0500):
> Matthew,
> 
> Just as an FYI, the latest version of Fisheye does support Git (you
> mentioned viewgit below). We're using it at my company and have had no
> problems with it.

Yeah - I heard that.

We're planning on moving from basically all the Atlassian tools except
JIRA. The reasons are:

 * Lack of familiarity with Java, which makes maintaining/debugging
   resource intensive. While we can get support from Atlassian and/or
   their partners, the problem is that we typically need a _fast_
   solution and/or one that works within the confines of our existing
   server infrastructure.

   If we can move to PHP-based tools, we can manage them much easier
   with our existing resources.

 * Ability to customize and embed tools in our site. The Atlassian tools
   have minimal customization capabilities, and as such stick out as not
   being part of the ZF site. We'd really like to have them look more
   like the rest of the site, to make the experience more cohesive and
   less jarring when you perform different tasks. The PHP apps are more
   conducive to this -- not just by design, but because we can easily
   manipulate the source code.

 * Performance. Our site performance often lags due to the architecture
   we've had to create to support having the Atlassian tools in place.
   The fewer tools we have up, the better the site will perform.

I've tinkered with viewgit quite a bit, and I think it will satisfy the
above situations quite well.

As for JIRA, it's really a quite good issue tracker, and I've heard
anecdotally that it's integration with git repositories works quite
well. As such, I see no reason to remove it from our stack.

> On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:
> 
> > Greetings, all --
> > 
> > Based on the wiki and the poll on this list, it looks like it makes
> > sense to move forward with git. We're still trying to iron on some
> > details about how this will work, but some details are falling into
> > place.
> > 
> > First, the things we plan:
> > 
> > * Git will be hosted on the ZF servers. This is so that we can have
> >   full control over hooks (i.e., no network latency from web hooks),
> >   integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
> >   will offer both anonymous access as well as selective writable
> >   access.
> > 
> >   Some will say, "why not just use Github?" The above does not preclude
> >   using github in any way; git allows you to specify multiple remotes
> >   from your repository. I already plan to have a mirror of my personal
> >   repo on github, as well as push to the ZF repo from the same
> >   location. This will allow people to use some of githubs powerful
> >   features such as pull queues while still allowing us to retain some
> >   control over the repository. (It also insulates us from githubs
> >   growing pains a bit -- I love github, but they are certainly
> >   suffering from rapid growth the last few months!)
> > 
> > * We plan to have a read-only subversion mirror of the git repository.
> >   This will allow those using svn:externals to continue to do so, as
> >   well as allow folks more familiar with svn to continue to provide
> >   patches.
> > 
> > Next, things we're still researching:
> > 
> > * How to handle contributions. Since we require a signed CLA, we need
> >   some way of verifying that a patch came from an author who has signed
> >   the CLA. There have been some suggestions that this may be possible
> >   with some sort of pre-commit verifications when committing to the
> >   master repository (or when someone with commit privileges commits to
> >   their own repository). We're still researching how this might be
> >   implemented.
> > 
> > * Submodules...
> >   For those unfamiliar with git submodules, they are roughly equivalent
> >   to svn:externals. I say "roughly", because they differ in many ways:
> >   they have to be manually initialized on each person's repository
> >   (though they can be defined in the master repository); they need to
> >   be manually updated periodically (unlike svn:externals, where anytime
> >   you do an "svn up", it also syncs the external); etc.
> > 
> >   They are quite powerful, however, and give us the ability to offer a
> >   "lean" initial checkout, allowing developers to sync in only the
> >   submodules they plan to utilize or commit to.
> > 
> >   On this note, I've fielded a number of suggestions. Some were
> >   suggesting the library directory be its own submodule, some suggested
> >   all top-level directories be their own submodule, etc. I've done some
> >   experimentation, and now propose the following structure:
> > 
> >    MAIN REPO:
> >        INSTALL.txt
> >        LICENSE.txt
> >        README.txt
> >        bin/
> >        library
> >        tests/
> >        documentation/manual/
> >            Makefile
> >            README.txt
> >            en/
> >    SUBMODULES:
> >        demos/
> >        resources/
> >        tools/
> >        documentation/manual/:
> >            all languages except "en"
> > 
> >   Now, for an explanation of the "whys" behind this. As contributors,
> >   it's important to make atomic commits: your code fix should also
> >   include a corresponding unit test, and potentially a documentation
> >   commit as well. If we split the library and tests directories out
> >   into their own submodules, we cannot do so; the code and test must be
> >   committed separately, which is (a) more work, and (b) unintuitive.
> >   The same goes for related documentation commits.
> > 
> >   Translations, on the other hand, are usually managed in a
> >   per-language capacity, flowing from English to the target language.
> >   Most developers do not need the docbook source for anything but their
> >   target language and English (the latter because it's used for
> >   fallbacks, and because it contains the build scripts). While we
> >   potentially lose the history of an "svn cp", I think this
> >   organization provides reasonable benefits.
> > 
> >   Finally, the demos, resources, and tools (the latter is a new
> >   directory) are all "opt-in" items -- if you need them, you can pull
> >   them in; if you don't, there's no reason to.
> > 
> > I'd love to get some feedback on the incomplete items. I think the
> > submodule layout I've come up with makes the most sense for contributors
> > (and based on testing, it's the cleanest and simplest way I've found to
> > accomplish most common development tasks on our tree), but am open to
> > further suggestions. If you have any ideas on handling ACLs, I'd love to
> > hear them, and sooner rather than later!
> > 
> > -- 
> > Matthew Weier O'Phinney
> > Project Lead            | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 13 Apr 2009 23:40:28 -0500
From: Ralph Schindler <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

Addressing the following points one by one, with some reasoning and 
additional brainstorming:

> In a nutshell, here's what they define:
> 
>  * Namespaces are lowercase: zend\codegenerator\php
 >  * Class names are MixedCase: zend\codegenerator\php\File

I wonder why and where this artificial limitation on namespace names 
came from?  Casing is about readability.  To me, it seems as though 
(even though we have a pretty solid IDE.. Zend Studio, et. al) we should 
keep a level of consistency between the class & namespace organization 
to the filesystem organization.  It should be as logical one one side as 
the other and to achieve this, we need to have as few translations rules 
as possible.

In the current library, (upper) camel case / mixed case provides this 
readability.  Currently, there is a 1-1 relationship between a class 
name and its expected location on disk.  We should attempt to attain 
that same level of direct relationship.

My problems with lower cased namespace names starts when we have 
multiple compound names like CodeGenerator or names with acronyms like 
PDFParser.  Their filesystem counterparts become less readable.  Not to 
mention, since the only separator allowed in namespaces is the 
underscore, this will cause confusion in the long run, not to mention 
there are countless arguments against underscore in filesystem names.

/My suggestion/: lets keep upper camel cased / mixed case names in both 
the namespace and on the filesystem.  This solution ultimate offers 
developers more transparency.

(other things to think about)
* fewer rules for autoloaders to find namespaced classes and files
* case sensitive and intensive file systems

>  * Namespaces may contain underscores, but they do not translate to the
>    directory separator
>  * Class names may contain underscores, and they *do* translate to the
>    directory separator

I touched on this above, but I can reiterate: I think there should be as 
few rules as possible when translating to and from class/namespace to 
filesystem.

Directories are a way of containing classes, and if in some case you are 
expecting an underscore to translate to a directory, then perhaps you 
should probably be using a sub-namespace anyway.

>  * Interfaces should be named descriptively, and not contain the word
>    "Interface" or the sigil "I".
>  * It is preferred that Abstract classes are also named descriptively,
>    but *may* contain the *suffix* Abstract.

I realize we are looking to find the golden rule, but really, I think it 
should come down to a few general rules.

/My golden rule/:

Names should be as short as possible while concisely conveying the 
maximum amount of meaning they can.

On the subject of interfaces:

There definitely should not be a single rule for interface naming. 
There are a couple of different uses for interfaces in object oriented 
programming, but I will describe the two most popular usages: 
*contracts* and *capabilities*.

Generally, we are using interfaces to enforce a specific contract.  A 
good example of this is Zend_Session_SaveHandler_Interface.  This 
interface defines the minimal (public method api) requirements that the 
Zend_Session system expects.  These minimal requirements define the 
*contract* between the consumer (Zend_Session) and the provider 
(Zend_Session_SaveHandler_DbTable for example).

In other cases, we are using interfaces to describe a capability that a 
class & object will have.  These interfaces generally will have 0 1, or 
maybe 2 methods.  (Interfaces requiring 0 methods are generally known an 
/marker/ interfaces since the consumer is using the presence of a 
specific interface as a sign of "membership" in a system.)  A good 
example of capability based interfaces would include SPL's Countable and 
Serializable interfaces.  Respectively, these interfaces require 1 and 2 
methods, specifically dealing with the implementation of the 
*capability* they are providing.

 From a naming perspective, *capability* interfaces have had a history 
of ending in -able or -ible in cases where names of such are possible.

My Suggestion:

For capability based interfaces I think we should stick with SPL's 
tendency to suffix meaningful names with -able and -ible.

For contract based interfaces, it seems (to me) that the most 
transparent way to identify interfaces both on the filesystem and in a 
class organization hierarchy is to suffix the class with -Interface. 
Like Benjamin said, this also plays nice with the english langage.  In 
this case, the "interface" is the noun, and the subject is actually the 
adjective.  For example, "the request interface".

Assuming all the above, this would give you something like:

Zend\Controller\Request\RequestInterface
Zend\View\ViewInterface
Zend\Filter\FilterInterface
Zend\Tag\Taggable

On the subject of Abstracts:

Abstracts, on the other hand, are partial implementations and as such 
can be governed by a different set of naming rules.  In my mind there 
are two important factors in naming: 1) can we identify visually that a 
given class is a partial implementation both in class organization view 
as well as filesystem view, and 2) can we use a natural naming.

(1) effectively means that we should be able to see (by looking at a 
directory, file, or a class tree) that a given item is abstract and/or 
contains something that can be extended. Point (2) is basically an 
attempt at keeping the naming scheme close to the way its thought of. 
For example, when talking about a Request object, we would say "the 
request"; when talking about a partial implementation though, we are 
inclined to say "the abstract request".  The word "abstract" is the 
adjective and "request" is still the noun.

Assuming those ideas, you get:

Zend\Controller\Request\AbstractRequest
Zend\Controller\AbstractAction (or) Controller\Action\AbstractAction
Zend\View\AbstractView

This has the added benefit of bubbling up the abstracts to the top of an 
alphabetical listing, as well as identify partial implementation classes.

-ralph

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 2 May 2009 21:34:37 +0200
From: till <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Zend_Session

Hey party people,

has anyone started on a rewrite of Zend_Session yet? The issues are
piling up on Jira and no one seems to be responsible while the general
consensus seems to be that it's gonna be re-done in 2.0. So anyway, if
anyone is working on this, I'd like to offer my help here.

Till

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 17:06:36 +0100
From: drm <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Matthew Weier O'Phinney wrote:
> Minimal package is simply everything under library/ and bin/ under the
> standard library (i.e., nothing from Extras, nothing pulled in from
> svn:externals).
Thanks, that explains why e.g. GData is in there.

Gerard

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Eric Clemmons <[email-masked]>
Date: Mon, 22 Mar 2010 15:59:06 -0500
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] use statements -- usage?

Aliasing longer namespaces would increase readability and really take =
advantage of namespaces as intended.  In the example provided, "\" is =
really the same as "_" in PHP 5.2

> use Role\RoleInterface;
> use Role\Registry\Registry;
>=20
> public function add(RoleInterface $role) { }
>    $registry =3D new Registry();

Ah, much nicer.  Packaging is one thing, but that's all automated.  The =
slowest part is the development process itself which determines to use =
relative namespaces or not.

On Mar 22, 2010, at 3:49 PM, Matthew Weier O'Phinney wrote:

> Hey, all --
>=20
> Within a namespace, you don't need to import subcomponent
> namespaces, as you can use the relative namespaces to help identify
> classes. As an example, from Zend\Acl:
>=20
>    public function add(Role\RoleInterface $role) { }
>=20
>    $registry =3D new Role\Registry\Registry();
>=20
>    etc.
>=20
> Does it make sense to create "use" statements for these, or simply =
start
> using them without aliases? Part of me wants to define the "use"
> statements to help with automating packaging; another feels we can
> simply assume anything within the given namespace is going to be
> packaged together anyways.
>=20
> Thoughts?
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 11:10:57 +0100
From: Giorgio Sironi <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

On Tue, Mar 16, 2010 at 7:25 AM, Ralph Schindler
<[email-masked]> wrote:
> But more importantly, it follows the adjective-noun naming. =A0For exampl=
e:
> Zend\Filter\AbstractFilter or Zend\Controller\AbstractController.
>
> Why force "ControllerAbstract" when "AbstractController" is more natural =
=A0in
> English speech? =A0Think about the two sentences (I know being an english
> speaker is not a weighted argument, but all of the code written in ZF is =
in
> english anyway):

Imho Abstract as a prefix is more readable. I guess it was a suffix
originally because of the logical location of the file:
Zend_View_Abstract goes in Zend/View folder. Instead of contrapting it
to ViewAbstract, a meaningful name can be Zend\View\AbstractView.

--=20
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 12 Jan 2010 09:58:50 +0100
From: drm <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] CLA approval

Hi,

I have sent in my CLA almost two months ago now. I have tried to contact 
Matthew on this, but no response. I'm wondering what's going on. Do I 
need to send it in again? Can anybody help me on this?

drm / Gerard

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Thu, 25 Feb 2010 20:54:54 +0100
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

On Thursday 25 February 2010 17:44:54 Luke Crouch wrote:
>Maybe I'm turning into a crotchety old programmer, but I'm not really
>impressed with git. We switched from svn to git at my day job and I
>haven't really seen any big benefits aside from a few sweet syntactic
>shortcuts like git stash. For larger projects with well-organized
>branching I just haven't seen much additional value from git.

I think if I was working in house with a centralised core of programmers,=20
there is a compelling argument to perhaps stay with SVN. You can enforce=20
practices in the organisation and you can deploy a common set of tools. SVN=
=20
access is much easier to manage.

ZF on the other hand is already a distributed project and Git's work-flow a=
nd=20
utilities are very well matched. The cheap branching and merging is in it's=
=20
own right reason enough to switch, in my opinion; but there are many other=
=20
aspects to Git that make it better for ZF's needs.

Remote tracking of multiple branches on multiple repo's combined with cheap=
=20
and easy merging is a killer feature. Not only does it make a maintainers l=
ife=20
a ton easier, it makes collaboration very much easier than SVN too, one of =
the=20
reasons GitHub/Gitorius are so successful...=20

Sure, I'm passionate about Git but it's because it has helped me become mor=
e=20
productive, and to me that is utter invaluable. I want ZF to switch to Git =
not=20
because I think it's the better tool or because it's not SVN, I want ZF to=
=20
switch to Git because I believe ZF as a project and anyone who uses ZF will=
=20
benefit more so than staying with SVN.

=2D-=20
=E2=80=9CWhat can be asserted without proof can be dismissed without proof.=
=E2=80=9D
=2D Christopher Hitchens

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 9 Mar 2010 09:00:09 -0600
From: Luke Crouch <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 8 Mar 2010

As another example, the Zend_Rest_Route tests touch both Zend_Rest and
Zend_Controller so I could put those tests into both groups so anytime
we change anything in either place the Zend_Rest tests run.

-L

On Tue, Mar 9, 2010 at 7:07 AM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Giorgio Sironi <[email-masked]> wrote
> (on Tuesday, 09 March 2010, 11:48 AM +0100):
>> On Tue, Mar 9, 2010 at 12:04 AM, Ben Scholzen 'DASPRiD' <[email-masked]=
e>
>> wrote:
>>
>> =A0 =A0 Matthew Weier O'Phinney wrote on 08.03.2010 22:41:
>> =A0 =A0 > =A0 =A0 # from tests/ directory
>> =A0 =A0 > =A0 =A0 % phpunit --group Zend_Acl .
>>
>> =A0 =A0 Why not just do phpunit --filter Zend_Acl instead? That makes th=
e @group
>> =A0 =A0 stuff obsolete.
>>
>>
>> You can even do:
>> $ phpunit Zend/Acl
>
> Using @group annotations allows us to run multiple component suites
> simultaneously, as well as to group test cases across multiple
> components. It also allows us to specify a given test case as belonging
> to multiple groups; this can be particularly useful for testing things
> such as view helpers (which are under Zend_View_Helper,
> Zend_Dojo_View_Helper, and ZendX_Jquery_View_Helper), action helpers
> (Zend_Controller_Action_Helper, Zend_Layout, etc.), and more.
>
> Basically, group annotations give us more structure and benefits.
>
> Most importantly to me, it provides an _explicit_ semantic meaning to the
> various test suites. We need to favor explicitness over implicitness for
> ZF 2.0.
>
> --
> Matthew Weier O'Phinney
> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 29 Sep 2009 22:22:48 +0100
From: James Dempster <[email-masked]>
To: Graham Anderson <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Google Wave Invites

I'm very interested.
My account name is letssurf.

Looking forward to getting my hands on it.

On Tuesday, September 29, 2009, Graham Anderson
<[email-masked]> wrote:
> The first wave (pardon the pun) of mass invites for Google Wave are going=
 out
> tomorrow, people with existing accounts and new invitees will be allocate=
d 8
> additional invites.
>
> If you don't already have a wave account and have *not* signed up to get =
one,
> I'll send out my 8 invites in on a first come first served basis on this =
list.
>
> Graham
> --
> =E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=
=9D
> =C2=A0=E2=98=98 Oscar Wilde
>

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Date: Fri, 14 Aug 2009 16:12:46 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [zf-contributors] Gravatar Proposal

--_004_6B4A8009371807499638509271DEA796011632DD6D7CIMSCMAIL1im_
Content-Type: multipart/alternative;
	boundary="_000_6B4A8009371807499638509271DEA796011632DD6D7CIMSCMAIL1im_"

--_000_6B4A8009371807499638509271DEA796011632DD6D7CIMSCMAIL1im_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello all,

I am wondering if anyone knows the status of the Gravatar Service Proposal =
(http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_Gravatar+Propos=
al+-+Wojciech+Naruniec)

If no one is working on it I would like to take it over as it seems about 9=
0% done.

Please let me know.

Thanks!

<http://zend.com/zce.php?c=3DZEND002524=
&r=3D219549271>

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]<mailto:[email-masked]>
P: (317) 492-8623 - F: (317) 492-6419

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

--_000_6B4A8009371807499638509271DEA796011632DD6D7CIMSCMAIL1im_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Lucida Sans";
	panose-1:2 11 6 2 3 5 4 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal">Hello all,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I am wondering if anyone knows the status of the Gra=
vatar Service Proposal (http://framework.zend.com/wiki/display/ZFPROP/Zend_=
Service_Gravatar&#43;Proposal&#43;-&#43;Wojciech&#43;Naruniec) &nbsp;<o:p><=
/o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">If no one is working on it I would like to take it o=
ver as it seems about 90% done.&nbsp;
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Please let me know.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks!<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<td width=3D"80" valign=3D"top" style=3D"width:60.0pt;padding:0in 0in 0in 0=
in">
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><a href=
=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><span style=
=3D"color:windowtext;text-decoration:none"><img border=3D"0" width=3D"73" h=
eight=3D"68" id=3D"Picture_x0020_1" src=3D"cid:[email-masked]=
D0" alt=3D"php5_zce_logo_new"></span></a><span style=3D"font-size:12.0pt"><=
o:p></o:p></span></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Lu=
cida Sans&quot;,&quot;sans-serif&quot;">Jon Whitcraft<br>
Indianapolis Motor Speedway<br>
</span><span style=3D"font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><a href=3D"mailto:[email-masked]"><span style=3D=
"font-size:10.0pt;
  font-family:&quot;Lucida Sans&quot;,&quot;sans-serif&quot;;color:blue">jw=
[email-masked]</span></a><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span s=
tyle=3D"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-ser=
if&quot;">P: (317) 492-8623 - F: (317) 492-6419</span><span style=3D"font-s=
ize:9.0pt;font-family:
  &quot;Arial&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><br clear=3D"all">
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<br>
<font face=3D"Arial" color=3D"Gray" size=3D"1">********************<br>
********************<br>
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify
 the sender by reply E-mail and erase this E-mail from your system. Your as=
sistance is appreciated. E-mail transmission may not be secure or error-fre=
e. The company is not responsible for any loss/damage arising from any viru=
s transmitted.<br>
********************<br>
********************<br>
</font>
</body>
</html>

--_000_6B4A8009371807499638509271DEA796011632DD6D7CIMSCMAIL1im_--

--_004_6B4A8009371807499638509271DEA796011632DD6D7CIMSCMAIL1im_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=2553;
	creation-date="Fri, 14 Aug 2009 16:12:47 GMT";
	modification-date="Fri, 14 Aug 2009 16:12:47 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_004_6B4A8009371807499638509271DEA796011632DD6D7CIMSCMAIL1im_--

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 9 Oct 2009 15:24:45 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code freeze for 1.9.4 starts Sunday night

Hey, all --

It's that time again: second and fourth Tuesday of each month are when
the bugfix release go out. As such, our next release, 1.9.4, will go out
this coming Tuesday, 13 October 2009. Code freeze will begin Sunday
evening, 11 October 2009. I'll try and have packages out for testing by
the end of the day on Monday; I'll also send an announcement once the
tag is created so that those who want to begin testing early can do so
from the tag.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 10:34:45 -0800
From: Kevin McArthur <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] New Sections for Zend Framework 2.0 Roadmap

Ok, my $0.02 (roll your eyes here)

Plugin stuff -- all sounds good... Maybe the "Interface" part of 
ConfigurableInterface is somewhat redundant.... or might be better as 
IConfigurable... (I assume this is about being worried that the PHP guys 
will add a same named interface in the future (ala the Date fiasco))

--

Zend-Form 2.0... I'm not a huge fan of the current (or this proposed) 
architecture. I'd rather see a component that takes PRG 
(Post-Redirect-Get) as the default mechanism and extrapolates interfaces 
from there... There should be strong integration with Zend_Session 2.0, 
and I'd like to see the Decorators and Translators moved to the view 
layer -- as they have little to do with the program logic and are purely 
presentation. The Decorators could be integrated tightly while still 
being independent of the validation specification. Zend_Form doesn't 
really need to know if data is coming from an input type=text, a 
textarea, or a select list... its all strings at the end of the process. 
I'd also recommend some sort of 'partial' for reusable forms decorator 
specs.

I'm thinking something like this (psuedo, hacked)

View (Form Partial);

<?php echo new Zend\Form\Field\Text('username') ?>

(Or)

<?php use \Zend\Form\Field; ?>
<?php echo new \Text('username',['elementNameReference']) ?>

View (Page)

<?php echo \Form('partialName'); ?>

Controller: (Action)

protected function _getWhateverForm() {
    $this->form = new \Form($config);
    $this->form->setSuccessRoute('routename'); // or equivilent set URI, 
goto, etc
    $this->form->setValidationErrorRoute('routename'); // or a constant 
depicting to redirect to self.
    $this->form->addElement* //... as normal for validators
    $this->form->setView('partialName'); // <--- where the decoration 
goes. (Or optionally a hand-coded form)
}

public function formAction() {
  if ($this->...->request->isPost()) {
     $this->form->process();
  } else {
      $this->form->display();
  }
}

Potentially code from _getWhateverForm could find itself in a model for 
reuse.

This is obviously a quick overview, but the idea is to more tightly tie 
Zend_Form in with the request cycle, assume PRG is the priority method 
for forms, and treat decoration in the view, not the model or controller.

--

The router changes look good as described...

Kevin

Matthew Weier O'Phinney wrote:
> Hey, all --
>
> There have been several new sections posted to the 2.0 roadmap that I
> want to bring to your attention:
>
>  * Plugins:
>    http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures 
>
>  * Zend_Form:
>    http://framework.zend.com/wiki/display/ZFDEV2/Zend_Form+2.0
>
>  * Router:
>    http://framework.zend.com/wiki/display/ZFDEV2/Zend_Controller_router+2.0
>
> Please review and comment when you have time.
>
> Thanks!
>
>   

nFrom nobody Wed Apr  7 08:46:07 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Giuseppe Roberti <[email-masked]>
To: [email-masked]
Date: Mon, 17 Aug 2009 03:57:35 +0200
Subject: Re: [zf-contributors] Duplicated find() on
	Zend_Session_SaveHandler_DbTable

--=-pMa7SyK91omMpOc1P+O9
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

There was an error, sorry.
Corrected patch attached.

On Mon, 2009-08-17 at 03:25 +0200, Giuseppe Roberti wrote:
> Hi list.
> 
> Walking thought the Zend Framework i have found that the
> Zend_Session_SaveHandler_DbTable do twice the find() over the associated
> DbTable; one in read() and another one in write().
> 
> Why ?
> Maybe there's some reason that i don't know.
> If not, here is a simple patch that erase this behavior.
> 
> Hope this is useful, thanks to all for the great job.
> 
-- 
Giuseppe Roberti <[email-masked]>

--=-pMa7SyK91omMpOc1P+O9
Content-Disposition: attachment;
	filename="zf-session-savehandler-dbtable-no-duplicate-find.patch"
Content-Type: text/x-patch;
	name="zf-session-savehandler-dbtable-no-duplicate-find.patch";
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

Index: DbTable.php
===================================================================
--- DbTable.php	(revision 17638)
+++ DbTable.php	(working copy)
@@ -127,6 +127,11 @@
     protected $_sessionName;
 
     /**
+     * Session rows from find()
+     */
+    protected $_rows = array();
+
+    /**
      * Constructor
      *
      * $config is an instance of Zend_Config or an array of key/value pairs containing configuration options for
@@ -319,6 +324,7 @@
 
         if (count($rows)) {
             if ($this->_getExpirationTime($row = $rows->current()) > time()) {
+                $this->_rows = $rows;
                 $return = $row->{$this->_dataColumn};
             } else {
                 $this->destroy($id);
@@ -342,7 +348,7 @@
         $data = array($this->_modifiedColumn => time(),
                       $this->_dataColumn     => (string) $data);
 
-        $rows = call_user_func_array(array(&$this, 'find'), $this->_getPrimary($id));
+        $rows = $this->_rows;
 
         if (count($rows)) {
             $data[$this->_lifetimeColumn] = $this->_getLifetime($rows->current());

--=-pMa7SyK91omMpOc1P+O9--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 17 Dec 2009 07:07:42 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] 2.0 Wishlist

-- Greg <[email-masked]> wrote
(on Thursday, 17 December 2009, 04:54 AM -0600):
> - Controllers as resource type so extending another controller doesn't
> incur a require statment to the parent class file.

This one might be possible using the resource autoloader, actually. I
may start looking into that.

That said, we typically encourage users to extend controllers via action
helpers instead of direct extension.

> - Tighter integration of Zend_Application throughout rest of other
> Zend_ components.

This has been happening, but it's been very gradual. As users find need
for bootstrapping components, they've either been directly contributing
resource plugins or requesting them.

> - View class name configurable via config. A couple of places force an
> instance of Zend_View unless the view class has already been
> instantiated and set.

This would be trivial to accommodate _now_. Could you file a feature
request, please?

> - Only create a view instance when needed.

The current assumption is that if you are executing a controller, a view
will be needed. 

In my prototype for the 2.0 MVC, this gets tossed out the door to a
degree. Instead of rendering the view from the controller, rendering is
done from the response -- which is when the view would actually be
instantiated, populated, and rendered. So what you suggest is already
in the planning. :)

> - Personal preference In relation to the latter; any assigned
> variables in the controller that are not protected or private are then
> automatically assigned to the View class when it is instantiated (i.e.
> after the execution of the controller Action method).

This one is a bit hard to justify when you consider action helpers. One
way action helpers can interact with the controller is via public
properties -- and the values they set/interact with may not be suitable
for the view object.

> - Zend Application options as a Zend_Config object, makes working with
> nested arrays easier using the chain syntax.

This has been a regular request, and already planned.

> - Zend_Application to be passed to various other components in
> replacement (where appropriate) of the config parameter. The Config
> can then be retrieved from Zend_Application and Zend_Application would
> also have a method for providing single instances of say Service
> objects.

This is already done. The bootstrap is injected into the front
controller, and thus into the router, dispatcher, and action
controllers. Within your action controller, you can do this:

    $bootstrap = $this->getInvokeArg('bootstrap');

and then access any resources you want.

> - Ability to override the execution of the part of the Action dispatch
> that calls the action method only but still keeps the surrounding pre
> and post Dispatch methods untouched.

You can do this already as well. The dispatcher calls
Zend_Controller_Action's run() method, which calls the dispatch()
method; you can override either one of these to alter the workflow
within the given controller.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: "Wil Sinclair" <[email-masked]>,
	<[email-masked]>
Date: Fri, 20 Mar 2009 21:41:37 +0100
Subject: Re: [zf-contributors] Release Policies and Conventions

Hy Wil,

"A mini release may contain only bug fixes. Note that no new features or API 
changes are allowed whatsoever."

This sentence could imply that new features are not allowed, but improvments 
of existing features are allowed as long as they don't change existing API. 
The word "only" could be overseen.

The question is also what's for us the difference between a feature 
enhancement and a new feature.
Feature Enhancement could be for example to add a new option. It would not 
change API. So a textual clearification would be great :-)

Also to note: Are new components allowed within minor releases or only 
within major releases? Should also be defined.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Wil Sinclair" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>; 
<[email-masked]>
Sent: Friday, March 20, 2009 9:31 PM
Subject: RE: [zf-contributors] Release Policies and Conventions

Hey Thomas, I'm not quite sure what you are referring to. Your
understanding is correct, and the wiki page seems to reflect it
perfectly. Can you tell me exactly what needs to be updated? Maybe with
the string that you're referring to?

Thanks.
,Wil

-----Original Message-----
From: Thomas Weidner [mailto:[email-masked]]
Sent: Friday, March 20, 2009 12:57 PM
To: Wil Sinclair; [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

Hy Wil,

In my understanding also "feature enhancements" are actually not allowed
to
be integrated within mini-releases.
Only "Bug fixes" which do not add additional API are allowed.

Maybe you should also add a definition for what's a bug fix, a
improvement
and a new feature to get that also defined, and we can all speak of the
same
in future.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 20, 2009 8:47 PM
Subject: [zf-contributors] Release Policies and Conventions

Over the 2 years that I've been involved with the project, there have
been many questions about what can go in to a given release and if there
are any guidelines for the release schedules. While many of you have
pieced the picture together from different mails, IRC chats, etc. I've
owed you a document for a long time now. Here it is:

http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
tions

I ask all contributors to review this and reply with any question or
edits- especially if I missed something- in this forum.

As always, thanks for all the time and effort. Also, go 1.8!

,Wil

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 10 Mar 2010 16:48:01 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 2.0 Status: 10 Mar 2010

Greetings!

Since the last update, myself and the team have been busy working on the
test suite. We had the following goals:

 * Strip (most) require_once calls
   If we're going to be an autoloading framework, unit tests should use
   autoloading as well.
 
 * Remove all AllTests.php files
   These are largely a relic of the early days of ZF development, and
   are not really needed anymore. You can specify specific directories
   in which to run tests, individual files, by group, and more;
   additionally, there are better tools for building test suites.

 * Create a phpunit.xml and test bootstrap
   This will allow us to specify rules for running tests, as well as the
   actual test environment for every test case.

 * Have all tests passing (or at least in the same state as trunk)

Ralph is working on Zend_Tool tests as I write this -- but that's the
last component to be reviewed. Otherwise, all the tasks above are now
accomplished. To run any tests, you simply change directory to the
tests/ subdirectory, and then call phpunit with any arguments you want
to specify (including directories or files).

Additionally, we've made some changes to Zend_Loader_Autoloader. Since
ZF users will likely be using both code with true PHP namespaces as well
as code using simply pre-5.3 style vendor prefixes, we introduced a set
of "registerPrefix" methods. The old familiar "registerNamespace"
methods will now work only for classes using PHP namespace notation.
This is definitely a BC break, but one that should be fairly trivial to
script a fix for in existing codebases.

Next on our list of "foundational tasks" to tackle:

 * Conversion to namespaces
 * Refactoring of exceptions

These tasks will likely take longer than what we've done to date. We are
aiming to balance automatic conversion, code readability, and
performance -- and I'm not expecting a good solution to present itself
on our first few tries. 

Until next time, happy programming!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 21 Dec 2009 09:01:15 -0600
From: Ralph Schindler <[email-masked]>
To: Carlton Gibson <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Status of ZF-6654 - Can/Should I take this on? 

Haha, no problem 

-ralph

On 12/21/09 6:23 AM, "Carlton Gibson" <[email-masked]> wrote:

> Sorry, cancel that. The issue was resolved in trunk on Thursday.
> 
> (Still can't read the issue tracker... :-)
> 
> On 21 Dec 2009, at 12:17, Carlton Gibson wrote:
> 
>> See: http://framework.zend.com/issues/browse/ZF-6654
>> 
>> Hi all, 
>> 
>> I've got a problem with chained routes not matching wildcards.
>> 
>> This kind of thing doesn't work:
>> 
>> $userRoute = new
>> Zend_Controller_Router_Route_Hostname(':nickname..'.$configuration->general->
>> domain,
>>                    array('controller'=>'profile', 'action'=>'view'));
>> 
>> $userActionsRoute =
>> new
>>  Zend_Controller_Router_Route(':action/*',
>> array('action'=>'view'));
>> $router->addRoute('uActionsRoute', $userRoute->chain($userActionsRoute));
>> 
>> ZF-6654 was opened for 1.8.1 but doesn't look as if it's received any
>> attention. 
>> 
>> There's a proposed fix but no test case.
>> 
>> I don't want to step on anyone's toes (the case is assigned to Ben Schlozen)
>> but if it's not being worked on, should I clear it up?
>> 
>> Regards,
>> Carlton
> 

-- 
Ralph Schindler
Software Engineer     | [email-masked]
Zend Framework        | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dennis Winter <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>
Date: Wed, 31 Mar 2010 16:38:10 +0200
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [zf-contributors] Plugin implementations

+1 on this! It's ok to have two methods for the same thing! And the  
benefit of clearer interfaces is overwhelming the disadvantages!
Just my 2 cents!

Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney  
<[email-masked]>:

> Greetings, all --
>
> Per the roadmap, one change we're planning on making is making plugin
> usage consistent across components: plugins will implement __invoke(),
> which makes them inherently callable.
>
> In our refactoring branch, I've done this now with Zend_Filter.  
> However,
> it required a ton of refactoring on the unit tests (had to either call
> __invoke() directly, or $filter($value)), and it got me to thinking:
>
> Would it make sense to keep the original interfaces (filter, isValid,
> render, etc.), but also implement __invoke() -- having it proxy to the
> appropriate interface method?
>
> As an example:
>
>    interface Filter
>    {
>        public function filter($value);
>        public function __invoke($value);
>    }
>
>    class Digits implements Filter
>    {
>        public function filter($value)
>        {
>            // ... logic...
>        }
>
>        public function __invoke($value)
>        {
>            return $this->filter($value);
>        }
>    }
>
> The benefits:
>
> * Fewer changes necessary to existing unit tests
> * interface method names may be more descriptive of intent
>
> Problems:
>
> * Using __invoke() introduces overhead -- 2 method calls instead of  
> one
> * Redundancy (two methods doing the same thing)
> * A few extra tests to write (to ensure __invoke works as expecte)
>
> After discussion with Ralph and Alex, I'm leaning towards having
> __invoke() as an _additional_ method, instead of replacing existing
> methods.
>
> Any thoughts or comments?
>
> -- 
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: [email-masked]
To: [email-masked]
Date: Mon, 08 Jun 2009 22:23:23 -0700
Subject: [zf-contributors] [email-masked]

Thanks in advance for subscription.

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 18:37:13 +0100
From: Giorgio Sironi <[email-masked]>
To: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--0016e6d64177b766540480703bbf
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 25, 2010 at 5:44 PM, Luke Crouch <[email-masked]> wrote:

> Maybe I'm turning into a crotchety old programmer, but I'm not really
> impressed with git. We switched from svn to git at my day job and I
> haven't really seen any big benefits aside from a few sweet syntactic
> shortcuts like git stash. For larger projects with well-organized
> branching I just haven't seen much additional value from git.
>

I'm also starting out with git. The point is in having the possibility to
branch at every moment of development, and to use those branches to merge
changes that would break the trunk. With distributed version control branch
is very cheap and people working on unstable components will be happier.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d64177b766540480703bbf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 25, 2010 at 5:44 PM, Luke Crouch <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrot=
e:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padd=
ing-left: 1ex;">
Maybe I&#39;m turning into a crotchety old programmer, but I&#39;m not real=
ly<br>
impressed with git. We switched from svn to git at my day job and I<br>
haven&#39;t really seen any big benefits aside from a few sweet syntactic<b=
r>
shortcuts like git stash. For larger projects with well-organized<br>
branching I just haven&#39;t seen much additional value from git.<br></bloc=
kquote><br>I&#39;m also starting out with git. The point is in having the p=
ossibility to branch at every moment of development, and to use those branc=
hes to merge changes that would break the trunk. With distributed version c=
ontrol branch is very cheap and people working on unstable components will =
be happier.<br>
</div><br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br><=
a href=3D"http://giorgiosironi.blogspot.com">http://giorgiosironi.blogspot.=
com</a><br><a href=3D"http://twitter.com/giorgiosironi">http://twitter.com/=
giorgiosironi</a><br>

--0016e6d64177b766540480703bbf--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 21:29:42 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0016e6d99d4635e562047832670f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 12, 2009 at 8:51 PM, Carlos Medina
<[email-masked]>wrote:

> 4) Getting rid of singletons.
>
> Well yes. I agree that. I think that the ZF should be easy and simple to
> use. At this moment i think that ZF pretend to be a big Framework for all
> and at the end will be used only for two or tree developer.
>

I could not understand if you favor singletons or their removal. Anyway,
"singletons are pathological liars" and presents global state which makes
hard to debug and test classes that use them. It is actually simpler to
provide a collaborator in the constructor instead of hide it in a singleton
accessed via static functions.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d99d4635e562047832670f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Nov 12, 2009 at 8:51 PM, Carlos Medina <=
span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">develop@=
simply-networks.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;">
<div class=3D"im">
4) Getting rid of singletons.<br>
<br></div>
Well yes. I agree that. I think that the ZF should be easy and simple to us=
e. At this moment i think that ZF pretend to be a big Framework for all and=
 at the end will be used only for two or tree developer.<br></blockquote>
<br>I could not understand if you favor singletons or their removal. Anyway=
, &quot;singletons are pathological liars&quot; and presents global state w=
hich makes hard to debug and test classes that use them. It is actually sim=
pler to provide a collaborator in the constructor instead of hide it in a s=
ingleton accessed via static functions.<br clear=3D"all">
</div><br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br><=
a href=3D"http://giorgiosironi.blogspot.com">http://giorgiosironi.blogspot.=
com</a><br><a href=3D"http://twitter.com/giorgiosironi">http://twitter.com/=
giorgiosironi</a><br>

--0016e6d99d4635e562047832670f--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: David Caunt <[email-masked]>
Date: Mon, 8 Feb 2010 11:46:56 +0000
To: Shawn Stratton <[email-masked]>
Cc: Nigel Chapman <[email-masked]>, 
	Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

--00151747965ae19677047f155c90
Content-Type: text/plain; charset=UTF-8

Hi Nigel, Shawn,

Unfortunately in the absence of this feature in SPL, we're forced to develop
wrappers. I think that's fine if the wrapper adds sufficient value, and I
believe Zend_Array does.

With regard to adapters, I think it's a great idea Nigel, and important for
the success of the component. It is by allowing easy consumption of
different types of data that Zend_Array can add significant value. The use
of filters and validators is a nice touch too.

I don't think this proposal will be accepted with built in methods that
produce HTML, and you'll be required to put helpers into
Zend/View/Helper/Array/* as is the case with Zend_Navigation. Your magic
methods can call these and it's easy for other developers to add or extend
existing renderers.

I see phplinq can pull data directly from a database. It might be nice for
one of your factory methods to take a Zend_Db[_Table]_Select object or
string SQL and to query for data.

I'll be happy to add my thoughts to the proposal page if you think they are
valid,

Dave

On 5 February 2010 17:30, Shawn Stratton <[email-masked]> wrote:

> Not to knock on the importance of what you're trying to do but wouldn't
> that really be a language level issue that should be handled in SPL or at
> least at the C level via Pecl?
>
> On Feb 5, 2010 1:59 AM, "Nigel Chapman" <[email-masked]> wrote:
>
> Hi All,  (? -- not sure how active this list is.)
>
> Just a note to announce a new proposal:
>
> Zend_Array is a fluent wrapper for PHP's array functions.
>
> It lets you deal with arrays rather as you would in Ruby or JQuery,
> with chained operators and closures.
>
> Over the next few weeks, I'll be workign on the doc standards and test
> suite, and thinking if it needs more (or less!) core methods.
>
> Comments? Improvements?
>
> * http://chapman.id.au/zend-array/
>
> * http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman
>
> I sometimes appear on #zftalk as kale77in.
>
> Thanks,
>
> Nigel.
>
>

-- 
Save Water...Drink Ouzo !

--00151747965ae19677047f155c90
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Nigel, Shawn,<div><br></div><div>Unfortunately in the absence of this fe=
ature in SPL, we&#39;re forced to develop wrappers. I think that&#39;s fine=
 if the wrapper adds sufficient value, and I believe Zend_Array does.</div>

<div><br></div><div><div>With regard to adapters, I think it&#39;s a great =
idea Nigel, and important for the success of the component. It is by allowi=
ng easy consumption of different types of data that Zend_Array can add sign=
ificant value. The use of filters and validators is a nice touch too.=C2=A0=
</div>

<div><br></div><div>I don&#39;t think this proposal will be accepted with b=
uilt in methods that produce HTML, and you&#39;ll be required to put helper=
s into Zend/View/Helper/Array/* as is the case with Zend_Navigation. Your m=
agic methods can call these and it&#39;s easy for other developers to add o=
r extend existing renderers.</div>

<div><br></div><div>I see phplinq can pull data directly from a database. I=
t might be nice for one of your factory methods to take a Zend_Db[_Table]_S=
elect object or string SQL and to query for data.</div><div><br></div>
<div>
I&#39;ll be happy to add my thoughts to the proposal page if you think they=
 are valid,</div><div><br></div><div>Dave</div><div><br><div class=3D"gmail=
_quote">On 5 February 2010 17:30, Shawn Stratton <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:[email-masked]">[email-masked]</a>&gt;</s=
pan> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><p>Not to knock on the importance of what y=
ou&#39;re trying to do but wouldn&#39;t that really be a language level iss=
ue that should be handled in SPL or at least at the C level via Pecl?</p>

<div><div></div><div class=3D"h5">
<p></p><blockquote type=3D"cite">On Feb 5, 2010 1:59 AM, &quot;Nigel Chapma=
n&quot; &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ni=
[email-masked]</a>&gt; wrote:<br><br>Hi All, =C2=A0(? -- not sure ho=
w active this list is.)<br>

<br>
Just a note to announce a new proposal:<br>
<br>
Zend_Array is a fluent wrapper for PHP&#39;s array functions.<br>
<br>
It lets you deal with arrays rather as you would in Ruby or JQuery,<br>
with chained operators and closures.<br>
<br>
Over the next few weeks, I&#39;ll be workign on the doc standards and test<=
br>
suite, and thinking if it needs more (or less!) core methods.<br>
<br>
Comments? Improvements?<br>
<br>
* <a href=3D"http://chapman.id.au/zend-array/" target=3D"_blank">http://cha=
pman.id.au/zend-array/</a><br>
<br>
* <a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nig=
el+Chapman" target=3D"_blank">http://framework.zend.com/wiki/display/ZFPROP=
/Zend_Array+-+Nigel+Chapman</a><br>
<br>
I sometimes appear on #zftalk as kale77in.<br>
<br>
Thanks,<br>
<font color=3D"#888888"><br>
Nigel.<br>
</font></blockquote><p></p>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water.=
..Drink Ouzo !<br>
</div></div>

--00151747965ae19677047f155c90--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 13:45:16 -0600
From: Tommy Smith <[email-masked]>
To: Eric Clemmons <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method 
	signatures

--000feae9a995a8ffd60481f03c5e
Content-Type: text/plain; charset=ISO-8859-1

Excellent (excellent) point Eric!

On Tue, Mar 16, 2010 at 1:38 PM, Eric Clemmons <[email-masked]> wrote:

> I too prefer to not have shorthand assignments using "AS".  You can dig
> through the Dojo codebase and see all sorts of "d., dc., dq., etc."
> shorthand that ultimately is more confusing, even though it's concise.
>
> There's a balance between having a wall of text because of verbose names
> and obfuscating code via shorthand.  We already know the problems with
> nondescript variable names.  Let's not fall into the same bad practices
> because we have a new toy to play with (namespaces).
>
>
> On Mar 16, 2010, at 2:26 PM, Ralph Schindler wrote:
>
> > Response inline..
> >
> >>> <?php
> >>> // this class has a use statement
> >>>
> >>> namespace Foo;
> >>> use Qux\Garply as garp;
> >>>
> >>> class Bar
> >>> {
> >>> // this method accepts an instance of Qux\Garply\Bar
> >>> public static function baz(garp\Bar $bar) {}
> >>> }
> >> And this one too, though you could "use" whole Qux\Garply\Bar as QGBar
> as well :)
> >
> > This is actually pretty close to my point.
> >
> > It's clear to people consuming Zend Framework classes that Bar inside the
> method signature means Foo\Bar.  The question comes in when people are
> consuming a class that has outside dependencies (like the example above).
> >
> > How is a developer suppose to know what the QGBar alias is short for?
> Moreover, if we are to use alias in method signatures, what kind of naming
> convention should be in play?
> >
> > Additionally, do we restrict it to importing full namespaces? Or would we
> allow importing of single classes?  Do we allow importing an aliased class
> into a File and use that inside a method signature?
> >
> > Imagine this:
> >
> > <?php
> > namespace Zend\Some\NS;
> > use \ArrayObject as Container;
> >
> > class Foo
> > {
> >   public function doSomething(Container $c);
> > }
> > ?>
> >
> > This is totally possible, and you could argue that its a superb use of
> namespaces.  Some might argue that it borders on runkit functionality (the
> ability to alias names bit). How is a developer suppose to know simply by
> looking at the method signature that he just needs to supply an ArrayObject?
> >
> > Do we simply rely on tools to tell us what Container really means?
> >
> > I totally agree with using "namespace resolved names" for method
> signatures, but I am skeptical on whether using "use resolved names" is
> going to produce easy to use APIs.
> >
> >
> >
> >>> One thing to notice is that if method signatures contain a fully
> >>> qualified name (those starting with a \) for type hints, you don't need
> >>> to know anything about what namespaces or aliases are in play;
> >>> everything you need to know is right in front of you. However, on the
> >> I have faith that Framework developers actually can remember inside
> which class and namespace they are :)
> >
> >
> > By "Framework developers" do you mean people writing ZF code? or people
> consuming ZF code?  I actually don't care about the burden put on people
> writing code for ZF, b/c you only need to write it once.  It's the burden
> put on the consumers of the ZF library of code that I feel is more
> important.
> >
> >
> >>> Should library/framework specific code be more expressive using fully
> >>> qualified names in method signatures and consequently in docblocks? Or
> >>> is using unqualified names just as easy to understand and/or more
> readable?
> >> Docblocks present interesting challenge, if they are used for typing
> purposes. I guess there some solution might be needed, but maybe smart tools
> can solve it...
> >
> > I am guessing that docblock class names should probably be using the same
> namespace and use rule resolution that classes use.
> >
> > -ralph
>
>

--000feae9a995a8ffd60481f03c5e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Excellent (excellent) point Eric!<br><br><div class=3D"gmail_quote">On Tue,=
 Mar 16, 2010 at 1:38 PM, Eric Clemmons <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">
I too prefer to not have shorthand assignments using &quot;AS&quot;. =A0You=
 can dig through the Dojo codebase and see all sorts of &quot;d., dc., dq.,=
 etc.&quot; shorthand that ultimately is more confusing, even though it&#39=
;s concise.<br>

<br>
There&#39;s a balance between having a wall of text because of verbose name=
s and obfuscating code via shorthand. =A0We already know the problems with =
nondescript variable names. =A0Let&#39;s not fall into the same bad practic=
es because we have a new toy to play with (namespaces).<br>

<br>
<br>
On Mar 16, 2010, at 2:26 PM, Ralph Schindler wrote:<br>
<br>
&gt; Response inline..<br>
&gt;<br>
&gt;&gt;&gt; &lt;?php<br>
&gt;&gt;&gt; // this class has a use statement<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; namespace Foo;<br>
&gt;&gt;&gt; use Qux\Garply as garp;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; class Bar<br>
&gt;&gt;&gt; {<br>
&gt;&gt;&gt; // this method accepts an instance of Qux\Garply\Bar<br>
&gt;&gt;&gt; public static function baz(garp\Bar $bar) {}<br>
&gt;&gt;&gt; }<br>
&gt;&gt; And this one too, though you could &quot;use&quot; whole Qux\Garpl=
y\Bar as QGBar as well :)<br>
&gt;<br>
&gt; This is actually pretty close to my point.<br>
&gt;<br>
&gt; It&#39;s clear to people consuming Zend Framework classes that Bar ins=
ide the method signature means Foo\Bar. =A0The question comes in when peopl=
e are consuming a class that has outside dependencies (like the example abo=
ve).<br>

&gt;<br>
&gt; How is a developer suppose to know what the QGBar alias is short for? =
Moreover, if we are to use alias in method signatures, what kind of naming =
convention should be in play?<br>
&gt;<br>
&gt; Additionally, do we restrict it to importing full namespaces? Or would=
 we allow importing of single classes? =A0Do we allow importing an aliased =
class into a File and use that inside a method signature?<br>
&gt;<br>
&gt; Imagine this:<br>
&gt;<br>
&gt; &lt;?php<br>
&gt; namespace Zend\Some\NS;<br>
&gt; use \ArrayObject as Container;<br>
&gt;<br>
&gt; class Foo<br>
&gt; {<br>
&gt; =A0 public function doSomething(Container $c);<br>
&gt; }<br>
&gt; ?&gt;<br>
&gt;<br>
&gt; This is totally possible, and you could argue that its a superb use of=
 namespaces. =A0Some might argue that it borders on runkit functionality (t=
he ability to alias names bit). How is a developer suppose to know simply b=
y looking at the method signature that he just needs to supply an ArrayObje=
ct?<br>

&gt;<br>
&gt; Do we simply rely on tools to tell us what Container really means?<br>
&gt;<br>
&gt; I totally agree with using &quot;namespace resolved names&quot; for me=
thod signatures, but I am skeptical on whether using &quot;use resolved nam=
es&quot; is going to produce easy to use APIs.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt;&gt; One thing to notice is that if method signatures contain a ful=
ly<br>
&gt;&gt;&gt; qualified name (those starting with a \) for type hints, you d=
on&#39;t need<br>
&gt;&gt;&gt; to know anything about what namespaces or aliases are in play;=
<br>
&gt;&gt;&gt; everything you need to know is right in front of you. However,=
 on the<br>
&gt;&gt; I have faith that Framework developers actually can remember insid=
e which class and namespace they are :)<br>
&gt;<br>
&gt;<br>
&gt; By &quot;Framework developers&quot; do you mean people writing ZF code=
? or people consuming ZF code? =A0I actually don&#39;t care about the burde=
n put on people writing code for ZF, b/c you only need to write it once. =
=A0It&#39;s the burden put on the consumers of the ZF library of code that =
I feel is more important.<br>

&gt;<br>
&gt;<br>
&gt;&gt;&gt; Should library/framework specific code be more expressive usin=
g fully<br>
&gt;&gt;&gt; qualified names in method signatures and consequently in docbl=
ocks? Or<br>
&gt;&gt;&gt; is using unqualified names just as easy to understand and/or m=
ore readable?<br>
&gt;&gt; Docblocks present interesting challenge, if they are used for typi=
ng purposes. I guess there some solution might be needed, but maybe smart t=
ools can solve it...<br>
&gt;<br>
&gt; I am guessing that docblock class names should probably be using the s=
ame namespace and use rule resolution that classes use.<br>
&gt;<br>
&gt; -ralph<br>
<br>
</blockquote></div><br>

--000feae9a995a8ffd60481f03c5e--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Renan de Lima <[email-masked]>
Date: Fri, 26 Feb 2010 18:46:41 -0300
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

Nice! ZFf 2.0!! :-D

About package dependencies...
I think it could be nice if we should prepare it for 2 (or more)
levels of dependency (or relashionship):
    1 - strong, some package that does not work without other
(example: Zend\Soap and Zend\Server)
    2 - weak, when the dependency is just a suggestion (example:
Zend\Auth and Zend\Db)

For end-users we could provide a download picker as well, like this:
http://phpjs.org/packages/configure

On 26 February 2010 10:59, Matthew Weier O'Phinney <[email-masked]> wrote=
:
> Hey, all --
>
> This is the first in a series of emails I'll be posting to this list
> with status updates on 2.0. I plan to do these several times a week
> throughout the process.
>
> Since branching 2.0 a couple days ago, I've been busy working on
> stripping require_once calls from the ZF library.
>
> My initial idea was to simply run the same find/sed script from the
> performance guide, but quickly discarded this for two reasons:
>
> =C2=A0* It only comments out those lines. Yes, it can be modified to remo=
ve
> =C2=A0 the lines as well, but this does not address other concerns such a=
s
> =C2=A0 preceding docblocks.
>
> =C2=A0* To package individual components, we need some way to determine
> =C2=A0 dependencies. Currently, require_once statements can help with tha=
t,
> =C2=A0 but stripping them makes this harder. My solution is to add @uses
> =C2=A0 annotations at the class docblock level. This assists the API docs=
,
> =C2=A0 but also should make it possible to use automated scanners to
> =C2=A0 determine dependencies.
>
> To accomodate these concerns, the process has to be manual. I've
> currently completed the top-level classes, and all components through
> Zend_Config. I'm committing to a local git branch incrementally, and
> will be pushing a squashed commit to the development-2.0 branch once
> complete.
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--
Renan de Lima Barbosa
gtalk/msn: [email-masked]
skype: renandelima
+55 61 8166-7755
renandelima.com

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 27 Jul 2009 09:37:03 -0700
From: Christoph Dorn <[email-masked]>
Reply-To: [email-masked]
To: Thomas Weidner <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Contributor list

> we have since several months a contributor list.
> http://framework.zend.com/wiki/pages/viewpage.action?pageId=11036
>
> Now for 1.9 it's time again to update this list.
> Every contributor/maintainer/component lead is announced to update 
> this list with his own informations within the proper component.

I know this has been discussed in the past but I want to bring up 
another suggestion for the use of annotations to maintain a contributor 
list such as this.

I agree with the problems around using @author tags but the consequences 
seem to outweigh the arguments against it. It would be very handy to 
know who to contact if you have a specific issue with or want to help 
out on a component.

Maybe we can introduce a @zf-lead or @zf-maintainer tag on a 
class-level. The class/component may have many authors but it usually 
only has one lead and one or a few maintainers. Such a tag would afford 
us to:

- Auto-generate the contributor (better called the "maintainer") list
- Potentially motivate leads and maintainers to maintain the classes 
since their name is attached to it and publicly reflects upon their 
commitment
- Track role transitions between people by monitoring these tags and 
issuing announcement emails. Such emails could be great catalysts to get 
older components back on track as new leads and maintainers usually are 
motivated to work on the component and will take user-feedback about 
priorities into account.

At the moment there is no real consequence for not maintaining a 
component as nobody knows who is responsible (except for a few people).

Going one step further, we could offer prizes on a monthly or minor 
release cycle for the maintainer who has contributed most to the 
components they are responsible for. Fostering a culture where 
maintenance efforts are publicly appreciated could go a log way towards 
reducing code rot.

Christoph

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 16:29:37 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

-- Nico Edtinger <[email-masked]> wrote
(on Thursday, 12 November 2009, 09:41 PM +0100):
> Kevin McArthur wrote:
> 
>     1 ) Unified constructor. All constructors will (optionally) accept an array
>     of options or Zend_Config object as the first argument.
> 
>     I take exception to this because, well, it's just going to kill performance
>     -- and it doesn't follow industry standard techniques for this type of
>     thing. This shouldn't be a rule as a ton of classes have no reason to be
>     configurable, or make a lot more sense to take real parameters, rather than
>     instantiating a new object. Instead, I recommend a Configurable interface
>     which _may_ mark classes as configurable as needed.
> 
> 
> But most of the components have at least one entry class, that is configurable.
> 
> I see another problem, but maybe it's just the example implementation. In a
> couple of components the options can't or shouldn't be changed after the
> constructor. The components just get more complicated if we don't let them
> initialize to a defined state, just to make them more configurable. Therefore
> not all components will have setOptions() and setXXX() methods, but they may
> take an object or array for their parameters in the constructor.

The reference implementation I provided is not necessarily intended for
usage in all components, only for those that follow the option => setter
paradigm. It's primary purpose is to consolidate existing code into a
single location to reduce code duplication. If individual components
and/or classes need to initialize differently, they will.

The "Unified" portion of the description is simply to indicate that this
pattern (passing an array and/or Zend_Config object to the constructor,
not how they are handled) will be used throughout the framework for
configurable objects.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked],
 James Dempster <[email-masked]>
Date: Mon, 5 Oct 2009 04:37:55 +0200
Subject: Re: [zf-contributors] Google Wave - public waves, tagging, contacts

--Boundary-01=_DwVyKvwn0dpuVZX
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Monday 05 October 2009 00:37:45 you wrote:
>Was wondering if you've looked into any of their APIs?
>=20

It was pretty quick and easy to get a hello world wave robot deployed to th=
e=20
app-engine. The google eclipse plugin is great and there's quite a few=20
different sample robots with code.

So using the java API it was really easy to create a simple robot, there's =
a=20
base class AbstractRobotServlet which pretty much automatically takes care =
of=20
your http and json handling. To manipulate a wave you need to use the main=
=20
hook method processEvents(). This method automatically gets called and pass=
ed=20
an object of RobotMessageBundle type every time an event happens in the wav=
e.=20

The message bundle has accessors to allow you to discover what just happene=
d=20
in the wave (type of event such as new participant, new post etc) and allow=
s=20
you to grab the sub wavelets or blips for manipulation.

Any events called inside the execution of processEvents(), such as adding o=
r=20
modifying a blip & creating a new wavelet or blip, will be sent to the wave=
=20
when the method exits.

So not having spent much time with java in the last five years, I was reall=
y=20
impressed. Even if you don't know java you shouldn't have too much trouble=
=20
getting a simple bot up and running, the java API methods seem intuitive at=
=20
least from my perspective. It's really simple to grab what you want from a=
=20
wave. A simplified way to think of a robot is that it performs much the sam=
e=20
function that an IRC bot does.

If you don't like the verbosity of java there's a python version, I've not =
had=20
time to look at this to compare it to the java version.

There's also a gadget API (javascript), this provides your way to customise=
=20
the in-wave experience with mini web apps. I've not looked at this in detai=
l=20
yet but clearly combining gadgets with robots to produce collaborative resu=
lts=20
is what wave is really all about.

The embed API is simple to use, include the embjed.js then instantiate the =
js=20
wave object and configure it before initialising it into some container. It=
=20
will load it's own iframe.

var wave =3D new WavePanel('https://wave.google.com/wave/');
wave.setUIConfig('white', 'black', 'Arial', '12px');
wave.loadWave('googlewave.com!w+FOOBARWAVEID');
wave.init(document.getElementById('wave'))

=2D-=20
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D
 =E2=98=98 Oscar Wilde

--Boundary-01=_DwVyKvwn0dpuVZX
Content-Type: text/html;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-=
html40/strict.dtd">
<html><head><meta name=3D"qrichtext" content=3D"1" /><style type=3D"text/cs=
s">
p, li { white-space: pre-wrap; }
</style></head><body style=3D" font-family:'DejaVu Sans Mono'; font-size:9p=
t; font-weight:400; font-style:normal;">
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">On Monday 0=
5 October 2009 00:37:45 you wrote:</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt;Was won=
dering if you've looked into any of their APIs?</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; </p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0;"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">It was pret=
ty quick and easy to get a hello world wave robot deployed to the app-engin=
e. The google eclipse plugin is great and there's quite a few different sam=
ple robots with code.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0;"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">So using th=
e java API it was really easy to create a simple robot, there's a base clas=
s <span style=3D" font-family:'Courier New,courier';">AbstractRobotServlet =
which pretty much automatically takes care of your http and json handling. =
To manipulate a wave you need to use the main hook method processEvents(). =
This method automatically gets called and passed an object of RobotMessageB=
undle type every time an event happens in the wave. </span></p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span style=
=3D" font-family:'Courier New,courier';">The message bundle has accessors t=
o allow you to discover what just happened in the wave (type of event such =
as new participant, new post etc) and allows you to grab the sub wavelets o=
r blips for manipulation.</span></p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span style=
=3D" font-family:'Courier New,courier';">Any events called inside the execu=
tion of processEvents(), such as adding or modifying a blip &amp; creating =
a new wavelet or blip, will be sent to the wave when the method exits.</spa=
n></p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span style=
=3D" font-family:'Courier New,courier';">So not having spent much time with=
 java in the last five years, I was really impressed. Even if you don't kno=
w java you shouldn't have too much trouble getting a simple bot up and runn=
ing, the java API methods seem intuitive at least from my perspective. It's=
 really simple to grab what you want from a wave. A simplified way to think=
 of a robot is that it performs much the same function that an IRC bot does=
=2E</span></p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span style=
=3D" font-family:'Courier New,courier';">If you don't like the verbosity of=
 java there's a python version, I've not had time to look at this to compar=
e it to the java version.</span></p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span style=
=3D" font-family:'Courier New,courier';">There's also a gadget API (javascr=
ipt), this provides your way to customise the in-wave experience with mini =
web apps. I've not looked at this in detail yet but clearly combining gadge=
ts with robots to produce collaborative results is what wave is really all =
about.</span></p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span style=
=3D" font-family:'Courier New,courier';">The embed API is simple to use, in=
clude the embjed.js then instantiate the js wave object and configure it be=
fore initialising it into some container. It will load it's own iframe.</sp=
an></p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span style=
=3D" font-family:'Courier New,courier';">var wave =3D new WavePanel('https:=
//wave.google.com/wave/');</span></p>
<pre style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-r=
ight:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span sty=
le=3D" font-family:'Courier New,courier';">wave.setUIConfig(</span><span st=
yle=3D" font-family:'Courier New,courier';">'white'</span><span style=3D" f=
ont-family:'Courier New,courier';">, </span><span style=3D" font-family:'Co=
urier New,courier';">'black'</span><span style=3D" font-family:'Courier New=
,courier';">, </span><span style=3D" font-family:'Courier New,courier';">'A=
rial'</span><span style=3D" font-family:'Courier New,courier';">, </span><s=
pan style=3D" font-family:'Courier New,courier';">'12px'</span><span style=
=3D" font-family:'Courier New,courier';">);</span></pre>
<pre style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-r=
ight:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span sty=
le=3D" font-family:'Courier New,courier';">wave.loadWave(</span><span style=
=3D" font-family:'Courier New,courier';">'googlewave.com!w+FOOBARWAVEID'</s=
pan><span style=3D" font-family:'Courier New,courier';">);</span></pre>
<pre style=3D" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-=
right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><span st=
yle=3D" font-family:'Courier New,courier';">wave.init(document.getElementBy=
Id('wave'))</span></pre>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0; font-family:'Courier New,courier';"></p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">-- </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">=E2=80=9CEx=
perience is the name everyone gives to their mistakes.=E2=80=9D</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-rig=
ht:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"> =E2=98=98 =
Oscar Wilde</p></body></html>
--Boundary-01=_DwVyKvwn0dpuVZX--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 13 Apr 2009 09:28:52 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

-- Benjamin Eberlei <[email-masked]> wrote
(on Monday, 13 April 2009, 02:55 PM +0200):
> Super, i like that with the interface name + abstract suffix, although in my 
> opinion an abstract prefix is much more readable since its in the english 
> languages natural flow.

The main reasons for using a suffix instead of a prefix have to do with
not pushing abstracts artificially earlier in the directory listings.

> so, since you mention it. how will namespace resolving be done with 
> autoloading? i.e. what will the directory structure / namespace /class 
> structure look like?

Still working on this part. Our needs will be different than PEAR's for
some obvious reasons (since they release individual packages). I'll be
looking at this more closely following the 1.8 release.

> On Monday 13 April 2009 14:49:06 Matthew Weier O'Phinney wrote:
> > I'm going to break a couple of rules here: I'm replying to my own email,
> > as well as top-posting. Bear with me...
> >
> > Robin S. raised an interesting point that Matt R. picked up and agreed
> > with:
> >
> >     I also notice that namespaces are written in Uppercase\Notation --
> >     Zend\Controller\Request. Will this be the standard? Another
> >     alternative is zend\controller\Request, which clearly distinguishes
> >     what's the namespace and what's the class/interface.
> >
> > Additionally, it seems the primary push-back is with abstract class
> > naming, particularly when there are also interfaces defined in the same
> > namespace.
> >
> > After reading these responses, I reached out to some friends in the PEAR
> > community, some of whom I've spoken with before about these issues. "Why
> > PEAR?" some may ask. ZF standards are based on PEAR standards. One goal
> > since the beginning of the ZF project has been to promote
> > interoperability with established standards. PEAR CS are the "gold
> > standard" in the PHP community, and whether you like or agree with them
> > or not, they are used widely.
> >
> > The PEAR Group has been debating new standards to adopt for PEAR2 for
> > some time now. PEAR2 is targeting a minimum required version of PHP 5.3,
> > so they are addressing the very same issues we're discussing. They have
> > also basically reached consensus, though they have not formally adopted
> > the new standards yet. When it comes to namespaces and class naming, it
> > is the ZF team's opinion that we need to be as close to PEAR standards
> > as possible.
> >
> > The relevant documents are here:
> >
> >     http://wiki.php.net/pear/rfc/pear2_class_naming
> >     http://wiki.php.net/pear/rfc/pear2_naming_standards
> >
> > In a nutshell, here's what they define:
> >
> >  * Namespaces are lowercase: zend\codegenerator\php
> >  * Class names are MixedCase: zend\codegenerator\php\File
> >  * Namespaces may contain underscores, but they do not translate to the
> >    directory separator
> >  * Class names may contain underscores, and they *do* translate to the
> >    directory separator
> >  * Interfaces should be named descriptively, and not contain the word
> >    "Interface" or the sigil "I".
> >  * It is preferred that Abstract classes are also named descriptively,
> >    but *may* contain the *suffix* Abstract.
> >
> > There are some good arguments for each point in the linked RFCs.
> >
> > I think that adopting these standards addresses most concerns the ZF
> > team has, as well as many if not most concerns posted in this thread.
> >
> > -- Matthew Weier O'Phinney <[email-masked]> wrote
> >
> > (on Friday, 10 April 2009, 02:24 PM -0400):
> > > Greetings, all --
> > >
> > > Below is a proposal I am making to modify the Zend Framework Coding
> > > Standards conventions for the naming of Interfaces and Abstract classes.
> > >
> > > This decision is basically already made, but I'd appreciate any feedback
> > > that you may have on the matter.
> > >
> > > Thanks!
> > >
> > > The problem
> > > ===========
> > > PHP 5.3 introduces namespaces to the PHP language. While this won't have
> > > an impact much on userland code, it will have an impact on library and
> > > framework code, as it provides a useful paradigm for organizing
> > > components as well as simplifying syntax. Instead of having to say things
> > > like:
> > >
> > >     $analyzer = new
> > > Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> > >
> > > we can instead do something like this:
> > >
> > >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > >
> > >     $analyzer = new Common_TextNum();
> > >
> > > or even:
> > >
> > >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > >
> > >     class Common_TextNum extends Common
> > >     {
> > >     }
> > >
> > > The problem that arises for Zend Framework has to do with how we name
> > > abstract classes and interfaces. Currently, the final segment of such
> > > classes are expected to end with _Abstract and _Interface, respectively.
> > > This will not work when we migrate to utilize namespaces, for two
> > > reasons.
> > >
> > > First, and most obviously, 'abstract' and 'interface' are reserved PHP
> > > keywords. As such, in situations such as the following:
> > >
> > >     namespace Zend\Controller\Request;
> > >
> > >     class Abstract
> > >     {
> > >     }
> > >
> > >     // or:
> > >
> > >     namespace Zend\Controller\Dispatcher;
> > >
> > >     interface Interface
> > >     {
> > >     }
> > >
> > > we'll run into issues.
> > >
> > > Second, and less obvious, is that perhaps the easiest solution breaks one
> > > of the key principles of namespaces (which are designed to help
> > > encapsulate components). This one's harder to explain, so let's look at
> > > examples. Consider a component such as Zend_Controller_Request. The
> > > simplest solution would be to name the abstract class or interface
> > > Zend\Controller\Request, and then have the various concrete
> > > implementations under that namespace:
> > >
> > >     namespace Zend\Controller;
> > >
> > >     interface Request
> > >     {
> > >     }
> > >
> > >     // and concrete ones:
> > >
> > >     namespace Zend\Controller\Request;
> > >
> > >     class Http
> > >     {
> > >     }
> > >
> > > What's the problem here? The interface is not in the same namespace as
> > > the concrete implementations.
> > >
> > > Potential solutions and recommendation
> > > ======================================
> > > So, how should Zend Framework "solve" these issues? A number of proposals
> > > and recommendations have been floated around, both within ZF circles and
> > > in the greater PHP community.
> > >
> > > Considerations include:
> > >
> > >  * Avoiding the use of PHP reserved keywords (already noted).
> > >  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
> > > name describe its type -- which, to a degree, the current naming
> > > conventions already violate). (See
> > > http://en.wikipedia.org/wiki/Hungarian_Notation, the sections
> > > "Disadvantages of Systems Hungarian" and "Notable Opinions" for some of
> > > the arguments against using Hungarian Notation.)
> > >
> > > Approaches that have been considered include:
> > >
> > >  * Using 'I' to prefix interfaces. This derives from standards in other
> > >    programming languages (.Net and python, in particular). This is just
> > > another form of Hungarian Notation, however.
> > >
> > >  * Using "Interface" or "Abstract" as a class name suffix:
> > > RequestInterface, RequestAbstract. Again, however this is Hungarian
> > > Notation.
> > >
> > >  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
> > > Base. This is just substituting the word Base for Abstract, however, and
> > > is really not much different than the above.
> > >
> > >  * Use generic, descriptive names indicative of functionality or
> > > behavior. As examples from the SPL, "Countable", "Iterator",
> > > "ArrayObject".
> > >
> > > My recommendation is to use the latter, as it solves all considerations.
> > > It will take more thought when naming, but will ensure that components
> > > can live in a self-contained namespace, do not use reserved keywords, and
> > > avoid Hungarian Notation.
> > >
> > > Plan for implementation
> > > =======================
> > > I recommend that the Coding Standards documentation be updated to reflect
> > > this approach.
> > >
> > > All new components going into 1.8 and onwards should adopt these
> > > standards. In releases 1.9 and forward, we will begin migrating existing
> > > interfaces/abstract classe. First, new classes/interfaces will be created
> > > that follow these conventions and which extend the originals; later, any
> > > type-hinting based on the original class/interface names will be updated
> > > to point to the new names; and finally, in 2.0, we will remove the old
> > > interfaces/abstract classes entirely.
> > >
> > > --
> > > Matthew Weier O'Phinney
> > > Software Architect      | [email-masked]
> > > Zend Framework          | http://framework.zend.com/
> 
> -- 
> Benjamin Eberlei
> http://www.beberlei.de
> 

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 16:51:49 +0100
From: [email-masked]
To: [email-masked]
Subject: [zf-contributors] ZF 2.0 option classes for methods

For easy usage of methods is it possible, to add option classes for metho=
ds that accept options as array or Zend_Config?

Code Assist in IDE's would propose the appropriate options including desc=
ription.

/**
 * @property-read string $host     What host to connect to...
 * @property-read string $username Connect to the database...
 * @property-read string $password Password associated with the...
 * @property-read string $dbname   The name of the database to user
 */
class Zend_Db_Options___Factory extends Zend_Config {
}

$options =3D new Zend_Db_Options___Factory();
$options->host =3D '127.0.0.1';
$options->username =3D 'webuser';
$options->password =3D 'xxxxxxxx';
$options->dbname =3D 'test';

$db =3D Zend_Db::factory('Pdo_Mysql', $options);

For performance reasons, it is easy to convert the above code to native a=
rray if needed.

$options =3D array(
	'host' =3D> '127.0.0.1',
	'username' =3D> 'webuser',
	'password' =3D> 'xxxxxxxx',
	'dbname' =3D> 'test'
);

Michael Rasmussen

PS: I hope you understand my english.

--=20
GMX DSL: Internet, Telefon und Entertainment f=FCr nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 14 Sep 2009 10:10:06 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Announcement: Monthly Bug Hunt!

--0-782210412-1252948206=:85689
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'll be there - I hope to see lot's more turning up over the hunt too.=0A=
=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivet=
hedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=0A=
=0A=0A________________________________=0AFrom: Matthew Weier O'Phinney <mat=
[email-masked]>=0ATo: [email-masked]=0ASent: Monday, Septemb=
er 14, 2009 5:55:25 PM=0ASubject: [zf-contributors] Announcement: Monthly B=
ug Hunt!=0A=0AGreetings, one and all!=0A=0AI've alluded several times in th=
e past month to having a plan for=0Ahelping manage our ever-growing bug lis=
t in the issue tracker. We're now=0Aready to roll out phase one of this pla=
n, and we need *you*!=0A=0AStarting this month, we will be sponsoring two b=
ug hunt days monthly, on=0Athe third Thursday and Friday of the month. That=
's this upcoming=0AThursday and Friday, 17-18 September 2009.=0A=0ADuring t=
hose days, the Zend team -- myself, Ralph, and Alex -- will be=0Ain #zftalk=
.dev on Freenode for our entire work day (Ralph and myself are=0Ain the Uni=
ted States, Alex is based in Russia; figure out the timezones=0Ayourself (-=
: ). We will be triaging bugs ourselves, but, more=0Aimportantly, we will b=
e there to help facilitate *you*, our contributors=0Aand users, in resolvin=
g issue reports. =0A=0AAs an incentive, each month, we will ship a Zend Fra=
mework t-shirt to=0Athe individual that assists in the most issue resolutio=
ns during the bug=0Ahunt days, whether via patches or direct commits. Quart=
erly, we will=0Aevaluate overall contributions, including documentation, bu=
g fixes, and=0Anewly contributed components, and award a developer with the=
ir choice of=0Aa Zend Studio license or Zend Framework Certification vouche=
r. (Caveat:=0Aone t-shirt per person per year, and one license/voucher per =
person per=0Ayear, folks!) =0A=0AFor those interested in participating in t=
he bug hunt days, the rules=0Aare simple: have a signed CLA on file, and re=
solve issues in the=0Atracker. =0A=0AIf you have not yet signed a CLA and w=
ant to participate, you can get a=0Acopy of the form here:=0A=0A    http://=
framework.zend.com/cla=0A=0ASign it and return it (you can email it, fax it=
, or send it via post);=0Aif you send it via post, you'll need to wait for =
confirmation that=0Awe've received it before we can accept code contributio=
ns from you.=0A=0ANow, when it comes to the issue tracker, you'll need to d=
etermine if the=0Aissue:=0A=0A* is simply the reporter misunderstanding or =
misusing code OR=0A* is a request for a new feature OR=0A* is a reproducibl=
e issue=0A=0AIn the first case, comment on it and indicate the correct usag=
e, and ask=0Athe component maintainer or somebody from Zend to review your =
response=0Aand mark the issue as resolved. In the second case, please try a=
nd focus=0Aon issue reports instead of feature requests during the bug hunt=
 days.=0A=0AThat brings us to the final case, reproducible issue reports. W=
ith=0Athese, you'll need to do the following:=0A=0A* Capture the reproduce =
case as a unit test=0A* Resolve the issue in such a way as to maintain back=
wards=0A   compatibility with existing usage. (In other words, don't change=
 the=0A   signature of a method unless the signature is what is actually=0A=
   broken.)=0A=0AFrom there, you then have two options:=0A=0A* If you alrea=
dy have commit access, commit the test and fix to the=0A   repository, and =
either resolve the issue or ask somebody from Zend to=0A   review and resol=
ve.  Don't forget to merge your changes to the 1.9=0A   release branch!=0A=
=0A* If you do not have commit rights, create a patch with the unit test=0A=
   and fix, and attach the patch to the issue. Ask the maintainer or=0A   s=
omebody from Zend to review and apply the patch.=0A=0AIf you need help crea=
ting the unit test or patch file, hop onto the=0A#zftalk.dev IRC channel an=
d ask for help.=0A=0AHow should you choose issues to work on? Answer the fo=
llowing questions,=0Aand you should be able to hop right in:=0A=0A* What co=
mponents do you have expertise in?=0A* What components are you interested i=
n learning more about?=0A* What issues have a high number of voters or watc=
hers?=0A=0ABug hunting should be fun, so pick components and issues you're=
=0Ainterested in. Ask questions on IRC if you don't understand how=0Asometh=
ing works.=0A=0ASo, spread the word, and come prepared this week to help ma=
ke the=0Aframework even better! I look forward to seeing you on IRC this we=
ek!=0A=0A-- =0AMatthew Weier O'Phinney=0AProject Lead            | matthew@=
zend.com=0AZend Framework          | http://framework.zend.com/=0A
--0-782210412-1252948206=:85689
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">I'll be there - I hope to see lot's more turning up over the h=
unt too.<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font s=
tyle=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><spa=
n style=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span s=
tyle=3D"font-style: italic;"><font style=3D"font-family: times new roman,ne=
w york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=
=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a re=
l=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com">=
http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_blan=
k" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Repr=
esentative</a><br></font></span></span><div><br></div><div style=3D"font-fa=
mily: times new roman,new
 york,times,serif; font-size: 12pt;"><br><div style=3D"font-family: tahoma,=
new york,times,serif; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"><hr=
 size=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Matthew =
Weier O'Phinney &lt;[email-masked]&gt;<br><b><span style=3D"font-weight: =
bold;">To:</span></b> [email-masked]<br><b><span style=3D"f=
ont-weight: bold;">Sent:</span></b> Monday, September 14, 2009 5:55:25 PM<b=
r><b><span style=3D"font-weight: bold;">Subject:</span></b> [zf-contributor=
s] Announcement: Monthly Bug Hunt!<br></font><br>=0AGreetings, one and all!=
<br><br>I've alluded several times in the past month to having a plan for<b=
r>helping manage our ever-growing bug list in the issue tracker. We're now<=
br>ready to roll out phase one of this plan, and we need *you*!<br><br>Star=
ting this month, we will be sponsoring two bug hunt days monthly, on<br>the=
 third Thursday and Friday of the month. That's this upcoming<br>Thursday a=
nd Friday, 17-18 September 2009.<br><br>During those days, the Zend team --=
 myself, Ralph, and Alex -- will be<br>in #zftalk.dev on Freenode for our e=
ntire work day (Ralph and myself are<br>in the United States, Alex is based=
 in Russia; figure out the timezones<br>yourself (-: ). We will be triaging=
 bugs ourselves, but, more<br>importantly, we will be there to help facilit=
ate *you*, our contributors<br>and users, in resolving issue reports. <br><=
br>As an incentive, each month, we will ship a Zend Framework t-shirt to<br=
>the individual that assists in the most
 issue resolutions during the bug<br>hunt days, whether via patches or dire=
ct commits. Quarterly, we will<br>evaluate overall contributions, including=
 documentation, bug fixes, and<br>newly contributed components, and award a=
 developer with their choice of<br>a Zend Studio license or Zend Framework =
Certification voucher. (Caveat:<br>one t-shirt per person per year, and one=
 license/voucher per person per<br>year, folks!) <br><br>For those interest=
ed in participating in the bug hunt days, the rules<br>are simple: have a s=
igned CLA on file, and resolve issues in the<br>tracker. <br><br>If you hav=
e not yet signed a CLA and want to participate, you can get a<br>copy of th=
e form here:<br><br><span>&nbsp; &nbsp; <a target=3D"_blank" href=3D"http:/=
/framework.zend.com/cla">http://framework.zend.com/cla</a></span><br><br>Si=
gn it and return it (you can email it, fax it, or send it via post);<br>if =
you send it via post, you'll need to wait for confirmation that<br>we've
 received it before we can accept code contributions from you.<br><br>Now, =
when it comes to the issue tracker, you'll need to determine if the<br>issu=
e:<br><br> * is simply the reporter misunderstanding or misusing code OR<br=
> * is a request for a new feature OR<br> * is a reproducible issue<br><br>=
In the first case, comment on it and indicate the correct usage, and ask<br=
>the component maintainer or somebody from Zend to review your response<br>=
and mark the issue as resolved. In the second case, please try and focus<br=
>on issue reports instead of feature requests during the bug hunt days.<br>=
<br>That brings us to the final case, reproducible issue reports. With<br>t=
hese, you'll need to do the following:<br><br> * Capture the reproduce case=
 as a unit test<br> * Resolve the issue in such a way as to maintain backwa=
rds<br>&nbsp;  compatibility with existing usage. (In other words, don't ch=
ange the<br>&nbsp;  signature of a method unless the signature is
 what is actually<br>&nbsp;  broken.)<br><br>From there, you then have two =
options:<br><br> * If you already have commit access, commit the test and f=
ix to the<br>&nbsp;  repository, and either resolve the issue or ask somebo=
dy from Zend to<br>&nbsp;  review and resolve.&nbsp; Don't forget to merge =
your changes to the 1.9<br>&nbsp;  release branch!<br><br> * If you do not =
have commit rights, create a patch with the unit test<br>&nbsp;  and fix, a=
nd attach the patch to the issue. Ask the maintainer or<br>&nbsp;  somebody=
 from Zend to review and apply the patch.<br><br>If you need help creating =
the unit test or patch file, hop onto the<br>#zftalk.dev IRC channel and as=
k for help.<br><br>How should you choose issues to work on? Answer the foll=
owing questions,<br>and you should be able to hop right in:<br><br> * What =
components do you have expertise in?<br> * What components are you interest=
ed in learning more about?<br> * What issues have a high number of
 voters or watchers?<br><br>Bug hunting should be fun, so pick components a=
nd issues you're<br>interested in. Ask questions on IRC if you don't unders=
tand how<br>something works.<br><br>So, spread the word, and come prepared =
this week to help make the<br>framework even better! I look forward to seei=
ng you on IRC this week!<br><br>-- <br>Matthew Weier O'Phinney<br>Project L=
ead&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a ymailto=3D"mailto:matthew=
@zend.com" href=3D"mailto:[email-masked]">[email-masked]</a><br><span>Z=
end Framework&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a target=3D"_blank" href=
=3D"http://framework.zend.com/">http://framework.zend.com/</a></span><br></=
div></div></div></body></html>
--0-782210412-1252948206=:85689--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 19 Jul 2009 09:48:45 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Test suite audit

Hey, all --

I've been auditing the test suite for the last few days, and just did a
huge commit that fixes a number of problems encountered when running the
full test suite (r16852).

The biggest change is that I have turned off output buffering by
default. In most cases, ob can be applied per test case or per test
suite. By turning it off, we get (a) reduced memory usage, (b) a faster
test suite, (b) real-time reporting of test status, and (c) the ability
to actually see what errors caused the suite to fail in the case of
fatal errors.

There are a few test suites that fail with this, however: Zend_Session
and Zend_Soap. In both cases, the internal PHP functions they each
delegate to attempt to send headers, and will raise warnings if unable
to do so. I've added a constant to the TestConfiguration.php.dist file
that allows you to selectively enable output buffering, but I'm also
looking into a way to solve the testing issues without resorting to
that.

Finally, I've discovered a number of test failures that exist when
running with or without the full test suite, and a number of failures
and errors that occur only when running the full test suite. I fixed
many of these during the audit, but some I have not been able to figure
out. I may be contacting some of you to help if your components are
affected.

Running the entire test suite takes between 5 and 6 minutes currently
when you run using defaults. As such, I ask that any time you write new
tests, please run the entire test suite prior to committing to verify
that the tests run when the full suite is executed. Most of the issues I
corrected were due to invalid assumptions made during setUp() of test
suites -- for instance, assuming the timezone or locale values match
your own, or that Zend_Registry is clean. Running the full test suite
will often help you identify such issues.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 08 Oct 2009 19:10:17 +0200
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] mailing list for contributors doesn't work on
	framework.zend.com

Hi,

The mailing list for contributors doesn't work:
http://framework.zend.com/archives/contributors

ERR:  An error occurred with this request: Action "contributors" does
not exist and was not trapped in __call().

The link is shown here:
http://framework.zend.com/wiki/display/ZFDEV/Contributing+to+Zend+Framework#ContributingtoZendFramework-mailinglists

All other mailing lists are working

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 20 Jan 2010 09:26:45 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Re: requirements (documentation) of Zend_Serializer

-- Marc Bennewitz <[email-masked]> wrote
(on Tuesday, 19 January 2010, 11:39 PM +0100):
> I added the requirements of Zend_Serializer to trunk but these files are
> completely different to that in 1.10 branch.
> Is there some work on it ?

Merge the changes to the 1.10 branch, please.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Tue, 23 Jun 2009 04:24:27 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.8.4 sanity check packages.

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9F3F5.49F21337
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all!

=20

The sanity check packages for ZF 1.8.4 are now available here:

http://framework.zend.com/releases/preview/ZendFramework-1.8.4.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-apidoc.ta
r.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-apidoc.zi
p

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-de
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-de
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-en
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-en
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-fr
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-fr
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-ja
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-ja
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-ru
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-ru
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-zh
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.4-manual-zh
.zip

=20

Note that this is *NOT* the official release of 1.8.4. If we find no
major issues with these builds, we will issue official 1.8.4 release
from this tag soon.=20

Please do *NOT* log any issues found in these archives in the issue
tracker; instead post any major functional or packaging issues to this
list or mail them to me directly ([email-masked]).

=20

=20

With best regards,

   Alexander Veremyev.

------_=_NextPart_001_01C9F3F5.49F21337
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@SimSun";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:2.0cm 69.6pt 2.0cm 69.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Hi all!</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>The sanity check packages for ZF 1.8.4 are =
now
available here:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4.ta=
r.gz">http://framework.zend.com/releases/preview/ZendFramework-1.8.4.tar.=
gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4.zi=
p">http://framework.zend.com/releases/preview/ZendFramework-1.8.4.zip</a>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ap=
idoc.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.4-apidoc.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ap=
idoc.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8.4-=
apidoc.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-de.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.4-manual-de.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-de.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.4-manual-de.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-en.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.4-manual-en.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-en.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.4-manual-en.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-fr.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.4-manual-fr.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-fr.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.4-manual-fr.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-ja.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.4-manual-ja.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-ja.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.4-manual-ja.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-ru.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.4-manual-ru.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-ru.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.4-manual-ru.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-zh.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.4-manual-zh.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.4-ma=
nual-zh.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.4-manual-zh.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Note that this is *NOT* the official release =
of 1.8.4.
If we find no major issues with these builds, we will issue official =
1.8.4
release from this tag soon. </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Please do *NOT* log any issues found in these =
archives
in the issue tracker; instead post any major functional or packaging =
issues to
this list or mail them to me directly =
([email-masked]).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>With best regards,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Alexander =
Veremyev.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9F3F5.49F21337--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Nico Edtinger <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Date: Wed, 23 Sep 2009 12:50:44 +0200
Cc: <[email-masked]>
Subject: Re: [zf-contributors] Discussion about Quality/Review Process -
	Community RM proposal

Benjamin Eberlei wrote:
> regarding the Backwards-Compabilitiy or not change problem with the  
> 1.9.3
> release we had a fairly extensive discussion on IRC yesterday that I
> would like to share with everyone who was not able to participate.
>
> To explain the issue, the 1.9.3 release had a BC break by changing
> how the Zend_Db::factory works. A Use-Case that was never described
> in documentation but was valid according to the methods docblock
> was changed.
>
> Now we had such problems in previous releases also and they are bound
> to happen again, however the question was how we could extend the  
> quality
> process to minimize the effect of such problems and detect them as  
> soon
> as possible.

If there is a use-case no one thinks of you won't find it in a unit  
test and a reviewer won't spot it either. Any contributor is too much  
involved to think outside the box. As long as "outsiders" wait for the  
final release and are not interested in testing RCs problems like  
yesterday will happen again.

Enough pessimism ;) Having more than one RM might still be a good idea  
for several reasons and there are a couple of trustworthy contributors.

nico

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 26 Jul 2009 11:31:15 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services
	to ZendX Proposal

-- Benjamin Eberlei <[email-masked]> wrote
(on Sunday, 26 July 2009, 11:35 AM +0200):
> i took the time today to look at the Problem of Zend_Service_Amazon. Due to an 
> API upgrade the ZF component won't work anymore come August 15th. I just saw 
> that the component uses the API from 2005, so its hopelessly out of date. I'll 
> look into a possible fix, but i can't guarantee for this to work with the 2005 
> API and i dont know how complex a migration to the latest 2009 API is.

Thanks for looking into this. I've seen the notices, but have had
neither the time nor the knowledge to attempt a fix.

> This out of date problem is the case with most of the other Service components 
> besides Twitter, S3 and EC2. Their code-base is mostly crap and they are all 
> unmaintained.
> 
> I want to propose a change to ZFs handling of Service components. Since they 
> all rely on third party API (through them having to rely on the stability of 
> external webservices) they should all be moved into ZendX for 2.0. Also every 
> new service component from now on should only be included in ZendX, with the 
> exception of service integration being programmed from companies that have an 
> agreement with Zend, such as the Infocard, Google and AMF components, where 
> the stability and up-to-date API can be somewhat guaranteed.

This idea has a good deal of merit, and I'll discuss it with Zeev.
Services are one of those areas where ZF differentiates itself from
other libraries and frameworks -- but also can be an achilles heel as
the various service APIs evolve.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: David Caunt <[email-masked]>
Date: Tue, 16 Mar 2010 11:22:02 +0000
To: Giorgio Sironi <[email-masked]>
Cc: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

--0015173fe8621dfa040481e936f4
Content-Type: text/plain; charset=UTF-8

I agree, the explicit names are well worth the extra typing

On 16 March 2010 10:20, Giorgio Sironi <[email-masked]>wrote:

> On Tue, Mar 16, 2010 at 8:53 AM, Andy Thompson <[email-masked]> wrote:
> > Suffixing the class name with its intent seems like the best way in my
> > opinion. In my own libraries, I've been frustrated with the way I might
> have
> > 3 or 4 of the same filenames open e.g. Field\DateTime.php,
> > Filter\DateTime.php, Validate\DateTime.php and Element\DateTime.php
> (though
> > that last one I've now renamed to DateTimeSelect).
>
> A single-word suffix really adds significance to the name. In Doctrine
> 2, which has a namespaced codebase, Roman told me the policy is the
> basename of a class should always have a meaning by itself (i.e.
> Doctrine\ORM\Persisters\SingleTablePersister;
> Doctrine\ORM\Mapping\OneToOneMapping).
> At least if it's not an internal class of a component, this is a
> useful convention; no one cares about Doctrine\ORM\Query\TreeWalker
> not being QueryTreeWalker because it's not meant to be referred out of
> Doctrine\ORM\Query.
>
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>

-- 
Save Water...Drink Ouzo !

--0015173fe8621dfa040481e936f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree, the explicit names are well worth the extra typing<div><br><br><di=
v class=3D"gmail_quote">On 16 March 2010 10:20, Giorgio Sironi <span dir=3D=
"ltr">&lt;<a href=3D"mailto:[email-masked]">piccoloprinci=
[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Tue, Mar 16, 2010 at 8=
:53 AM, Andy Thompson &lt;<a href=3D"mailto:[email-masked]">andy@webtati=
c.com</a>&gt; wrote:<br>

&gt; Suffixing the class name with its intent seems like the best way in my=
<br>
&gt; opinion. In my own libraries, I&#39;ve been frustrated with the way I =
might have<br>
&gt; 3 or 4 of the same filenames open e.g. Field\DateTime.php,<br>
&gt; Filter\DateTime.php, Validate\DateTime.php and Element\DateTime.php (t=
hough<br>
&gt; that last one I&#39;ve now renamed to DateTimeSelect).<br>
<br>
</div>A single-word suffix really adds significance to the name. In Doctrin=
e<br>
2, which has a namespaced codebase, Roman told me the policy is the<br>
basename of a class should always have a meaning by itself (i.e.<br>
Doctrine\ORM\Persisters\SingleTablePersister;<br>
Doctrine\ORM\Mapping\OneToOneMapping).<br>
At least if it&#39;s not an internal class of a component, this is a<br>
useful convention; no one cares about Doctrine\ORM\Query\TreeWalker<br>
not being QueryTreeWalker because it&#39;s not meant to be referred out of<=
br>
Doctrine\ORM\Query.<br>
<div><div></div><div class=3D"h5"><br>
--<br>
Giorgio Sironi<br>
Piccolo Principe &amp; Web Engineer<br>
<a href=3D"http://giorgiosironi.blogspot.com" target=3D"_blank">http://gior=
giosironi.blogspot.com</a><br>
<a href=3D"http://twitter.com/giorgiosironi" target=3D"_blank">http://twitt=
er.com/giorgiosironi</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water.=
..Drink Ouzo !<br>
</div>

--0015173fe8621dfa040481e936f4--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 11:55:49 -0300
From: Guilherme Blanco <[email-masked]>
To: Giorgio Sironi <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

Hi all,

IMHO execute() reflects more directly to Command pattern. =3D)

Cheers,

On Mon, Mar 22, 2010 at 7:15 AM, Giorgio Sironi
<[email-masked]> wrote:
> On Mon, Mar 22, 2010 at 3:44 AM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
>> I'm trying to decide if "direct" (which suggests strategy) or
>> "execute" makes more sense for the method name.
>
> Imho direct() has continuity and consistency. I do not know if putting
> such a method in an interface will force the user to use
> func_get_args(), but I see no other choice.
>
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>

--=20
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [email-masked]
URL: http://blog.bisna.com
S=C3=A3o Paulo - SP/Brazil

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 22 Jan 2010 15:59:32 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Marc Bennewitz <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend_Date & build-in class DateTime

--0-1591286221-1264204772=:82588
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Personally I don't see DateTime as massively important to Zend_Date. It wou=
ld be nice to have, but the class itself is pretty basic that I'm not sure =
what exactly it would add to Zend_Date other than offer a (measured?) perfo=
rmance boost and some import/export functionality for interoperability (wou=
ld have been nicer to have a DateTime interface).=0A=0A P=E1draic Brady=0A=
=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID=
 Europe Foundation Irish Representative=0A=0A=0A=0A=0A=0A__________________=
______________=0AFrom: Marc Bennewitz <[email-masked]>=0ATo: zf-co=
[email-masked]=0ASent: Fri, January 22, 2010 10:16:02 PM=0ASubje=
ct: [zf-contributors] Zend_Date & build-in class DateTime=0A=0A Hi all,=0A=
=0ADoes is matter that Zend_Date doesn't extends the build-in DateTime=0Acl=
ass ?=0A-> The DateTime class is available since PHP =0A5.2.0 and ZF requir=
e PHP 5.2.4.=0A=0AIt would be very nice because than Zend_Date would be com=
patible to=0Aother php libraries using DateTime and within ZF tests like th=
e=0Afollowing can simplify:=0A=0Aif ($date instanceof Zend_Date_DateObject)=
 {=0A    $timestamp =3D $date->getUnixTimestamp();=0A} elseif ($date instan=
ceof DateTime) {=0A    $timestamp =3D $date->getTimestamp();=0A} else {=0A =
   $timestamp =3D (float)$date;=0A}=0A=0AGreetings,=0AMarc=0A
--0-1591286221-1264204772=:82588
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Personally I don't see DateTime as massively important to Zend=
_Date. It would be nice to have, but the class itself is pretty basic that =
I'm not sure what exactly it would add to Zend_Date other than offer a (mea=
sured?) performance boost and some import/export functionality for interope=
rability (would have been nicer to have a DateTime interface).<br><div>&nbs=
p;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: =
times new roman,new york,times,serif;" size=3D"3"><span style=3D"font-weigh=
t: bold;">P=E1draic Brady<br><br></span></font><span style=3D"font-style: i=
talic;"><font style=3D"font-family: times new roman,new york,times,serif;" =
size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"http://blog.astrum=
futura.com">http://blog.astrumfutura.com</a><br><a rel=3D"nofollow" target=
=3D"_blank"
 href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com=
</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideuro=
pe.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span>=
</span><div><br></div><div style=3D"font-family: times new roman,new york,t=
imes,serif; font-size: 12pt;"><br><div style=3D"font-family: times new roma=
n,new york,times,serif; font-size: 12pt;"><font face=3D"Tahoma" size=3D"2">=
<hr size=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Marc =
Bennewitz &lt;[email-masked]&gt;<br><b><span style=3D"font-weight:=
 bold;">To:</span></b> [email-masked]<br><b><span style=3D"=
font-weight: bold;">Sent:</span></b> Fri, January 22, 2010 10:16:02 PM<br><=
b><span style=3D"font-weight: bold;">Subject:</span></b> [zf-contributors] =
Zend_Date &amp; build-in class DateTime<br></font><br>=0A<meta http-equiv=
=3D"x-dns-prefetch-control" content=3D"off">=0A=0A=0A=0A =0A=0AHi all,<br>=
=0A<br>=0ADoes is matter that Zend_Date doesn't extends the build-in DateTi=
me=0Aclass ?<br>=0A-&gt; The DateTime class is available since PHP =0A5.2.0=
 and ZF require PHP 5.2.4.<br>=0A<br>=0AIt would be very nice because than =
Zend_Date would be compatible to=0Aother php libraries using DateTime and w=
ithin ZF tests like the=0Afollowing can simplify:<br>=0A<br>=0Aif ($date in=
stanceof Zend_Date_DateObject) {<br>=0A&nbsp;&nbsp;&nbsp; $timestamp =3D $d=
ate-&gt;getUnixTimestamp();<br>=0A} elseif ($date instanceof DateTime) {<br=
>=0A&nbsp;&nbsp;&nbsp; $timestamp =3D $date-&gt;getTimestamp();<br>=0A} els=
e {<br>=0A&nbsp;&nbsp;&nbsp; $timestamp =3D (float)$date;<br>=0A}<br>=0A<br=
>=0AGreetings,<br>=0AMarc<br>=0A<meta http-equiv=3D"x-dns-prefetch-control"=
 content=3D"on"></div></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compressed/=
chunked Sun Jan 17 05:08:35 PST 2010 -->=0A</div></body></html>
--0-1591286221-1264204772=:82588--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 18:00:58 +0200
From: Tobias Gies <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Discussion about Quality/Review Process - 
	Community RM proposal

--001485f723a41aedfd047440d26c
Content-Type: text/plain; charset=ISO-8859-1

Hey Matthew,

> We will not be using the wiki for the official documentation, period.

*jumps from the chair to salute* Sir, yes, sir!

> New documentation or community-contributed docs are in a
> wiki, but migrated to docbook once they mature. The reasons for doing so
> are very similar to those I've outlined above.

Now *that* sounds like a concept worth looking into. I'm imagining a process
like this right now:

- Contributors team up to write docs about a new component.
- Contributors create a wiki article for the component.
- When the article is finished, it is converted to docbook. From now on, all
changes to the article are made in the docbook sources.
- If, at some point in time, the article needs a severe overhaul (no changes
that can in any way be described as minor, mind you), contributors can
"fork" it back into a wiki article and re-start from step two.

Like it?

> Additionally, one part of the documentation effort is to
> provide the ability to add comments within the manual. Once this
> functionality is added, we can periodically review comments to see where
> changes need to be made in the manual.

Oooh, sounds fancy, too. Kinda like the way it is possible to comment on the
Survive the Deep End website?

--001485f723a41aedfd047440d26c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Matthew,<br><br>
&gt; We will not be using the wiki for the official documentation, period.<=
br><br>*jumps from the chair to salute* Sir, yes, sir!<br><br>&gt; New docu=
mentation or community-contributed docs are in a<br>
&gt; wiki, but migrated to docbook once they mature. The reasons for doing =
so<br>&gt; are very similar to those I&#39;ve outlined above.<br><br>Now *t=
hat* sounds like a concept worth looking into. I&#39;m imagining a process =
like this right now:<br>
<br>- Contributors team up to write docs about a new component.<br>- Contri=
butors create a wiki article for the component.<br>- When the article is fi=
nished, it is converted to docbook. From now on, all changes to the article=
 are made in the docbook sources.<br>
- If, at some point in time, the article needs a severe overhaul (no change=
s that can in any way be described as minor, mind you), contributors can &q=
uot;fork&quot; it back into a wiki article and re-start from step two.<br>
<br>Like it?<br><br>&gt; Additionally, one part of the documentation effort=
 is to<br>
&gt; provide the ability to add comments within the manual. Once this<br>
&gt; functionality is added, we can periodically review comments to see whe=
re<br>
&gt; changes need to be made in the manual.<br><br>Oooh, sounds fancy, too.=
 Kinda like the way it is possible to comment on the Survive the Deep End w=
ebsite?<br>

--001485f723a41aedfd047440d26c--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 24 Mar 2009 14:42:24 -0600
From: "A.J. Brown" <[email-masked]>
To: Wil Sinclair <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Proper place to report incubator 
	issues/requests?

--00221532c7589f4e590465e36b33
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hey Wil,

That's actually exactly what I was hoping for :)

Cheers!

On Tue, Mar 24, 2009 at 2:37 PM, Wil Sinclair <[email-masked]> wrote:

>  Hey AJ, I=92ve been meaning to answer this one for days, so I=92m the ca=
use
> of the unresponsiveness here. ;) With a recent release of JIRA, it became
> easy to migrate issues between projects. I propose we create a separate
> project for incubator that uses the same issue scheme as the ZF project w=
ith
> components that are currently in incubator. We would then make migrating
> these issues part of promoting the component to trunk.
>
> If there are no issues or better suggestions, I=92ll implement this propo=
sal
> tomorrow.
>
>
>
> ,Wil
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *A.J.
> Brown
> *Sent:* Wednesday, March 18, 2009 11:05 PM
> *To:* [email-masked]
> *Subject:* [zf-contributors] Proper place to report incubator
> issues/requests?
>
>
>
> Hey guys,
>
> I have some requests I want to file for a component currently in the
> standard incubator (specifically Zend_Queue).  Where's the place to do so=
?
> --
> A.J. Brown
> web | http://ajbrown.org
> phone | (937) 660-3969

--=20
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

--00221532c7589f4e590465e36b33
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hey Wil,<br><br>That&#39;s actually exactly what I was hoping for :)<br><br=
>Cheers!<br><br><br><div class=3D"gmail_quote">On Tue, Mar 24, 2009 at 2:37=
 PM, Wil Sinclair <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">wil=
@zend.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US">

<div>

<p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">Hey AJ, I=92ve=
 been meaning to answer this one for days, so I=92m
the cause of the unresponsiveness here. ;) With a recent release of JIRA, i=
t
became easy to migrate issues between projects. I propose we create a separ=
ate project
for incubator that uses the same issue scheme as the ZF project with compon=
ents
that are currently in incubator. We would then make migrating these issues =
part
of promoting the component to trunk.</span></p>

<p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">If there are n=
o issues or better suggestions, I=92ll implement
this proposal tomorrow.</span></p>

<p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">=A0</span></p>

<p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">,Wil</span></p=

<p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">=A0</span></p>

<p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">=A0</span></p>

<div style=3D"border-style: solid none none; border-color: rgb(181, 196, 22=
3) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium=
; padding: 3pt 0in 0in;">

<p><b><span style=3D"font-size: 10pt;">From:</span></b><span style=3D"font-=
size: 10pt;"> <a href=3D"mailto:[email-masked]" target=3D"_blank">fynwin=
[email-masked]</a>
[mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">fynwine@gmai=
l.com</a>] <b>On Behalf Of </b>A.J. Brown<br>
<b>Sent:</b> Wednesday, March 18, 2009 11:05 PM<br>
<b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_bla=
nk">[email-masked]</a><br>
<b>Subject:</b> [zf-contributors] Proper place to report incubator
issues/requests?</span></p>

</div><div><div></div><div class=3D"h5">

<p>=A0</p>

<p>Hey guys,<br>
<br>
I have some requests I want to file for a component currently in the standa=
rd
incubator (specifically Zend_Queue).=A0 Where&#39;s the place to do so?<br =
clear=3D"all">
<br>
-- <br>
A.J. Brown<br>
web | <a href=3D"http://ajbrown.org" target=3D"_blank">http://ajbrown.org</=
a><br>
phone | (937) 660-3969</p>

</div></div></div>

</div>

</blockquote></div><br><br clear=3D"all"><br>-- <br>A.J. Brown<br>web | <a =
href=3D"http://ajbrown.org">http://ajbrown.org</a><br>phone | (937) 660-396=
9<br>

--00221532c7589f4e590465e36b33--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Sun, 21 Mar 2010 14:42:59 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: [zf-contributors] Zend View Helpers in 2.0: Command
	=?UTF-8?Q?Pattern=3F?=

Hello everyone,

I just wanted to point out an obstacle with the current View Helper
implementation for Zend_View 2.0
I realized when hacking into Zend View and PluginHelper to get it running
with namespaces.

namespace Whitewashing\Blog\View;
use Whitewashing\Blog\PostService;

class PostsCloud extends \Zend_View_Helper_Abstract
{
    private $postService;

    public function setPost(PostService $postService)
    {
        $this->postService =3D $postService;
    }

    public function postsCloud()
    {

    }
}

The current approach with the method name like the helper name does not
work with namespaces,
as in PHP the helper method is considered a constructor of the helper and
would be executed
upon instantiation.

Since the helper method is a command pattern i would suggest renaming the
method "execute"
or something alike.

greetings,
Benjamin

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 05 Jun 2009 18:58:59 -0700
From: Jason Webster <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] [ZF-870] Tracking open transactions in
	Zend_Db_Adapter_Abstract

Hey all,

I'd like to get input on the basic issue raised in ZF-870 
<http://framework.zend.com/issues/browse/ZF-870>

The basic run down is that it'd be great to have a way of seeing if there is currently a transaction 
open, or if the RDBMS supports it, multiple transactions open.

Jan Pieper posted one use case for nested transactions on the ticket, but here's an even simpler one 
(this assumes that the DB in question is MySQL, which does not support concurrent transactions):

You've got a resource that has a few one-to-many and many-to-many relationships. Let's call it an 
Article, for now. It's model/datamapper/whichever has a destroy() method, which deletes it's 
database rows, but also calls some methods on other models, which handle the relationships. These 
methods on the other models could be used in different contexts, or even on their own, so it's 
feasible that they would also like to run in a transaction. Imagine something like this:

public function destroy($id) {
	if(!$article = $this->find($id))
		throw new Exception('Trying to delete a article that does not exist? Really?');

	 $attachments = $article->getAttachments();	
	 $this->_db->beginTransaction();
  		
	 try {
		App::getModel('Attachments')->destroy($attachments);
	 	
		$this->_db->delete('table', $this->_db->quoteInto('ID = ?', $article->ID, 'INTEGER'));
		$this->_db->delete('other_table', $this->_db->quoteInto('article_id = ?', $article->ID, 'INTEGER'));
		
		App::getModel('Tags')->destroyRelationships($article);
			
	 	$this->_db->commit();
		$this->_cacheFlushOne($article->ID);
	} catch (Exception $e) {
		$this->_db->rollBack();
		throw $e;
	}
}

Now, that's fine... but some of those methods that are called may want to run transactions of their 
own, because they can be used independently of this method.
So, if, for example, the Tags model destroyRelationships() method metioned above wanted to have a 
transaction, it currently could not. Well, at least not without wrapping $db->beginTransaction() in 
a try/catch; which is less than desirable.

There's been a patch on this ticket for about 2 years now that offers a solution to this problem. 
Just a simple counter on Zend_Db_Adapter_Abstract, that gets incremented when a transaction starts, 
and decremented when one ends. It also adds one simple getter method to access this counter.
This would facilitate methods to detect whether a transaction was currently running or not, and 
either start one or not.

Anyone else think this is necessary/useful?

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 21:01:08 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

-- Robin Skoglund <[email-masked]> wrote
(on Friday, 10 April 2009, 09:42 PM +0200):
> On Fri, Apr 10, 2009 at 20:24, Matthew Weier O'Phinney <[email-masked]>
> wrote:
> I also notice that namespaces are written in Uppercase\Notation -- Zend\
> Controller\Request. Will this be the standard? Another alternative is zend\
> controller\Request, which clearly distinguishes what's the namespace and what's
> the class/interface.

Well, it's actually pretty clear already -- the class name is whatever
follows the last \.

The other potential problem I see with this approach is that many of our
components have MixedCase segments -- going to all lowercase would be
harder to read.

But this is a discussion for another day -- I want to focus on the
naming conventions of Interfaces and Abstract classes for now, as that's
the more immediate concern.

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Date: Wed, 23 Sep 2009 16:40:43 +0200
Subject: Re: [zf-contributors] Discussion about Quality/Review Process - 
	Community RM proposal
From: till <[email-masked]>
To: Carlton Gibson <[email-masked]>
Cc: "Matthew Weier O'Phinney" <[email-masked]>,
	[email-masked]

On Wed, Sep 23, 2009 at 4:40 PM, till <[email-masked]> wrote:
> (...)
> Two cents on documentation and user interfaction.

That was supposed to be "interaction".

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Wed, 11 Nov 2009 20:06:10 +0100
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

looks great!

how will we conceptionally move from php 5.x to 5.3? might it be a good idea 
to implement a rough tokenizer => transformer to apply for example the 
following rules:

1. collect all classes and interfaces using Reflection and Zend_Reflection_File.

Package_Subpackage_Class => Package\Subpackage\Class

if(Class == Abstract)
Class = SubpackageAbstract

if(Class == Interface)
Class = Subpackage

if(Class == Exception)
class = ExceptionImpl implements Exception
+ Interface Exception

2. Define all exceptions to this rule in a simple array map (important for most 
of the interfaces).

3. iterate over the code with a tokenizer on a file basis, find all INTERFACE 
and CLASS tokens and when re-applying them to the file change with the new 
code.

Imho this would be better than to ask all the maintainers to make the 
migration, since that will probably take several months and make it incredible 
hard to work with the trunk.

greetings,
Benjamin

On Wednesday 11 November 2009 07:38:57 pm Matthew Weier O'Phinney wrote:
> Hey, all --
>
> There have been a ton of questions about the ZF 2.0 roadmap, and my
> answer has been consistently, "I'm working on it; I'll have something to
> publish soon."
>
> "Soon" is now:
>
>    
> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>
> I'd like you, as contributors, to look over it, and start discussing the
> various ramifications; we can do that either in comments to the pages or
> on this list.
>
> The roadmap is primarily a conceptual one right now, though a
> proof-of-concept has been created for the proposed MVC. I'd like to stay
> fairly high-level for now, and then start getting a flow of proposals
> into the system for specific migration-related tasks.
>
> Thanks everyone who has provided me input over the past many months, and
> let's get started on the next generation of ZF!

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 31 Aug 2009 14:43:49 -0300
From: Guilherme Blanco <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in 
	Zend_Entity

Took me some time to reply, but here it is...

On Fri, Aug 28, 2009 at 12:24 PM, Matthew Weier
O'Phinney<[email-masked]> wrote:
> -- Guilherme Blanco <[email-masked]> wrote
> (on Friday, 28 August 2009, 11:40 AM -0300):
>> other types.
>> There're main places that requires changes. One example is the DQL to
>> SQL generation... Against DDBMS, it can't be used SQL, so we'll have
>> to move the SqlWalker extended from TreeWalker (which navigates
>> through the AST generated by LL(k) parser) to be Platform dependant.
>> This means that if we want to choose Tamino (Document-oriented XML DB)
>> for example, we'll have to generate the XQL (a kind of XPath) to query
>> the DB.
>
> This is the job of a query/criteria builder, though -- to provide an OO
> interface for dynamically building the query parts, and then generating
> the appropriate markup. I see no conflict here (though I'm not sure if
> you were implying there was one).

No, I'm not pointing to conflicts here.
I'm pointing that *IF* you want to support a kind of ZQL... that's the
solution we have planned to workaround this issue.

>
>> Also, if you want to restrict the structure of a DDBMS to always fit
>> your Zend_Entity, this means you're loosing the most powerful thing it
>> supports (schema-less definitions).
>
> Not necessarily.
>
> The way I look at it, each document presents its own schema within its
> structure (the key/value pairs it contains). Zend_Entity (or another ORM
> solution) would simply have some knowledge about how to represent
> specific keys in a document. For example, in CouchDB, you might have
> tags embedded in the document:
>
> =C2=A0 =C2=A0tags: ["foo", "bar", "baz"]
>
> The ORM would then map the individual items in "tags" to a Tag entity,
> creating them based on the string value provided. On the flip side, when
> persisting back to CouchDB, it would know to create an array of values
> based on the Tag entities aggregated.

Again... the most powerful thing in DDBMS is the ability to have
schemaless models.
Enforcing a schema (like we do in Doctrine and like we have in
Zend_Entity) drops this feature.
I'm a fan of DDBMSs, IMHO they should be schema based, but
seriously... end user needs to decide it, not the tool he's using.

>
>> Another point to highlight: DDBMS do not support relations natively.
>> Except MongoDB, which is the only DDBMS that supports it, you'll have
>> to rely on a lazy load of relations all the time to load related data.
>> This changes quite a lot the structure of your Collection and Entity.
>> We get prepared to afford this type of need, but you may need to think
>> correctly based on your structure.
>>
>> Doctrine team is even considering to go into the direction of
>> EclipseLink, which supports it by supporting similar projects. That's
>> one of the reasons we organized our repository in Common, DBAL and
>> ORM. If we can't afford the changes needed to support DDBMS, we may
>> need to create a ODM repository.
>> Trust me, you like challenges like we all loves. But build a unique
>> solution to support RDBMS, DDBMS, OODBMS are not easy.
>>
>>
>>
>> Matthew,
>>
>> We'll release Doctrine 2.0 in September 1st. =3D)
>> It'll be a preview alpha.
>
> I know. :)
>
> What's the schedule for final, though?

We'll start with first alpha tomorrow...
Continuing with implementation against what's still missing and also
implementing new features, we plan to reach a final 2.0.0 in Q1 2010.

>
>> We want people to start testing our new codebase and provide us some
>> feedback. We still have lots of development to do, I just finished the
>> base of CLI tasks, while Jonathan finished the Optimistic Locking
>> strategy. =C2=A0On schedule we have many other interesting things to com=
e.
>> Recently I've been speaking a lot with Steve Ebersole from Hibernate.
>> We're planning to support HiLo Id Generator soon.
>>
>> Most of the concepts we're bringing to Doctrine are quite new to PHP
>> world, mainly to lack of some tools of language until now. PHP 5.3
>> opened a new world of possibilities and we're just taking advantage of
>> it.
>
> Understood -- I wasn't intending my language as bashing previously --
> it was simply to illustrate that your adoption of 5.3 will predate ours,
> which makes integration opportunities a little more tricky.

Let's hope people start to move their servers soon!
Fedora, Red hat, SuSE are already packing 5.3 releases... Q1-Q2 2010
is our expected date of an average adoption.
We'll still support 1.X series until 2011. Just checkout our planned
roadmap: http://www.doctrine-project.org/blog/doctrine-future-roadmap

>
>> Native support to Metadata mapping through Annotations is a rather
>> unique thing in PHP, only seen similar in Unit Test tools.
>
> Actually, ZF's various Server classes utilize annotations to build up
> method maps and prototypes. :) We're using stock annotations (short/long
> descriptions, param, and return), but it's been part of the offerring
> since 0.1.0. Zend_Server_Reflection and the newer Zend_Reflection offer
> a lot of support for introspecting annotations.

I know and I follow ZF evolution since the first day.
But you probably know we have a rather poor support to Reflection in PHP.
Once we reach a good stage and we find some free time, I'll work on
patches to Reflection. Maybe soon we have some optimizations on it. =3DD

>
> It's a powerful paradigm -- though a little expensive in terms of
> computation.

Most of what we have today in Java world is thanks to their Reflection API.
We can reach a better stage of what we currently have in PHP
Reflection. It's just a matter of time and knowledge of contributors.
=3D)

I really like the approach we're having here. It's good to talk about
points of implementation, specs, etc.
It makes the user land easier to switch from one to the other.

We attempted to do a similar approach in 2006/2007... but none of the
authors of specific tools were interested (read as: Hans - Propel and
Konsta - Doctrine).
I was working at that time in a Persistence Layer of IBM written by
Scott Ambler.
Of course it was just an ego-talk and the list died quickly...
although I saw some of the ideas I gave that time implemented in
Propel and also in Doctrine.
In 2007 I joined the Doctrine team because I didn't find enough time
to finish my implementation alone... so I had to take a decision. I
think I did it well. =3D)

Anyway... we're in a stage of a dream like we're in 2006. Let's just
continue with it and see what's the acceptance of public.

>
>> Let's see how people accept these new ideas, we're open to hear any
>> feedback from userland.
>>
>>
>>
>> Cheers,
>>
>>
>> On Fri, Aug 28, 2009 at 8:22 AM, Matthew Weier
>> O'Phinney<[email-masked]> wrote:
>> > -- Benjamin Eberlei <[email-masked]> wrote
>> > (on Thursday, 27 August 2009, 10:06 PM +0200):
>> >> i am currently scratching my head on howto abstract the query API for=
 different
>> >> storages and often think about CouchDb which has a fundamently differ=
ent Query
>> >> concept than a RDBMS.
>> >>
>> >> For clarification to the not so familiar, it the EntityManager is the=
 sole
>> >> public API to the user of Zend_Entity and its facilities. It manages =
the life-
>> >> cycle of domain objects.
>> >>
>> >> Currently, it has the following API for queries:
>> >>
>> >> EntityManager::load($entityClass, $id);
>> >> EntityManager::createNamedQuery($name);
>> >> EntityManager::createNativeQuery($input, $resultSetMapping);
>> >> EntityManager::createNativeQueryBuilder($entityClass=3Dnull);
>> >> EntityManager::createQuery($zql); // not implemented yet
>> >> EntityManager::createQueryBuilder(); // not implemented yet
>> >>
>> >> This is very large and still very RDBMS specific interface. To break =
that up
>> >> I was thinking to go the following way, only have three methods:
>> >>
>> >> EntityManager::load($entityClass, $id);
>> >> EntityManager::createNamedQuery($name);
>> >> EntityManager::createNativeQuery($input, $resultSetMapping);
>> >>
>> >> And all the other Query related stuff is implemented and used explici=
tly by
>> >> calling for example:
>> >>
>> >> $sqlQueryBuilder =3D new Zend_Db_Mapper_SqlQueryBuilder($entityManage=
r);
>> >> $queryBuilder =3D new Zend_Db_Mapper_QueryBuilder($entityManager);
>> >> $zqlQuery =3D new Zend_Db_Mapper_ZqlQuery($entityManager);
>> >>
>> >> This way the API can be hinted explicitly in IDEs (since its often qu=
ite
>> >> complex) and storage specific features can be implemented.
>> >
>> > This seems like a very good approach to me. It keeps the primary query
>> > types front and center, but offers the flexibility to create your own
>> > without needing to inform Zend_Entity of them. I particularly like thi=
s
>> > because it introduces the idea of a "criteria" object -- which can the=
n
>> > be as abstract as you want it, or specific to your particular data
>> > storage implementation.
>> >
>> >> Now you ask yourself, how is this storage independent? It is via the
>> >> "createNamedQuery()" method. This method internally uses the plugin
>> >> loader to instantiate queries via the command pattern. In a storage
>> >> independent database, all operations have to be build as named query
>> >> and executed such. =C2=A0For each storage a corresponding implementat=
ion
>> >> has to exist.
>> >
>> > This seems like it would be very compatible with CouchDB views,
>> > actually.
>> >
>> > --
>> > Matthew Weier O'Phinney
>> > Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]=
om
>> > Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.ze=
nd.com/
>> >
>>
>>
>>
>> --
>> Guilherme Blanco - Web Developer
>> CBC - Certified Bindows Consultant
>> Cell Phone: +55 (16) 9215-8480
>> MSN: [email-masked]
>> URL: http://blog.bisna.com
>> S=C3=A3o Paulo - SP/Brazil
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/

--=20
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [email-masked]
URL: http://blog.bisna.com
S=C3=A3o Paulo - SP/Brazil

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Ryan Vennell <[email-masked]>
Date: Mon, 11 Jan 2010 16:09:14 -0600
To: [email-masked]
Subject: [zf-contributors] PHP error in framework docs search results.

--Apple-Mail-2--674770674
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hey,

I put in the search term "timezone" in the reference guide, and got a =
whole page full of errors:
=
http://framework.zend.com/manual/search?query=3Dtimezone&language=3Den&sea=
rch=3DSearch+Manual!

Example:
Notice: Undefined offset: 159 in =
/var/www/website-release-1.9.7/framework/library/Zend/Search/Lucene/Search=
/Query/MultiTerm.php on line 480

They're all pretty much identical, but the offset changes for each =
error.

Thanks!

-RV=

--Apple-Mail-2--674770674
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hey,<div><br></div><div>I put in the search term "timezone" in the reference guide, and got a whole page full of errors:</div><div><a href="http://framework.zend.com/manual/search?query=timezone&amp;language=en&amp;search=Search+Manual!">http://framework.zend.com/manual/search?query=timezone&amp;language=en&amp;search=Search+Manual!</a></div><div><br></div><div>Example:</div><div><b>Notice</b>:  Undefined offset:  159 in <b>/var/www/website-release-1.9.7/framework/library/Zend/Search/Lucene/Search/Query/MultiTerm.php</b> on line <b>480</b></div><div><br></div><div>They're all pretty much identical, but the offset changes for each error.</div><div><br></div><div>Thanks!</div><div><br></div><div>-RV</div></body></html>
--Apple-Mail-2--674770674--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 17:27:12 +0100
From: Julien Pauli <[email-masked]>
To: Anthony Shireman <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

Well, as far as there is a reference guide for GIT for those who never
used it (me, for example), why not...

J.Pauli

On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]> wro=
te:
> Moving from SVN to Git seems like quite a major switch. But, with the ste=
p
> from 1.X to 2.0 it seems like a good time to do it. I like the idea (as
> David Caunt mentioned) of releasing a 1.X branch with Doctrine 1 to test =
the
> waters and judging by the amount of work required decide to go with Doc2+=
ZF2
> when the time comes. It's an exciting time to work with ZF and I'm lookin=
g
> forward to a time when ZF2 uses Git and Doctrine 2.
>
>
> On Thu, Feb 25, 2010 at 5:20 AM, Matthew Weier O'Phinney <[email-masked]=
m>
> wrote:
>>
>> -- David Caunt <[email-masked]> wrote
>> (on Thursday, 25 February 2010, 11:13 AM +0000):
>> > Integration of Doctrine 1 with ZF 1.11 might be a good way to test the
>> > water and then community feedback may inform ZF2's integration with
>> > Doctrine 2.
>> >
>> > As keen as I am for ZF2, I think the amount of work to be done on the
>> > core is substantial and probably leaves enough time for a 1.11
>> > release.
>>
>> Well, that's what we're trying to gauge at this point. It seems like a
>> substantial amount of work, but if the initial development I outlined
>> goes quickly, we may find ourselves working on the various
>> rewrites/refactors much sooner, which could lead to an earlier release.
>> Then again, it may take much longer, meaning a delay. I don't want to
>> make a call either way yet, and thus the uncertainty about a 1.11
>> release.
>>
>> If we end up deciding to do a 1.11 branch, we'll very likely look at
>> doing integration with Doctrine 1.2 for the very reasons you describe,
>> but also to serve as an upgrade path for ZF users.
>>
>> > Are there any plans to maintain the 1.x series once 2.0 is released?
>>
>> This is another area we're trying to gauge -- whether to continue
>> maintenance on the 1.X branch following a 2.0 release.
>>
>> My personal feeling is that if we do, any future releases would address
>> only critical bugs or security issues, and no new features. As long as
>> we develop new features on the 1.X series, we'll hamper adoption of 2.0.
>> In this vein, we'd likely do like the PHP project did, and do a new
>> minor release on the version 1 branch simultaneous to 2.0 that would be
>> for tracking those issues.
>>
>> If we do, I'll likely look for a small team from the community to assist
>> as release masters for that branch.
>>
>>
>> > On 25 February 2010 10:46, Giorgio Sironi
>> > <[email-masked]>
>> > wrote:
>> >
>> > =A0 =A0 On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley
>> > <[email-masked]>
>> > =A0 =A0 wrote:
>> >
>> > =A0 =A0 =A0 =A0 In my opinion if Doctrine integration is to be left un=
til ZF
>> > 2.0, then
>> > =A0 =A0 =A0 =A0 the integrated version of Doctrine should be the 2.0 v=
ersion.
>> > Since
>> > =A0 =A0 =A0 =A0 both 2.0 versions will require PHP 5.3.
>> >
>> >
>> > =A0 =A0 I agree. Doctrine 2 will fill the lack of model infrastructure=
 in
>> > Zend
>> > =A0 =A0 Framework.
>> > =A0 =A0 Anyway, the set of changes listed by Matthew is already a big =
step
>> > towards
>> > =A0 =A0 simpler development (exploiting phpunit new features for examp=
le.)
>> >
>> > =A0 =A0 Regards,
>> > =A0 =A0 --
>> > =A0 =A0 Giorgio Sironi
>> > =A0 =A0 Piccolo Principe & Web Engineer
>> > =A0 =A0 http://giorgiosironi.blogspot.com
>> > =A0 =A0 http://twitter.com/giorgiosironi
>> >
>> >
>> >
>> >
>> > --
>> > Save Water...Drink Ouzo !
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
>> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
>

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 01 May 2009 08:51:05 -0700
From: Kevin McArthur <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] ZF has mostly integration-tests, no unittests

This is a cryptographically signed message in MIME format.

--------------ms050102040800050603060703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Maybe we should revisit our testing-strategy and remove 
testing-for-the-sake-of-testing ... driven development.

Testing should add value... right now, and with what you're proposing... 
it removes value, retards development, and adds a significant 
contribution overhead -- none of which is good for the advancement of 
the project's core features.

$0.02

Kevin

Benjamin Eberlei wrote:
> Running a grep on the function 'getMock' of phpunit in the Zend Framework code 
> basis shows that there are exactly 13 calls. Running any single testsuite 
> shows that tests mostly depend on several other components, who depend on 
> other components and so on.
>
> Tests are for defect localization, otherwise they are integration tests and 
> produce a large set of unmaintainable test-code which bites any component lead 
> in the back some day.
>
> We should maybe revisit our testing-strategy and enforce test-driven 
> development on new components, additionally old unittests should be refactored 
> to be more unittest like and not general tests that are build after the fact 
> and only by tricking get to > 80% code-coverage . Any Ideas on how to improve 
> test-code? Its totally going to get back at us.
>
> For example look at Zend_Service_Amazon_OnlineTest. It talks to amazon for ALL 
> its tests and asserts nothing. Still if you for example only run the 
> "testItemSearchPhp" test you get a coverage of 76%! This is just bullhist!
>
> Many ZF testsuites are that bad. They dont really test much and produce false 
> comfort. The high number of bugs in many of the components are an indicator 
> that there is something wrong somewhat.
>
> greetings,
> Benjamin
>
>   

-- 

Kevin McArthur

StormTide Digital Studios Inc.
http://www.stormtide.ca

--------------ms050102040800050603060703
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050102040800050603060703--

nFrom nobody Wed Apr  7 08:46:08 2010
Date: Wed, 23 Sep 2009 16:40:04 +0200
Subject: Re: [zf-contributors] Discussion about Quality/Review Process - 
	Community RM proposal
From: till <[email-masked]>
To: Carlton Gibson <[email-masked]>
Cc: "Matthew Weier O'Phinney" <[email-masked]>,
	[email-masked]

On Wed, Sep 23, 2009 at 4:20 PM, Carlton Gibson
<[email-masked]> wrote:
> (...)
> Fair enough. Perhaps the ability to comment will be enough --- my concern is
> simply that of lowering the barrier to entry... :-)

Two cents on documentation and user interfaction.

IMHO, user comments could be a great way to...

 * spot obvious issues/shortcomings with the existing documentation
(e.g. if people are asking the same thing over and over maybe we need
an additional example, or rephrase whatever is written in the manual)
 * gather general feedback and additional tips

In the end responsible people (who signed a CLA) could transform these
comments into jira issues (API?).

I think one of the greatest advantages of PHP's documentation system
is that people can leave comments.

Of course they may need to be moderated and therefor not only provide
advantages but also disadvantages (time is always tight), but maybe
the advantages overrule the possible disadvantages.

Till

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 20 Mar 2009 12:47:55 -0700
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] Release Policies and Conventions

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A994.C418B746
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Over the 2 years that I've been involved with the project, there have
been many questions about what can go in to a given release and if there
are any guidelines for the release schedules. While many of you have
pieced the picture together from different mails, IRC chats, etc. I've
owed you a document for a long time now. Here it is:

=20

http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
tions

=20

I ask all contributors to review this and reply with any question or
edits- especially if I missed something- in this forum.

=20

As always, thanks for all the time and effort. Also, go 1.8!

=20

,Wil

------_=_NextPart_001_01C9A994.C418B746
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Over the 2 years that I&#8217;ve been involved with =
the
project, there have been many questions about what can go in to a given =
release
and if there are any guidelines for the release schedules. While many of =
you
have pieced the picture together from different mails, IRC chats, etc. =
I&#8217;ve
owed you a document for a long time now. Here it is:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><a
href=3D"http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and=
+Conventions">http://framework.zend.com/wiki/display/ZFDEV/Release+Polici=
es+and+Conventions</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I ask all contributors to review this and reply =
with any
question or edits- especially if I missed something- in this =
forum.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>As always, thanks for all the time and effort. =
Also, go 1.8!<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>,Wil<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9A994.C418B746--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Sat, 23 Jan 2010 00:24:54 +0100
Subject: Re: [zf-contributors] Zend_Date & build-in class DateTime

This has been discussed several times in past and the answer is still the 
same.

"As long as ZF uses minimum required PHP Versions where DateTime is not 
available per default (without changing configuration after installation) we 
will not change the I18n core."

Additionally the method "getTimestamp" you referred to is available per PHP 
5.3.0. It was not available in DateTime below this PHP release.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Marc Bennewitz" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 22, 2010 11:16 PM
Subject: [zf-contributors] Zend_Date & build-in class DateTime

> Hi all,
>
> Does is matter that Zend_Date doesn't extends the build-in DateTime class 
> ?
> -> The DateTime class is available since PHP 5.2.0 and ZF require PHP 
> 5.2.4.
>
> It would be very nice because than Zend_Date would be compatible to
> other php libraries using DateTime and within ZF tests like the
> following can simplify:
>
> if ($date instanceof Zend_Date_DateObject) {
>    $timestamp = $date->getUnixTimestamp();
> } elseif ($date instanceof DateTime) {
>    $timestamp = $date->getTimestamp();
> } else {
>    $timestamp = (float)$date;
> }
>
> Greetings,
> Marc
> 

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 5 Dec 2009 03:58:31 +0000
From: Juozas <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: [zf-contributors] Zend Framework modularity and application structure

--001485f1d850d116640479f33cdc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello everyone,

as you know, Zend Framework 2.0 is having a major rewrite in some parts and
a lot things can be arranged to make development easier/more flexible/etc.

After discussing this with Matthew, I'm asking you to:

*Write in short, how do you use Zend Framework*
*
*
What interests us is how you work with modules (blog, products, news,
users), how you divide your applications in to parts (admin, public,
something else) and how other parts of code (acl, configuration, resources)
comes into play here.

The reason why I'm asking this, is because I'm using Zend Framework for
quote big applications and for me it's important to have ability to create
application with self-contained modules and sub-applications. For example I
have e-commerce products having admin, public and supplier sub-applications=
,
but everything is still nicely divided into modules (products, warehouse,
orders, customers etc.) and App_Application and FrontController plugins doe=
s
some work to make one application code to be divided in these parts.

However, I know that some people use applications completely based on acl -
there is one site and only depending on what your permissions are, you see
data, can edit or delete if you want to. Here again somewhat different
structure comes into play. Also quite popular thing to do is to have
admin/default modules. Even though I completely don't understand this
approach, some people like it and use everyday, hence it should also be
possible to use.

So please write what you think about such things, I will try to read them
all, generalize into a comparison table and make it into a proposal of what
functions from core are needed to support it (without any hacking, which I
done quite a lot)

--
Juozas Kaziuk=C4=97nas ([email-masked])
A=C5=A1 internete - JuoKaz (http://www.juokaz.com)

--001485f1d850d116640479f33cdc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello everyone,<div><br></div><div>as you know, Zend Framework 2.0 is havin=
g a major rewrite in some parts and a lot things can be arranged to make de=
velopment easier/more flexible/etc.</div><div><br></div><div>After discussi=
ng this with Matthew, I&#39;m asking you to:</div>
<div><br></div><div><b>Write in short, how do you use Zend Framework</b></d=
iv><div><b><br></b></div><div>What=C2=A0interests us is how you work with m=
odules (blog, products, news, users), how you divide your applications in t=
o parts (admin, public, something else)=C2=A0and how other parts of code (a=
cl, configuration, resources) comes into play here.=C2=A0</div>
<div><br></div><div>The reason why I&#39;m asking this, is because I&#39;m =
using Zend Framework for quote big applications and for me it&#39;s importa=
nt to have ability to create application with self-contained modules and su=
b-applications. For example I have e-commerce products having admin, public=
 and supplier sub-applications, but everything is still nicely divided into=
 modules (products, warehouse, orders, customers etc.) and App_Application =
and FrontController plugins does some work to make one application code to =
be divided in these parts.=C2=A0</div>
<div><br></div><div>However, I know that some people use applications compl=
etely based on acl - there is one site and only depending on what your perm=
issions are, you see data, can edit or delete if you want to. Here again so=
mewhat different structure comes into play.=C2=A0Also quite popular thing t=
o do is to have admin/default modules. Even though I completely don&#39;t u=
nderstand this approach, some people like it and use everyday, hence it sho=
uld also be possible to use.=C2=A0</div>
<div><br></div><div>So please write what you think about such things, I wil=
l try to read them all, generalize into a comparison table and make it into=
 a proposal of what functions from core are needed to support it (without a=
ny hacking, which I done quite a lot)</div>
<div><br clear=3D"all">--<br>Juozas Kaziuk=C4=97nas (<a href=3D"mailto:juoz=
[email-masked]">[email-masked]</a>)<br>A=C5=A1 internete - JuoKaz (<a hre=
f=3D"http://www.juokaz.com">http://www.juokaz.com</a>)<br>
</div>

--001485f1d850d116640479f33cdc--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 8 Feb 2010 13:53:29 +0300
From: Georgy Turevich <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] FW: [fw-general] Topics for Zend Framework 
	conference (Russia, St. Petersburg). Lets discuss them!

--0003255579ea96b6f4047f149c5d
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

Hello Benjamin,

Thank you!

Some time ago i see similar problem in issue-tracker. And now, after your
feedback, I will consider it.

Benjamin, also I'm planing to contact with you about point "Looking to the
future!" of my speak.
Do you have any plans for improve ZendX_jQuery compnonent?

--
Georgy

2010/2/6 Benjamin Eberlei <[email-masked]>

>
> Hey Georgy,
>
> I see you are doing a talk on the ZendX jQuery integration. You should
> make sure to check
> out the current trunk, since it contains fixed to integrate the jQuery UI
> 1.8 Autocomplete
> Widget. In this regard the requirements are bumped up to jQuery 1.4 + UI
> 1.8 in the next release.
>
> greetings,
> Benjamin
>
> On Thu, 4 Feb 2010 16:08:09 -0800, "Alexander Veremyev"
> <[email-masked]> wrote:
> > Hi!
> >
> > First Russian ZF Conference is officially announced! :)
> > http://devzone.zend.com/article/11781-1st-Russian-Zend-Framework-Confer=
e
> > nce-Announced
> >
> > You are welcome to discuss conference topics and give your
> > recommendations to speakers.
> >
> > Topics list and theses are available here as well as in the DevZone
> > announce.
> >
> > With best regards,
> >    Alexander Veremyev.
> >
> > -----Original Message-----
> > From: Georgy Turevich [mailto:[email-masked]]
> > Sent: Thursday, February 04, 2010 2:52 AM
> > To: [email-masked]
> > Subject: [fw-general] Topics for Zend Framework conference (Russia, St.
> > Petersburg). Lets discuss them!
> >
> > Hello,
> >
> > ZF conference (ZFConf 2010) will take place in Saint Petersburg
> > (Russia) at the end of March.
> > I am one of this event's organizers so I would like to discuss the
> > topics of the expected topics with you.
> >
> > Our speakers are deeply interested in your feedback. On its basis they
> > can modify the content of their reviews.
> >
> > For russian developers which are not aware of the event yet:
> > - http://www.zfconf.ru
> > - additional discussions on topics are available at the forum:
> > http://zendframework.ru/forum/index.php?topic=3D2281.0
> >
> >
> > Here is the list of the expected topics (see the detailed theses for
> > each of them below):
> > - Proposal Lifecycle
> > - Zend_Search_Lucene in the Details
> > - Performance of Zend Framework Applications
> > - Zend Framework and MVC, <Fat> Model
> > - Fotostrana.ru: Prototyping Project with Zend Framework
> > - Using Message Queues in Day-to-Day Projects (Zend_Queue)
> > - Zend Framework and Doctrine
> > - ZF and Multilingual
> > - History of e-Shtab.ru
> > - What News Zend Framework 2.0 Brings to Us?
> > - jQuery and Dojo Toolkit JavaScript-frameworks Integration with Zend
> > Framework
> >
> >
> > =3D=3D=3D Proposal Lifecycle =3D=3D=3D
> > Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)
> >
> > This presentation is intended to describe Zend Framework proposal
> > lifecycle in details to give clear understanding of the steps required
> > to get proposal included into ZF.
> >
> > It'll touch on proposal lifecycle actors, proposal lifecycle
> > steps/proposal states, ZF repository areas created to support proposal
> > process and other things.
> > In addition to this some recommendations helping to promote your
> > proposal quickly will be given.
> >
> >
> > =3D=3D=3D Zend_Search_Lucene in the Details =3D=3D=3D
> > Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)
> >
> > Presentation gives a complete description of a Zend_Search_Lucene
> > full-text search component usage.
> >
> > It's oriented to new Zend_Search_Lucene users as well as to experienced
> > users.
> >
> > The following aspects will be described within presentation:
> >
> >     * history of component creation;
> >     * component purpose;
> >     * index format details (including factors affecting performance);
> >     * indexing and indexing performance;
> >     * searching using queries and query construction API;
> >     * search results pagination.
> >
> > Presentation also describes techniques of improving searching
> > performance for different modes of component usage.
> >
> >
> > =3D=3D=3D Performance of Zend Framework Applications =3D=3D=3D
> > Alexander Mahomet (ZendFramework.ru Community, Founder)
> >
> > The main goal of this report is to show how certain techniques can
> > improve performance of applications that use Zend Framework. I will
> > create demo application and will apply these techniques to it. Plan of
> > report:
> >
> > Problem definition:
> >
> >     * Overview of demo application;
> >     * Overview of testing environment;
> >     * Overview of instruments for testing;
> >     * Overview of parameters we should test, measurements before
> > testing.
> >
> > Overview of techniques (after each item - new measurements):
> >
> >     * Methods which are not directly connect to Zend Framework
> > (accelerators, setup of web server);
> >     * Deleting of require* from Zend Framework;
> >     * Joining of Zend Framework classes to one big file;
> >     * Autoloading and Zend_Loader;
> >     * Caching of objects (Zend_Config, Zend_Locale, Zend_Acl,
> > Zend_Navigation), caching of pages and blocks, caching results of
> > database queries, etc;
> >     * Memcache;
> >     * Recommendations from Zend Framework team;
> >     * How Zend_Server can help building high-load applications.
> >
> > Comparison Zend Framework performance with other popular PHP frameworks=
.
> >
> >
> > =3D=3D=3D Zend Framework and MVC, <Fat> Model =3D=3D=3D
> > Alexander Steshenko (Norada Corporation, PHP programmer)
> >
> > 1. MVC pattern in details
> >     * Controller, View
> >     * Model is the application logic. Model isolation from other parts
> > of MVC triad
> > 2. MVC implementation in Zend Framework
> >     * Zend_Controller_Action
> >     * Zend_Controller_Front
> >     * Zend_Controller_Dispatcher_Standard
> >     * Zend_Controller_Action_Helper_ViewRenderer
> >     * Zend_View
> > 3. Thin / Fat Model
> >     * What is thin Model, why it does not fit MVC pattern, code samples
> >     * <Fat> model is every fragment of the application and the whole
> > application itself
> >     * Domain model
> >     * Most often used data access patterns and approaches for modeling
> > application objects
> >     * Code samples
> >     * Data access design patterns flexibility problems
> >     * Benefits of Data Mapper - data access decomposition, easy
> > refactoring of every part of the application
> >     * Service layer, code samples
> > 4. General tips and advices
> >     * Automated testing
> >     * ORM tool
> >     * Good OOP, software design patterns
> >
> >
> > =3D=3D=3D Fotostrana.ru: Prototyping Project with Zend Framework =3D=3D=
=3D
> > Leonid Zhavoronkov (Fotostrana.ru, Teamlead)
> >
> > The history about Zend Framework usage in highload-project (12M hits,
> > 200K hosts):
> >     * Project's history and key features
> >     * Choice of ZF as a platform for a startup: benefits and drawbacks
> >     * Project's platform evolution
> >     * The current architecture of the project and plans for the future
> >
> >
> > =3D=3D=3D Using Message Queues in Day-to-Day Projects (Zend_Queue) =3D=
=3D=3D
> > Denis Baklikov (Obnovlenie, Web Developer)
> >
> > 1. What is message queues?
> >     * MQ history. JMS
> >     * Advantages of using message queues
> >     * Example usage of message queues. Bad examples
> >     * Messaging patterns
> > 2. Zend_Queue overview
> >     * Interfaces overview
> >     * Adapters overview
> >     * Using different adapters. Best practices
> >           o array
> >           o db
> >           o mq server
> >     * Zend_Queue development. Next steps
> > 3. MQ servers overview
> >     * List of MQ serves (main idea: show people large number of
> > servers they can use)
> >     * Features of messaging servers (ActiveMQ, MemcacheQ, ...)
> > 4. Projects using message queues
> >     * Classic example - delayed emails sending
> >     * Real time statistics processing
> >     * Social networks. Image uploading example
> >
> >
> > =3D=3D=3D Zend Framework and Doctrine =3D=3D=3D
> > Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)
> >
> > 1. Connection of Doctrine to ZF project
> >     * I will show the examples of code
> >     * I will tell which options are responsible for what
> > 2. Script for work with Doctrine_Cli
> >     * I will show an example of work with Doctrine Cli
> >     * I will tell how to create your task for Doctrine Cli
> > 3. Generation models and mappers with yaml schemes. Inheritance.
> > Migrations
> >     * I will show the example of some simple circuits with binding and
> > inheritance
> >     * I will show our inputs for the models'autogeneration in modular
> > application that correspond to standard coding of Zend Framework
> > 4. Adapters for Zend_Paginator and Zend_Auth
> >     * I will tell how to work and to show code
> > 5. Caching of query results
> >     * I will tell and show how to connect it and how to work with it
> >
> >
> > =3D=3D=3D ZF and Multilingual =3D=3D=3D
> > Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)
> >
> > 1. Adding language in the URL using a custome router (author -
> > Konstantin Yurevich), a standard router and hostname router. Pluses
> > and minuses of each approach
> >     * I will show an examples of routers and examples of simple
> > applications
> >     * I will speak about pluses and minuses this routers in terms of SE=
O
> > 2. Plugin or action helper to initialize translator
> >     * I will show code examples
> > 3. Why gettext? Nuances and hacks in the implementation of
> > multilanguage through gettext
> >     * I will show how convenient to add gettext through poedit and
> > explain why I think other ways of localization inconvenient
> >     * I will tell you that we do to translate validators messages
> > 4. Caching
> >     * I will show code examples
> >
> >
> > =3D=3D=3D History of e-Shtab.ru =3D=3D=3D
> > Anatoliy Larin (e-Legion, Web Developer)
> >
> > Architecture:
> >     * Zend_Application, Zend_Config, Zend_Controller, Zend_Router
> >     * MySQL, Zend_Db_Select, Zend_Db_Table, Zend_Db_Row
> >       Table and Row have partly performed the Model role.
> >     * Smarty
> >       We gave up using PHTML because of its extreme flexibility,
> > posibility to change the data right in the template.
> >     * Zend_Feed, Zend_Pagination, Zend_Openid
> > Problems:
> >     * Smarty autoescaping
> >       The programmers' forgetfulness became a problem, we missed out
> > too many XSS holes.
> >       The problem was solved via patching the Smarty by adding
> > variables autoescaping functionality.
> >     * Console jobs
> >       Zend Framework does not provide instruments for creating console
> > tasks (crontab, management tasks).
> >     * A lot of problems related to character encodings
> >     * Unintuitive URL-Router (upside-down)
> >     * Error in long email subject in Russian
> >       We had to spend a few days, to solve the issue.
> >       http://framework.zend.com/issues/browse/ZF-1688
> > (07.07.07-18.01.09)
> >     * Notice, warning instead of Exceptions
> >       At first we paid no attention to them, which led to bad
> > consequences a few times.
> >       As a result, we haven't elaborated correct coding style, which
> > we got in other programming languages, where the bad-quality code is
> > denied by compiler / interpreter.
> >     * Reusability
> >       Few parts of code we were able to use again without a pain.
> >       A lot of things were created by copy'n'paste of existing code.
> >
> >
> > =3D=3D=3D What News Zend Framework 2.0 Brings to Us? =3D=3D=3D
> > Nadezhda Blinova (Wizartech, Web Programmer), Georgy Turevich
> > (Wizartech, Lead Web Programmer)
> >
> > The following changes will be examined in the review:
> >     * Architectural \ Design Changes
> >     * MVC Implementation
> >     * Plugin Architectures
> >     * Other components (Zend_Acl, Zend_Controller,
> > Zend_Controller_Router, Zend_Form, Zend_Session, Zend_Soap, Zend_View,
> > Zend_Mail)
> > In the course of the review preparation the latest details will be
> > obtained from ZF developers.
> >
> >
> > =3D=3D=3D jQuery and Dojo Toolkit JavaScript-frameworks Integration wit=
h
> > Zend Framework =3D=3D=3D
> > Georgy Turevich (Wizartech, Lead Web Programmer)
> >
> > During the presentation we will take a detailed look at different
> > aspects of the integration and examine some examples:
> > 1.  ZF + jQuery and ZF + Dojo Toolkit features overview
> > 2. jQuery
> >     * Setup jQuery Core and jQuery UI enviroments
> >     * Automation work with jQuery UI-components
> >     * Working with "autocompletion"
> >     * Zend_Form customization with jQuery UI
> >     * Looking to the future!
> > 3.    Dojo Toolkit
> >     * Setup Dojo-enviroment
> >     * Automation with dijit's
> >     * Working with "autocompletion"
> >     * Zend_Form customization with Dijit
> >     * Generation of data in specialized format (dojo.data)
> >     * Automation Deployment Dojo Toolkit
> >     * Looking to the future!
> > 4. Several practical demontstrations
> >
> >
> > Best Regards,
> > Georgy Turevich
>

--=20
=E7=C5=CF=D2=C7=C9=CA, +7 921 384 81 25

--0003255579ea96b6f4047f149c5d
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

Hello Benjamin,<div><br></div><div>Thank you!</div><div><br></div><div>Some=
 time ago i see similar problem in issue-tracker. And now, after your feedb=
ack, I will consider it.</div><div><br></div><div>Benjamin, also I&#39;m pl=
aning to contact with you about point &quot;<span class=3D"Apple-style-span=
" style=3D"font-family: arial, sans-serif; font-size: 13px; border-collapse=
: collapse; ">Looking to the future!<span class=3D"Apple-style-span" style=
=3D"border-collapse: separate; font-family: arial; font-size: small; ">&quo=
t; of my speak.</span></span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl=
e-span" style=3D"border-collapse: separate; font-family: arial; font-size: =
small; ">Do you have any plans for improve ZendX_jQuery compnonent?</span><=
/span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl=
e-span" style=3D"border-collapse: separate; font-family: arial; font-size: =
small; "><br>
</span></span></div><div><span class=3D"Apple-style-span" style=3D"font-fam=
ily: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span=
 class=3D"Apple-style-span" style=3D"border-collapse: separate; font-family=
: arial; font-size: small; ">--</span></span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 13px; border-collapse: collapse; "><span class=3D"Apple-styl=
e-span" style=3D"border-collapse: separate; font-family: arial; font-size: =
small; ">Georgy</span></span></div>
<div><br><div class=3D"gmail_quote">2010/2/6 Benjamin Eberlei <span dir=3D"=
ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;=
</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex;">
<br>
Hey Georgy,<br>
<br>
I see you are doing a talk on the ZendX jQuery integration. You should<br>
make sure to check<br>
out the current trunk, since it contains fixed to integrate the jQuery UI<b=
r>
1.8 Autocomplete<br>
Widget. In this regard the requirements are bumped up to jQuery 1.4 + UI<br=
1.8 in the next release.<br>
<br>
greetings,<br>
<font color=3D"#888888">Benjamin<br>
</font><div><div></div><div class=3D"h5"><br>
On Thu, 4 Feb 2010 16:08:09 -0800, &quot;Alexander Veremyev&quot;<br>
&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wr=
ote:<br>
&gt; Hi!<br>
&gt;<br>
&gt; First Russian ZF Conference is officially announced! :)<br>
&gt; <a href=3D"http://devzone.zend.com/article/11781-1st-Russian-Zend-Fram=
ework-Confere" target=3D"_blank">http://devzone.zend.com/article/11781-1st-=
Russian-Zend-Framework-Confere</a><br>
&gt; nce-Announced<br>
&gt;<br>
&gt; You are welcome to discuss conference topics and give your<br>
&gt; recommendations to speakers.<br>
&gt;<br>
&gt; Topics list and theses are available here as well as in the DevZone<br=
&gt; announce.<br>
&gt;<br>
&gt; With best regards,<br>
&gt; =9A =9AAlexander Veremyev.<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: Georgy Turevich [mailto:<a href=3D"mailto:georgy.turevich@gmail.=
com">[email-masked]</a>]<br>
&gt; Sent: Thursday, February 04, 2010 2:52 AM<br>
&gt; To: <a href=3D"mailto:[email-masked]">[email-masked]=
.com</a><br>
&gt; Subject: [fw-general] Topics for Zend Framework conference (Russia, St=
.<br>
&gt; Petersburg). Lets discuss them!<br>
&gt;<br>
&gt; Hello,<br>
&gt;<br>
&gt; ZF conference (ZFConf 2010) will take place in Saint Petersburg<br>
&gt; (Russia) at the end of March.<br>
&gt; I am one of this event&#39;s organizers so I would like to discuss the=
<br>
&gt; topics of the expected topics with you.<br>
&gt;<br>
&gt; Our speakers are deeply interested in your feedback. On its basis they=
<br>
&gt; can modify the content of their reviews.<br>
&gt;<br>
&gt; For russian developers which are not aware of the event yet:<br>
&gt; - <a href=3D"http://www.zfconf.ru" target=3D"_blank">http://www.zfconf=
.ru</a><br>
&gt; - additional discussions on topics are available at the forum:<br>
&gt; <a href=3D"http://zendframework.ru/forum/index.php?topic=3D2281.0" tar=
get=3D"_blank">http://zendframework.ru/forum/index.php?topic=3D2281.0</a><b=
r>
&gt;<br>
&gt;<br>
&gt; Here is the list of the expected topics (see the detailed theses for<b=
r>
&gt; each of them below):<br>
&gt; - Proposal Lifecycle<br>
&gt; - Zend_Search_Lucene in the Details<br>
&gt; - Performance of Zend Framework Applications<br>
&gt; - Zend Framework and MVC, &lt;Fat&gt; Model<br>
&gt; - Fotostrana.ru: Prototyping Project with Zend Framework<br>
&gt; - Using Message Queues in Day-to-Day Projects (Zend_Queue)<br>
&gt; - Zend Framework and Doctrine<br>
&gt; - ZF and Multilingual<br>
&gt; - History of e-Shtab.ru<br>
&gt; - What News Zend Framework 2.0 Brings to Us?<br>
&gt; - jQuery and Dojo Toolkit JavaScript-frameworks Integration with Zend<=
br>
&gt; Framework<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D Proposal Lifecycle =3D=3D=3D<br>
&gt; Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)<=
br>
&gt;<br>
&gt; This presentation is intended to describe Zend Framework proposal<br>
&gt; lifecycle in details to give clear understanding of the steps required=
<br>
&gt; to get proposal included into ZF.<br>
&gt;<br>
&gt; It&#39;ll touch on proposal lifecycle actors, proposal lifecycle<br>
&gt; steps/proposal states, ZF repository areas created to support proposal=
<br>
&gt; process and other things.<br>
&gt; In addition to this some recommendations helping to promote your<br>
&gt; proposal quickly will be given.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D Zend_Search_Lucene in the Details =3D=3D=3D<br>
&gt; Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)<=
br>
&gt;<br>
&gt; Presentation gives a complete description of a Zend_Search_Lucene<br>
&gt; full-text search component usage.<br>
&gt;<br>
&gt; It&#39;s oriented to new Zend_Search_Lucene users as well as to experi=
enced<br>
&gt; users.<br>
&gt;<br>
&gt; The following aspects will be described within presentation:<br>
&gt;<br>
&gt; =9A =9A * history of component creation;<br>
&gt; =9A =9A * component purpose;<br>
&gt; =9A =9A * index format details (including factors affecting performanc=
e);<br>
&gt; =9A =9A * indexing and indexing performance;<br>
&gt; =9A =9A * searching using queries and query construction API;<br>
&gt; =9A =9A * search results pagination.<br>
&gt;<br>
&gt; Presentation also describes techniques of improving searching<br>
&gt; performance for different modes of component usage.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D Performance of Zend Framework Applications =3D=3D=3D<br>
&gt; Alexander Mahomet (ZendFramework.ru Community, Founder)<br>
&gt;<br>
&gt; The main goal of this report is to show how certain techniques can<br>
&gt; improve performance of applications that use Zend Framework. I will<br=
&gt; create demo application and will apply these techniques to it. Plan of=
<br>
&gt; report:<br>
&gt;<br>
&gt; Problem definition:<br>
&gt;<br>
&gt; =9A =9A * Overview of demo application;<br>
&gt; =9A =9A * Overview of testing environment;<br>
&gt; =9A =9A * Overview of instruments for testing;<br>
&gt; =9A =9A * Overview of parameters we should test, measurements before<b=
r>
&gt; testing.<br>
&gt;<br>
&gt; Overview of techniques (after each item - new measurements):<br>
&gt;<br>
&gt; =9A =9A * Methods which are not directly connect to Zend Framework<br>
&gt; (accelerators, setup of web server);<br>
&gt; =9A =9A * Deleting of require* from Zend Framework;<br>
&gt; =9A =9A * Joining of Zend Framework classes to one big file;<br>
&gt; =9A =9A * Autoloading and Zend_Loader;<br>
&gt; =9A =9A * Caching of objects (Zend_Config, Zend_Locale, Zend_Acl,<br>
&gt; Zend_Navigation), caching of pages and blocks, caching results of<br>
&gt; database queries, etc;<br>
&gt; =9A =9A * Memcache;<br>
&gt; =9A =9A * Recommendations from Zend Framework team;<br>
&gt; =9A =9A * How Zend_Server can help building high-load applications.<br=
&gt;<br>
&gt; Comparison Zend Framework performance with other popular PHP framework=
s.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D Zend Framework and MVC, &lt;Fat&gt; Model =3D=3D=3D<br>
&gt; Alexander Steshenko (Norada Corporation, PHP programmer)<br>
&gt;<br>
&gt; 1. MVC pattern in details<br>
&gt; =9A =9A * Controller, View<br>
&gt; =9A =9A * Model is the application logic. Model isolation from other p=
arts<br>
&gt; of MVC triad<br>
&gt; 2. MVC implementation in Zend Framework<br>
&gt; =9A =9A * Zend_Controller_Action<br>
&gt; =9A =9A * Zend_Controller_Front<br>
&gt; =9A =9A * Zend_Controller_Dispatcher_Standard<br>
&gt; =9A =9A * Zend_Controller_Action_Helper_ViewRenderer<br>
&gt; =9A =9A * Zend_View<br>
&gt; 3. Thin / Fat Model<br>
&gt; =9A =9A * What is thin Model, why it does not fit MVC pattern, code sa=
mples<br>
&gt; =9A =9A * &lt;Fat&gt; model is every fragment of the application and t=
he whole<br>
&gt; application itself<br>
&gt; =9A =9A * Domain model<br>
&gt; =9A =9A * Most often used data access patterns and approaches for mode=
ling<br>
&gt; application objects<br>
&gt; =9A =9A * Code samples<br>
&gt; =9A =9A * Data access design patterns flexibility problems<br>
&gt; =9A =9A * Benefits of Data Mapper - data access decomposition, easy<br=
&gt; refactoring of every part of the application<br>
&gt; =9A =9A * Service layer, code samples<br>
&gt; 4. General tips and advices<br>
&gt; =9A =9A * Automated testing<br>
&gt; =9A =9A * ORM tool<br>
&gt; =9A =9A * Good OOP, software design patterns<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D Fotostrana.ru: Prototyping Project with Zend Framework =3D=
=3D=3D<br>
&gt; Leonid Zhavoronkov (Fotostrana.ru, Teamlead)<br>
&gt;<br>
&gt; The history about Zend Framework usage in highload-project (12M hits,<=
br>
&gt; 200K hosts):<br>
&gt; =9A =9A * Project&#39;s history and key features<br>
&gt; =9A =9A * Choice of ZF as a platform for a startup: benefits and drawb=
acks<br>
&gt; =9A =9A * Project&#39;s platform evolution<br>
&gt; =9A =9A * The current architecture of the project and plans for the fu=
ture<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D Using Message Queues in Day-to-Day Projects (Zend_Queue) =3D=
=3D=3D<br>
&gt; Denis Baklikov (Obnovlenie, Web Developer)<br>
&gt;<br>
&gt; 1. What is message queues?<br>
&gt; =9A =9A * MQ history. JMS<br>
&gt; =9A =9A * Advantages of using message queues<br>
&gt; =9A =9A * Example usage of message queues. Bad examples<br>
&gt; =9A =9A * Messaging patterns<br>
&gt; 2. Zend_Queue overview<br>
&gt; =9A =9A * Interfaces overview<br>
&gt; =9A =9A * Adapters overview<br>
&gt; =9A =9A * Using different adapters. Best practices<br>
&gt; =9A =9A =9A =9A =9A o array<br>
&gt; =9A =9A =9A =9A =9A o db<br>
&gt; =9A =9A =9A =9A =9A o mq server<br>
&gt; =9A =9A * Zend_Queue development. Next steps<br>
&gt; 3. MQ servers overview<br>
&gt; =9A =9A * List of MQ serves (main idea: show people large number of<br=
&gt; servers they can use)<br>
&gt; =9A =9A * Features of messaging servers (ActiveMQ, MemcacheQ, ...)<br>
&gt; 4. Projects using message queues<br>
&gt; =9A =9A * Classic example - delayed emails sending<br>
&gt; =9A =9A * Real time statistics processing<br>
&gt; =9A =9A * Social networks. Image uploading example<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D Zend Framework and Doctrine =3D=3D=3D<br>
&gt; Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)<br>
&gt;<br>
&gt; 1. Connection of Doctrine to ZF project<br>
&gt; =9A =9A * I will show the examples of code<br>
&gt; =9A =9A * I will tell which options are responsible for what<br>
&gt; 2. Script for work with Doctrine_Cli<br>
&gt; =9A =9A * I will show an example of work with Doctrine Cli<br>
&gt; =9A =9A * I will tell how to create your task for Doctrine Cli<br>
&gt; 3. Generation models and mappers with yaml schemes. Inheritance.<br>
&gt; Migrations<br>
&gt; =9A =9A * I will show the example of some simple circuits with binding=
 and<br>
&gt; inheritance<br>
&gt; =9A =9A * I will show our inputs for the models&#39;autogeneration in =
modular<br>
&gt; application that correspond to standard coding of Zend Framework<br>
&gt; 4. Adapters for Zend_Paginator and Zend_Auth<br>
&gt; =9A =9A * I will tell how to work and to show code<br>
&gt; 5. Caching of query results<br>
&gt; =9A =9A * I will tell and show how to connect it and how to work with =
it<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D ZF and Multilingual =3D=3D=3D<br>
&gt; Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)<br>
&gt;<br>
&gt; 1. Adding language in the URL using a custome router (author -<br>
&gt; Konstantin Yurevich), a standard router and hostname router. Pluses<br=
&gt; and minuses of each approach<br>
&gt; =9A =9A * I will show an examples of routers and examples of simple<br=
&gt; applications<br>
&gt; =9A =9A * I will speak about pluses and minuses this routers in terms =
of SEO<br>
&gt; 2. Plugin or action helper to initialize translator<br>
&gt; =9A =9A * I will show code examples<br>
&gt; 3. Why gettext? Nuances and hacks in the implementation of<br>
&gt; multilanguage through gettext<br>
&gt; =9A =9A * I will show how convenient to add gettext through poedit and=
<br>
&gt; explain why I think other ways of localization inconvenient<br>
&gt; =9A =9A * I will tell you that we do to translate validators messages<=
br>
&gt; 4. Caching<br>
&gt; =9A =9A * I will show code examples<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D History of e-Shtab.ru =3D=3D=3D<br>
&gt; Anatoliy Larin (e-Legion, Web Developer)<br>
&gt;<br>
&gt; Architecture:<br>
&gt; =9A =9A * Zend_Application, Zend_Config, Zend_Controller, Zend_Router<=
br>
&gt; =9A =9A * MySQL, Zend_Db_Select, Zend_Db_Table, Zend_Db_Row<br>
&gt; =9A =9A =9A Table and Row have partly performed the Model role.<br>
&gt; =9A =9A * Smarty<br>
&gt; =9A =9A =9A We gave up using PHTML because of its extreme flexibility,=
<br>
&gt; posibility to change the data right in the template.<br>
&gt; =9A =9A * Zend_Feed, Zend_Pagination, Zend_Openid<br>
&gt; Problems:<br>
&gt; =9A =9A * Smarty autoescaping<br>
&gt; =9A =9A =9A The programmers&#39; forgetfulness became a problem, we mi=
ssed out<br>
&gt; too many XSS holes.<br>
&gt; =9A =9A =9A The problem was solved via patching the Smarty by adding<b=
r>
&gt; variables autoescaping functionality.<br>
&gt; =9A =9A * Console jobs<br>
&gt; =9A =9A =9A Zend Framework does not provide instruments for creating c=
onsole<br>
&gt; tasks (crontab, management tasks).<br>
&gt; =9A =9A * A lot of problems related to character encodings<br>
&gt; =9A =9A * Unintuitive URL-Router (upside-down)<br>
&gt; =9A =9A * Error in long email subject in Russian<br>
&gt; =9A =9A =9A We had to spend a few days, to solve the issue.<br>
&gt; =9A =9A =9A <a href=3D"http://framework.zend.com/issues/browse/ZF-1688=
" target=3D"_blank">http://framework.zend.com/issues/browse/ZF-1688</a><br>
&gt; (07.07.07-18.01.09)<br>
&gt; =9A =9A * Notice, warning instead of Exceptions<br>
&gt; =9A =9A =9A At first we paid no attention to them, which led to bad<br=
&gt; consequences a few times.<br>
&gt; =9A =9A =9A As a result, we haven&#39;t elaborated correct coding styl=
e, which<br>
&gt; we got in other programming languages, where the bad-quality code is<b=
r>
&gt; denied by compiler / interpreter.<br>
&gt; =9A =9A * Reusability<br>
&gt; =9A =9A =9A Few parts of code we were able to use again without a pain=
.<br>
&gt; =9A =9A =9A A lot of things were created by copy&#39;n&#39;paste of ex=
isting code.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D What News Zend Framework 2.0 Brings to Us? =3D=3D=3D<br>
&gt; Nadezhda Blinova (Wizartech, Web Programmer), Georgy Turevich<br>
&gt; (Wizartech, Lead Web Programmer)<br>
&gt;<br>
&gt; The following changes will be examined in the review:<br>
&gt; =9A =9A * Architectural \ Design Changes<br>
&gt; =9A =9A * MVC Implementation<br>
&gt; =9A =9A * Plugin Architectures<br>
&gt; =9A =9A * Other components (Zend_Acl, Zend_Controller,<br>
&gt; Zend_Controller_Router, Zend_Form, Zend_Session, Zend_Soap, Zend_View,=
<br>
&gt; Zend_Mail)<br>
&gt; In the course of the review preparation the latest details will be<br>
&gt; obtained from ZF developers.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3D jQuery and Dojo Toolkit JavaScript-frameworks Integration wi=
th<br>
&gt; Zend Framework =3D=3D=3D<br>
&gt; Georgy Turevich (Wizartech, Lead Web Programmer)<br>
&gt;<br>
&gt; During the presentation we will take a detailed look at different<br>
&gt; aspects of the integration and examine some examples:<br>
&gt; 1. =9AZF + jQuery and ZF + Dojo Toolkit features overview<br>
&gt; 2. jQuery<br>
&gt; =9A =9A * Setup jQuery Core and jQuery UI enviroments<br>
&gt; =9A =9A * Automation work with jQuery UI-components<br>
&gt; =9A =9A * Working with &quot;autocompletion&quot;<br>
&gt; =9A =9A * Zend_Form customization with jQuery UI<br>
&gt; =9A =9A * Looking to the future!<br>
&gt; 3. =9A =9ADojo Toolkit<br>
&gt; =9A =9A * Setup Dojo-enviroment<br>
&gt; =9A =9A * Automation with dijit&#39;s<br>
&gt; =9A =9A * Working with &quot;autocompletion&quot;<br>
&gt; =9A =9A * Zend_Form customization with Dijit<br>
&gt; =9A =9A * Generation of data in specialized format (dojo.data)<br>
&gt; =9A =9A * Automation Deployment Dojo Toolkit<br>
&gt; =9A =9A * Looking to the future!<br>
&gt; 4. Several practical demontstrations<br>
&gt;<br>
&gt;<br>
&gt; Best Regards,<br>
&gt; Georgy Turevich<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>=E7=C5=CF=
=D2=C7=C9=CA, +7 921 384 81 25<br>
</div>

--0003255579ea96b6f4047f149c5d--

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 20 Mar 2009 22:13:28 +0100
From: till <[email-masked]>
To: Wil Sinclair <[email-masked]>
Cc: Thomas Weidner <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

Yeah, I wanted to make sure.

Also, the following sentence is way to lax IMHO (also missing spaces
around the dashes):
Functionality enhancements are defined as behavioral changes that do
not affect- or minimally affect- one or more API's.

IMHO, that leaves too much room to argue what "minimally" is. IMHO, if
the API is effected in a way that it breaks BC, then it has to wait
for a major release and cannot be done in a minor or mini.

2 cents,
Till

On Fri, Mar 20, 2009 at 10:10 PM, Wil Sinclair <[email-masked]> wrote:
> You can add new API's and new features that don't affect API's much in
> mini releases. They have to be BC, however. I'm pretty sure that's
> called out in the document, but let me know if it's not.
>
> Thanks.
> ,Wil
>
> -----Original Message-----
> From: till [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 2:07 PM
> To: Wil Sinclair
> Cc: Thomas Weidner; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> What if I added a "feature" to an existing component.
>
> I mean, from what I understand -- the mini releases shouldn't break BC
> -- that's all. But if I add to the api that's allowed? (asking)
>
> On Fri, Mar 20, 2009 at 10:02 PM, Wil Sinclair <[email-masked]> wrote:
>> OK, I changed it. There will inevitably be some hand-waving around
> what
>> is a new feature and what is a functionality enhancement. I'd rather
>> confine this thread to the issue of release policies and conventions.
> :)
>>
>> New components pretty clearly fall under the category of 'new
> features'
>> in my mind. If others are confused, we should further clarify it.
>>
>> ,Wil
>>
>> -----Original Message-----
>> From: Thomas Weidner [mailto:[email-masked]]
>> Sent: Friday, March 20, 2009 1:42 PM
>> To: Wil Sinclair; [email-masked]
>> Subject: Re: [zf-contributors] Release Policies and Conventions
>>
>> Hy Wil,
>>
>> "A mini release may contain only bug fixes. Note that no new features
> or
>> API
>> changes are allowed whatsoever."
>>
>> This sentence could imply that new features are not allowed, but
>> improvments
>> of existing features are allowed as long as they don't change existing
>> API.
>> The word "only" could be overseen.
>>
>> The question is also what's for us the difference between a feature
>> enhancement and a new feature.
>> Feature Enhancement could be for example to add a new option. It would
>> not
>> change API. So a textual clearification would be great :-)
>>
>> Also to note: Are new components allowed within minor releases or only
>> within major releases? Should also be defined.
>>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com
>>
>> ----- Original Message -----
>> From: "Wil Sinclair" <[email-masked]>
>> To: "Thomas Weidner" <[email-masked]>;
>> <[email-masked]>
>> Sent: Friday, March 20, 2009 9:31 PM
>> Subject: RE: [zf-contributors] Release Policies and Conventions
>>
>>
>> Hey Thomas, I'm not quite sure what you are referring to. Your
>> understanding is correct, and the wiki page seems to reflect it
>> perfectly. Can you tell me exactly what needs to be updated? Maybe
> with
>> the string that you're referring to?
>>
>> Thanks.
>> ,Wil
>>
>> -----Original Message-----
>> From: Thomas Weidner [mailto:[email-masked]]
>> Sent: Friday, March 20, 2009 12:57 PM
>> To: Wil Sinclair; [email-masked]
>> Subject: Re: [zf-contributors] Release Policies and Conventions
>>
>> Hy Wil,
>>
>> In my understanding also "feature enhancements" are actually not
> allowed
>> to
>> be integrated within mini-releases.
>> Only "Bug fixes" which do not add additional API are allowed.
>>
>> Maybe you should also add a definition for what's a bug fix, a
>> improvement
>> and a new feature to get that also defined, and we can all speak of
> the
>> same
>> in future.
>>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com
>>
>> ----- Original Message -----
>> From: "Wil Sinclair" <[email-masked]>
>> To: <[email-masked]>
>> Sent: Friday, March 20, 2009 8:47 PM
>> Subject: [zf-contributors] Release Policies and Conventions
>>
>>
>> Over the 2 years that I've been involved with the project, there have
>> been many questions about what can go in to a given release and if
> there
>> are any guidelines for the release schedules. While many of you have
>> pieced the picture together from different mails, IRC chats, etc. I've
>> owed you a document for a long time now. Here it is:
>>
>>
>>
>>
> http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
>> tions
>>
>>
>>
>> I ask all contributors to review this and reply with any question or
>> edits- especially if I missed something- in this forum.
>>
>>
>>
>> As always, thanks for all the time and effort. Also, go 1.8!
>>
>>
>>
>> ,Wil
>>
>>
>

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 09:27:12 +0100
From: =?ISO-8859-1?Q?Jurri=EBn_Stutterheim?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

Personally, I would love to see Git being used, but I agree with Thomas. Go=
od tooling across all platforms is a must-have. Unfortunately, (tooling) su=
pport for Git on Windows is severely lacking.
A good alternative could be Bazaar[1]. Even though I have hardly used it, I=
 will try and summarize what I've read about it so far.
Tooling support across platforms is good. There is an Eclipse plugin[2], a =
TortoiseBzr client[3] that acts much like the popular ToirtoiseSVN, and a c=
ross-platform standalone tool, called BzrExplorer[4].
Another nice property of Bazaar is that it seems to be a bit more "managed"=
 (by my current lack of a better word) than Git. The default workflows it s=
upports are "safer" than those in Git. On one project I did, we tried Git, =
and the lack of enforced workflow by Git caused some commits to just get lo=
st or overridden. Granted, that was because we were all inexperienced with =
Git, but if that can happen in a small team, it can most definitely happen =
in a larger team, such as the team of all ZF contributors. For more informa=
tion, check out [5].

This email serves mostly as food for thought. I think the discussion should=
 not be Git vs SVN, but rather SVN vs DVCS.*

Cheers,

- Jurri=EBn

[1] http://bazaar.canonical.com/en/
[2] http://wiki.bazaar.canonical.com/BzrEclipse
[3] http://wiki.bazaar.canonical.com/WindowsDownloads
[4] http://wiki.bazaar.canonical.com/BzrExplorer
[5] http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html

=20
On Friday, February 26, 2010, at 08:46AM, "Thomas Weidner" <thomas.weidner@=
gmx.at> wrote:
>If there is a working integration into Eclipse than things are also ok for=
=20
>people who are using Windows (like me).
>
>But when you must always open a linux virtual machine or go down to comman=
d=20
>line from Eclipse to commit anything than this is a real blocker as it=20
>breaks the complete workflow and makes them less efficient.
>
>I have this problem and actually I am between 150 to 300 commits per month=
=20
>just to give a number.
>
>Greetings
>Thomas Weidner, I18N Team Leader, Zend Framework
>http://www.thomasweidner.com
>
>----- Original Message -----=20
>From: "P=E1draic Brady" <[email-masked]>
>To: "Dolf Schimmel" <[email-masked]>
>Cc: "Zend Framework Contributors" <[email-masked]>
>Sent: Friday, February 26, 2010 12:45 AM
>Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!
>
>
>I suppose just to make two points (I am pro-git but they need=20
>consideration).
>
>>> Tooling across platforms is not as mature or robust
>>Who needs
>anything else than /usr/bin/git? Obviously should the
>>Atlassian tools should support git as well, but I guess they do these
>>days.
>
>Original comment was referring to Windows. The tools are heavily Linux=20
>centric and I'm sure many of us are more than comfortable doing things the=
=20
>Linux way. I know I rarely, if ever, leave the command line except to swit=
ch=20
>to my editor or browser ;). Is everyone though? On Windows, the story is=
=20
>less kind and the tools somewhat cumbersome. On the other hand, for SVN, t=
he=20
>Windows tooling is very mature, easy to use, and integrates right in=20
>alongside pretty much everything.
>
>Paddy
>
> P=E1draic Brady
>
>http://blog.astrumfutura.com
>http://www.survivethedeepend.com
>OpenID Europe Foundation Irish Representative
>
>
>
>
>
>________________________________
>From: Dolf Schimmel <[email-masked]>
>To: Graham Anderson <[email-masked]>
>Cc: [email-masked]
>Sent: Thu, February 25, 2010 11:20:26 PM
>Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!
>
>I guess I'll have to confess I've been convinced ZF should use GIT,
>not only because other major projects like Zym use it (:wink:), but
>also because it seems to bring quite a lot of advantages, while hardly
>bringing any disadvantages.
>
>The cons (from the wiki):
>> Tracking CLAs becomes more difficult. Currently with SVN, we only grant=
=20
>> access to those who have signed a CLA; if anybody can fork, we now need=
=20
>> some way to verify CLA status before pulling patches.
>After all there's always someone who's committing to the 'main'
>(master?) repository. You can always track who makes those 'main'
>commits? The person committing to the main repos should then keep
>track of
>everybody contributing to a certain commit has signed a CLA (as is
>done now when a patch is applied). There should however be a clear and
>uptodate list of everybody who signed a CLA (that's more than a
>selectbox in jira...).
>
>
>> No good svn:externals equivalent
>We could just commit a checkout of Dojo (and possibly Dcotrine) into
>the ZF repository, making it read-only by anybody who's not a release
>manager. For people who use svn for their own projects, there should
>be an svn mirror for people to use for their svn:externals. If Zend
>can't provide such mirror I (my company) would be happy to do so.
>
>> Tooling across platforms is not as mature or robust
>Who needs anything else than /usr/bin/git? Obviously should the
>Atlassian tools should support git as well, but I guess they do these
>days.
>
>> Would potentially require (re-)training contributors
>I have never worked with git myself, but how difficult can the basics
>be? git clone, git pull, git status, git add, git commit -a should be
>things any contributor can understand (right?). Instead of actively
>train them, I'd be a fan of putting a link to
>http://git.or.cz/course/svn.html in the topic of #zftalk.dev on
>freenode (and the wiki etc...).
>
>
>--Freeaqingme
>
>P.s. For all of those not following me, I indeed had a different
>opinion on this a few days ago...
>
>On Thu, Feb 25, 2010 at 11:53 PM, Graham Anderson
><[email-masked]> wrote:
>> On Thursday 25 February 2010 21:48:57 Matthew Weier O'Phinney wrote:
>>>The release master can
>>>track multiple repos from multiple collaborators, and then selectively
>>>merge into their own "master" -- and push those patches into the
>>>mainline.
>>
>> For the benefit of those who don't currently use Git one other powerful=
=20
>> aspect
>> of this collaborative work-flow is being able to cherry pick commits.
>>
>> In this situation you may have multiple branches, some of them may or ma=
y=20
>> not
>> track other developers remote branches. Rather than merge the whole bran=
ch
>> from HEAD to 6 commits previously, you see that only one of the commits=
=20
>> has
>> the changeset you need. Git cherry-pick allows you to merge a single=20
>> commit.
>>
>> This, and being able to merge at will from multiple remote branches is t=
he
>> kind of functionality I believe makes Git more suitable than SVN for wha=
t=20
>> we
>> do.
>>
>> There's more, much more. One of the key differences between Git and SVN,=
=20
>> and
>> this is extremely important, is that Git tracks the _content_ of your=20
>> files
>> whereas SVN tracks the files themselves. Git really doesn't care that=20
>> there
>> are 10 or 20 or 1,000 files, it only cares about the content and it only=
=20
>> cares
>> how the content changes.
>>
>> Here's an example, since Layout.php has been in the codebase for a while=
 I
>> wanted to see who was responsible for last editing it. So i looked at th=
e
>> source and decided to lookup the method setMvcSuccessfulActionOnly(). It=
's=20
>> on
>> line number 483-487.
>>
>>    git blame -L 483,487 Layout.php
>>
>> I'll trim the output and ommit the actual code which is appended to the=
=20
>> end of
>> the following lines but you can see the detailed info that is available.
>>
>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
>> +0000
>> 483)
>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
>> +0000
>> 484)
>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
>> +0000
>> 485)
>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
>> +0000
>> 486)
>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
>> +0000
>> 487)
>>
>> So in less than a quarter of a second I can search the whole commit=20
>> history of
>> the main ZF repo and see who was responsible for last editing any line o=
f=20
>> any
>> file. There's lots more gems like this that let you unleash the power of=
=20
>> Git
>> if you want to look below the surface.
>>
>> The surface is a good place to be as well, let me offer a common work-fl=
ow
>> situation with git using every day commands.
>>
>> git checkout -b foobar
>> edit foo/bar.php
>> ... hack hack hack ...
>> *ring ring* oops emergency fix needed
>> git stash
>> git checkout master
>> edit emergency/fix.php
>> git commit -am "Commit fix!"
>> git checkout foobar
>> git stash pop
>> ... hack hack hack ...
>> git checkout master
>> git merge foobar
>> *glug glug glug* cold beers while your colleagues are still fighting SVN=
.
>>
>> The story above is: Create and move into feature branch "foobar". Start
>> hacking on the feature. Boss calls, X is broken!, stash your changes and
>> quickly switch to master(trunk). Fix broken things, commit them, switch=
=20
>> back
>> to foobar branch. Pop your changes from the stash into your working set,
>> continue hacking. Switch to master(trunk) and merge your new feature=20
>> Foobar.
>> Profit!
>>
>> --
>> =93What can be asserted without proof can be dismissed without proof.=94
>> - Christopher Hitchens
>>
>
>
>

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 7 Dec 2009 12:27:43 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

-- P=C3=A1draic Brady <[email-masked]> wrote
(on Monday, 07 December 2009, 08:34 AM -0800):
> >I'm missing the most important thing: write a unit test with known att=
ack
> vectors. If I'd want an improvement as important as security I'd write =
a unit
> test to prove that it works (or fails).
> > Putting the burden on someone else by hiding testable examples in a b=
log post
> > or email leaves a bad aftertaste.
>=20
> I apologise for exposing the stupidity of relying on Zend_Filter_StripT=
ags to
> prevent XSS, or even, like, strip tags. Truly. Sorry.
>=20
> Now read the blog and see where I three frigging times make it absolute=
ly clear
> that at the time I wrote this I did NOT consider this a security issue =
for the
> Zend Framework. I am ENTITLED to change my mind after over a day of dis=
cussing
> it which is exactly what I did. In the future, however, I will keep my =
mouth
> shut. When I see something wrong, I will remain silent.

My point to you on twitter and in my last post is that it was the
language you used to report that is raising the most questions.

If your post title had been, "Zend_Filter_StripTags: It's not an XSS
filter, stupid!" the connotation would have been quite different.
Instead, you use the phrase "Security Nightmare" in the title, which, as
a project lead, immediately raises my guard and has me wondering if a
security vulnerability is being reported.

For the first half of your post I totally agree with. It's from the
point "Bring Forth the Firing Squad" forward that I start to have
issues.=20

Your first example with a self-closed <img> tag should have simply been
reported via the issue tracker. It has nothing to do with your main
point, which was that StripTags does not protect against XSS. Same goes
for the second example (closing tags only example).

Your third example made sense... up to the sentence, "Given the
obviousness of this, it should be apparent that Zend_Filter_StripTags
offers an unknown level of XSS protection - i.e. it's untrustworthy."

At this point, your language deviates, and it becomes less clear if you
are claiming that users should be leary of using StripTags as it does
not protect from XSS, or if you are claiming that it _introduces_ an
XSS.=20

Additionally, the way you advertised the post on twitter makes this
unclear:

 * "Some debate over the StripTags security issues..."
   Makes it sound like there are security issues with the component (not
   that if mis-used, you can introduce security issues)

 * "The #ZF StripTags issue proving a sad lesson. Too many people don't
   actually understand XSS..."
   Makes it sound like StripTags has an XSS vulnerability

 * "Have just confirmed a second XSS vulnerability in
   Zend_Filter_StripTags"
   Explicitly calls it out as having multiple XSS vulnerabilities.

If you really don't feel that the component is vulnerable, then why use
that language and get everyone ranting and raving about it?=20

Do I think the blog post was misguided? No -- I just think it could have
been better executed to make your main point clearer: don't use
StripTags and think that you've protected yourself from XSS. And when
tweeting about it, it would have made more sense to be explicit as well:
"More examples showing why StripTags is not an XSS filter..."

Also, my critiques are not meant to silence you in any way. I simply
want to make it clear that you have to be careful when reporting
security vulnerabilities. Proper security etiquette would have you
discuss and collaborate with the vendor to fix the issue _prior_ to
reporting publically. In this case, since it wasn't an actual security
issue, my point is to be careful how you post security-related
information, to ensure that people don't jump to conclusions.

> Yeah, like that will happen...:P. I rant - live with it.
>=20
> Paddy
>=20
>=20
> =20
> P draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>=20
>=20
> =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=
> From: Nico Edtinger <[email-masked]>
> To: P draic Brady <[email-masked]>
> Sent: Mon, December 7, 2009 4:10:04 PM
> Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities I=
n
> Zend_Filter_StripTags
>=20
> Am 07.12.2009 um 15:26 schrieb P draic Brady:
>=20
>     I would also suggest the following:
>=20
>     a) Rework the filter's current four lines of documentation (http://
>     framework.zend.com/manual/en/zend.filter.set.html#zend.filter.set.s=
triptags
>     ) to cover the component in greater detail clarifying its use cases=
,
>     potential for misuse, and clarifying it is not XSS  or malformed HT=
ML safe.
>     b) Immediately deprecate in 1.9 branch (and remove in 2.0 - prefera=
bly 1.10
>     given its significance) its ability to flexibly allow some HTML/com=
ments
>     thus preserving its only truly worthwhile feature - stripping ALL H=
TML.
>     c) Do this ASAP.
>=20
>=20
> I'm missing the most important thing: write a unit test with known atta=
ck
> vectors. If I'd want an improvement as important as security I'd write =
a unit
> test to prove that it works (or fails). Putting the burden on someone e=
lse by
> hiding testable examples in a blog post or email leaves a bad aftertast=
e.
>=20
> nico

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 14:09:55 -0700
From: Stanislav Malyshev <[email-masked]>
Organization: Zend Technologies
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

Hi!

> When we made the decisions before, we were looking at the following
> three options for interfaces:
>
>   1. Prefix interfaces with "I" ("IFoobar").
>   2. Suffix interfaces with "Interface" ("FoobarInterface")
>   3. Use adjective/noun names such as "Foobarable", "Foobarist"

I like (3) better, with small note that it doesn't have to be specific 
form - i.e. just Element is better that trying to stick an unnatural 
prefix at the end of it (of course, if there's a natural one, like 
Countable, we're lucky :)
Now, the collision here is - what if we had both interface and abstract 
implementation of it - i.e. both Element interface and Element abstract 
class?
I think it would make sense to do it this way:

interface Element {}
abstract class ElementBase implements Element {}
class ConcreteElement extends ElementBase {}
class FancyElement implements Element {}

it would make code using Element look like:

function addElement(Element $element) {}

and:

if($element instanceof Element) { $element->doStuff(); }

which IMHO is both clear and compact (note that you would rarely use 
ElementBase in the code above since your base reference type is supposed 
to be Element, and ElementBase is just a code reuse tool).
-- 
Stanislav Malyshev, Zend Software Architect
[email-masked]   http://www.zend.com/
(408)253-8829   MSN: [email-masked]

nFrom nobody Wed Apr  7 08:46:08 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 25 Sep 2009 10:20:37 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] IMPORTANT: svn read-only and developer tools down
	tonight

Hey, all --

Our hosting provider is relocating our servers to a different facility
this evening, starting at 16:00 PDT. While we have arranged for a backup
server, we feel it would be safest during the transition if we:

 * mark SVN read-only
 * take down the developer tools (wiki, issue tracker, fisheye)

As such, I will be taking the above steps at 13:00 PDT today. They will
be down for 12-15 hours.

I will send an email when each transition occurs (taking them down,
bringing them back up).

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 03 Sep 2009 12:37:47 -0500
From: Ralph Schindler <[email-masked]>
To: Guilherme Blanco <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in
	Zend_Entity

> I know and I follow ZF evolution since the first day.
> But you probably know we have a rather poor support to Reflection in PHP.
> Once we reach a good stage and we find some free time, I'll work on
> patches to Reflection. Maybe soon we have some optimizations on it. =D

That would be awesome.  In fact, I'd like to see some of the 
functionality in Zend_Reflection move into the reflection extension, 
like phpdoc/annotation support.

The problem will always be that anytime reflection is spun up, you are 
introspecting code during runtime, which will never be cheap.

Ideally, I would like to see some kind of caching layer built into 
Zend_Reflection, so that developers can utilize Reflection during 
runtime and use cached information instead of reflecting on each 
request.  Since code does not change from one request to another, 
caching should be the most ideal solution for anyone with runtime 
reflection.

  -ralph

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Nico Edtinger <[email-masked]>
Date: Thu, 12 Nov 2009 21:41:11 +0100
Cc: [email-masked]
To: Kevin McArthur <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--Apple-Mail-9-578397287
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes

Kevin McArthur wrote:
> 1 ) Unified constructor. All constructors will (optionally) accept  
> an array of options or Zend_Config object as the first argument.
>
> I take exception to this because, well, it's just going to kill  
> performance -- and it doesn't follow industry standard techniques  
> for this type of thing. This shouldn't be a rule as a ton of classes  
> have no reason to be configurable, or make a lot more sense to take  
> real parameters, rather than instantiating a new object. Instead, I  
> recommend a Configurable interface which _may_ mark classes as  
> configurable as needed.

But most of the components have at least one entry class, that is  
configurable.

I see another problem, but maybe it's just the example implementation.  
In a couple of components the options can't or shouldn't be changed  
after the constructor. The components just get more complicated if we  
don't let them initialize to a defined state, just to make them more  
configurable. Therefore not all components will have setOptions() and  
setXXX() methods, but they may take an object or array for their  
parameters in the constructor.

nico
--Apple-Mail-9-578397287
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Kevin McArthur wrote:</div><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">1 ) Unified constructor. <b>All</b> constructors will (optionally)
accept an array of options or Zend_Config object as the first argument.<br>
<br>
I take exception to this because, well, it's just going to kill
performance -- and it doesn't follow industry standard techniques for
this type of thing. This shouldn't be a rule as a ton of classes have
no reason to be configurable, or make a lot more sense to take real
parameters, rather than instantiating a new object. Instead, I
recommend a <b>Configurable interface</b> which _may_ mark classes as
configurable as needed. <br>
</div>

</blockquote><br></div><div>But most of the components have at least one entry class, that is configurable.</div><div><br></div><div>I see another problem, but maybe it's just the example implementation. In a couple of components the options can't or shouldn't be changed after the constructor. The components just get more complicated if we don't let them initialize to a defined state, just to make them more configurable. Therefore not all components will have setOptions() and setXXX() methods, but they may take an object or array for their parameters in the constructor.</div><div><br></div><div>nico</div></body></html>
--Apple-Mail-9-578397287--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 26 Jul 2009 23:22:06 +0200
From: till <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to 
	ZendX Proposal

Hey guys!

<snip>

Maybe maintenance could/should be handle more transparently. I mean, I
understand there are no author tags on the code, but there are not
even pages with who maintains a certain component etc.. Sometimes it's
obvious who does by the names you see on the issue tracker on issues.
But maybe a meta site with some contact info, a status
(maintained/not) and open issues in Jira would be nice (sorta like
pearweb-light).

At times it's also hard to get a patch into the framework. For
starters, even if you supply patches I've gotten the answer, "add it
to the issue tracker, and let's wait what the community says".  The
patches did not break BC, they improved the usage of the component,
etc.. I have my doubts that people will send in a CLA in order to vote
on an issue (people who have are on the issue tracker rarely do unless
you ping mailing lists and beg for votes ;-)).

Other issues never get resolved at all. Not to single out someone or a
particular component, but for example Zend_Gdata is in trouble (kinda)
if you judge it by the open issues/tasks in Jira (92 open), and that's
despite it's backed by Google/Zend? (If I read correctly.) I'm not
saying that it doesn't work, the contrary is the case, but there are
also a lot of open issues.

Personally, I also find it hard to judge the "state" of code with the
lack of versioning of the each package. E.g. even if a component made
it into trunk, it says little about code quality/stability and
acceptance. It just means that you can't break BC until a new major
release. That's really it.

No offense meant, just stating what I think.

Till

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 08:23:41 -0800 (PST)
From: Diego Henrique Oliveira <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

--0-638511119-1264436621=:86405
Content-Type: text/plain; charset=us-ascii

In the adapter DbTable, the generated query to the database is a 'select *', and as it was being a bottleneck in my application (users table with many fields), i made these changes in the component Zend_Auth_Adapter_DbTable.

class Zend_Auth_Adapter_DbTable
{
    
    protected $_returnedFields;
    
    public function setReturnedFields( array $fields )
    {
        $this->_returnedFields = $fields;
    }
    
    public function getReturnedFields()
    {
        if (is_null($this->_returnedFields))
        {
            return array('*');
        }
        return $this->_returnedFields;
    }
    
    /**
     * _authenticateCreateSelect() - This method creates a Zend_Db_Select object that
     * is completely configured to be queried against the database.
     *
     * @return Zend_Db_Select
     */
    protected function _authenticateCreateSelect()
    {
        // build credential expression
        if (empty($this->_credentialTreatment) || (strpos($this->_credentialTreatment, '?') === false)) {
            $this->_credentialTreatment = '?';
        }

        $credentialExpression = new Zend_Db_Expr(
            '(CASE WHEN ' .
            $this->_zendDb->quoteInto(
                $this->_zendDb->quoteIdentifier($this->_credentialColumn, true)
                . ' = ' . $this->_credentialTreatment, $this->_credential
                )
            . ' THEN 1 ELSE 0 END) AS '
            . $this->_zendDb->quoteIdentifier(
                $this->_zendDb->foldCase('zend_auth_credential_match')
                )
            );

        // get select
        $fields   = $this->getReturnedFields();
        array_push( $fields, $credentialExpression );
        $dbSelect = clone $this->getDbSelect();
        $dbSelect->from($this->_tableName, $fields)
                 ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . ' = ?', $this->_identity);

        return $dbSelect;
    }
    
}

What you guys think about these changes? And should I submit them to the project?

Cheers

Diego 
http://diegoholiveira.com

--0-638511119-1264436621=:86405
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:verdana,helvetica,sans-serif;font-size:10pt;color:#000000;"><div>In the adapter DbTable, the generated query to the database is a 'select *', and as it was being a bottleneck in my application (users table with many fields), i made these changes in the component Zend_Auth_Adapter_DbTable.<br><br><br><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">class Zend_Auth_Adapter_DbTable</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">{</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; </span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold;
 font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; protected $_returnedFields;</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; </span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; public function setReturnedFields( array $fields )</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; {</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier
 New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; $this-&gt;_returnedFields = $fields;</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; }</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; </span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; public function getReturnedFields()</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier
 New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; {</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (is_null($this-&gt;_returnedFields))</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return array('*');</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight:
 bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return $this-&gt;_returnedFields;</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; }</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; </span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;
 /**</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp; * _authenticateCreateSelect() - This method creates a Zend_Db_Select object that</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp; * is completely configured to be queried against the database.</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp; *</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp; * @return Zend_Db_Select</span><br style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp; */</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; protected function _authenticateCreateSelect()</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; {</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // build credential expression</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (empty($this-&gt;_credentialTreatment) || (strpos($this-&gt;_credentialTreatment, '?') === false)) {</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;_credentialTreatment = '?';</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $credentialExpression = new
 Zend_Db_Expr(</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '(CASE WHEN ' .</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;_zendDb-&gt;quoteInto(</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_credentialColumn, true)</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; . ' = ' . $this-&gt;_credentialTreatment, $this-&gt;_credential</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; . ' THEN 1 ELSE 0 END) AS '</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .
 $this-&gt;_zendDb-&gt;quoteIdentifier(</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;_zendDb-&gt;foldCase('zend_auth_credential_match')</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; );</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><br style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // get select</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">$fields&nbsp;&nbsp; = $this-&gt;getReturnedFields();</span><br style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; array_push( $fields, $credentialExpression );</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $dbSelect = clone $this-&gt;getDbSelect();</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-weight: bold; font-family: Courier New,courier,monaco,monospace,sans-serif;">$dbSelect-&gt;from($this-&gt;_tableName, $fields)</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;where($this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_identityColumn, true) . ' = ?', $this-&gt;_identity);</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><br style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return $dbSelect;</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; }</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">&nbsp;&nbsp;&nbsp; </span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">}</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><br><br><br>What you guys think about these changes? And should I submit them to the project?<br><br><br>Cheers<br><br>Diego <br><span><a target="_blank"
 href="http://diegoholiveira.com">http://diegoholiveira.com</a></span><br></div>
<!-- cg5.c2.mail.ac4.yahoo.com compressed Fri Jan 22 08:31:24 PST 2010 -->
</div><br>

      </body></html>
--0-638511119-1264436621=:86405--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 17:22:43 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

-- Renan de Lima <[email-masked]> wrote
(on Friday, 26 February 2010, 06:46 PM -0300):
> About package dependencies...
> I think it could be nice if we should prepare it for 2 (or more)
> levels of dependency (or relashionship):
>     1 - strong, some package that does not work without other
> (example: Zend\Soap and Zend\Server)
>     2 - weak, when the dependency is just a suggestion (example:
> Zend\Auth and Zend\Db)
>=20
> For end-users we could provide a download picker as well, like this:
> http://phpjs.org/packages/configure

Actually, the above will be addressed by creating PEAR packages, as we
can then specify optional dependencies, or create bundles.

We do plan to offer a PEAR channel with per-component downloads for 2.0,
as this will make cherry-picking easier, and also provide an easier path
for integrating with other frameworks (the symfony CLI tool, for
instance, can install 3rd party code by proxying to PEAR, and this is
just one such example).

> On 26 February 2010 10:59, Matthew Weier O'Phinney <[email-masked]> w=
rote:
> > Hey, all --
> >
> > This is the first in a series of emails I'll be posting to this list
> > with status updates on 2.0. I plan to do these several times a week
> > throughout the process.
> >
> > Since branching 2.0 a couple days ago, I've been busy working on
> > stripping require_once calls from the ZF library.
> >
> > My initial idea was to simply run the same find/sed script from the
> > performance guide, but quickly discarded this for two reasons:
> >
> > =A0* It only comments out those lines. Yes, it can be modified to rem=
ove
> > =A0 the lines as well, but this does not address other concerns such =
as
> > =A0 preceding docblocks.
> >
> > =A0* To package individual components, we need some way to determine
> > =A0 dependencies. Currently, require_once statements can help with th=
at,
> > =A0 but stripping them makes this harder. My solution is to add @uses
> > =A0 annotations at the class docblock level. This assists the API doc=
s,
> > =A0 but also should make it possible to use automated scanners to
> > =A0 determine dependencies.
> >
> > To accomodate these concerns, the process has to be manual. I've
> > currently completed the top-level classes, and all components through
> > Zend_Config. I'm committing to a local git branch incrementally, and
> > will be pushing a squashed commit to the development-2.0 branch once
> > complete.
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> > Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
>=20
> --
> Renan de Lima Barbosa
> gtalk/msn: [email-masked]
> skype: renandelima
> +55 61 8166-7755
> renandelima.com
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Oct 2009 14:31:53 -0700
From: Trevor Johns <[email-masked]>
To: till <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Code Review

On Mon, Oct 12, 2009 at 1:38 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> I think pre-commit would be a bit unwieldy and introduce too much
> overhead and complexity to the project.

On the project's I've worked on that use pre-commit reviews, I've
found it to be relatively painless.

It does add a bit of delay when submitting new patches, but it can be
done asynchronously (code, upload patch and ask somebody to review it,
work on something else while waiting on the review).

With post-commit, it's easy to forget to have code reviewed, and it's
more difficult to ensure that the comments from the review actually
get applied. It's also not really friendly to developers without a
commit bit, since there's a high overhead to getting any new patch
committed.

Also, if code is only reviewed before merging into a release branch,
anything that's targeted for a major/minor release (and therefore is
never merged) won't get reviewed. This is outside the original scope
of this discussion, but it's probably good to have major changes like
these reviewed too.

> The other issue I had with Crucible had to do with how comments were
> relayed to the reviewees and peer reviewers: After each comment was
> entered, an email was sent.

I forgot about that. That's also incredibly annoying. :)

On Mon, Oct 12, 2009 at 1:48 PM, till <[email-masked]> wrote:
> I remember looking at both and I decided against Rietveld because it's
> AppEngine-based and the other is (was?) for GIT-powered projects. I
> ended up baking a couple greasemonkey scripts for code review from a
> trac install.

Yes, unfortunately both of them do have some issues that would need to
be addressed before using them with ZF.

The problem with Rietveld is not that it runs on App Engine per se,
but rather that App Engine enforces a request timeout. I've run into
cases where uploading very large patches can cause it to hit this
timeout. :(

And yes, Gerrit is Git only. Not sure what it would take to migrate
it. I personally love Git and wish we used it instead of SVN, but
that's a topic for another thread. ;)

-- 
Trevor Johns

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 9 Mar 2010 11:48:32 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 8 Mar 2010

--00163641780b45b61004815becfa
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 9, 2010 at 12:04 AM, Ben Scholzen 'DASPRiD' <[email-masked]>wrote:

> Matthew Weier O'Phinney wrote on 08.03.2010 22:41:
> >     # from tests/ directory
> >     % phpunit --group Zend_Acl .
>
> Why not just do phpunit --filter Zend_Acl instead? That makes the @group
> stuff obsolete.
>

You can even do:
$ phpunit Zend/Acl

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--00163641780b45b61004815becfa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Mar 9, 2010 at 12:04 AM, Ben Scholzen &#=
39;DASPRiD&#39; <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">m=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8=
ex; padding-left: 1ex;">

Matthew Weier O&#39;Phinney wrote on 08.03.2010 22:41:<br>
<div class=3D"im">&gt; =A0 =A0 # from tests/ directory<br>
&gt; =A0 =A0 % phpunit --group Zend_Acl .<br>
<br>
</div>Why not just do phpunit --filter Zend_Acl instead? That makes the @gr=
oup<br>
stuff obsolete.<br></blockquote><div><br>You can even do:<br>$ phpunit Zend=
/Acl<br></div></div><br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web=
 Engineer<br><a href=3D"http://giorgiosironi.blogspot.com">http://giorgiosi=
roni.blogspot.com</a><br>
<a href=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgiosiro=
ni</a><br>

--00163641780b45b61004815becfa--

nFrom nobody Wed Apr  7 08:46:09 2010
Date: Mon, 23 Nov 2009 13:18:06 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Subject: Re: [zf-contributors] ZF 1.9.6 sanity check tarballs ready
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>

--0-1152979957-1259011086=:86738
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Not sure if builds have caught up yet or something - the links aren't activ=
e right now.=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura=
.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Re=
presentative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Matt=
hew Weier O'Phinney <[email-masked]>=0ATo: [email-masked]=
=0ASent: Mon, November 23, 2009 8:52:56 PM=0ASubject: [zf-contributors] ZF =
1.9.6 sanity check tarballs ready=0A=0AGreetings!=0A=0AThanks everyone for =
participating in the Bug Hunt Days last week! Many=0Aof the fruits of your =
labors will be released this week, with ZF 1.9.6.=0A=0AI've prepared some s=
anity check tarballs:=0A=0A* Full packages:=0A  http://framework.zend.com/r=
eleases/ZendFramework-1.9.6/ZendFramework-1.9.6.tar.gz=0A  http://framework=
.zend.com/releases/ZendFramework-1.9.6/ZendFramework-1.9.6.zip=0A=0A* Minim=
al packages:=0A  http://framework.zend.com/releases/ZendFramework-1.9.6/Zen=
dFramework-1.9.6-minimal.tar.gz=0A  http://framework.zend.com/releases/Zend=
Framework-1.9.6/ZendFramework-1.9.6-minimal.zip=0A=0AAt this time, we plan =
to release late tomorrow (Tuesday) or early=0AWednesday (EST).=0A=0APlease =
test and let me know ASAP if you discover any show stoppers. =0A=0AThanks!=
=0A=0A-- =0AMatthew Weier O'Phinney=0AProject Lead            | matthew@zen=
d.com=0AZend Framework          | http://framework.zend.com/=0A
--0-1152979957-1259011086=:86738
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Not sure if builds have caught up yet or something - the links=
 aren't active right now.<br><br>Paddy<br><div>&nbsp;</div><span style=3D"c=
olor: rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new york=
,times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brad=
y<br><br></span></font><span style=3D"font-style: italic;"><font style=3D"f=
ont-family: times new roman,new york,times,serif;" size=3D"3"><a rel=3D"nof=
ollow" target=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blog.=
astrumfutura.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http:=
//www.survivethedeepend.com">http://www.survivethedeepend.com</a><br><a rel=
=3D"nofollow" target=3D"_blank" href=3D"http://www.openideurope.eu/">OpenID=
 Europe Foundation Irish Representative</a><br></font></span></span><div><b=
r></div><div
 style=3D"font-family: times new roman,new york,times,serif; font-size: 12p=
t;"><br><div style=3D"font-family: tahoma,new york,times,serif; font-size: =
8pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"fon=
t-weight: bold;">From:</span></b> Matthew Weier O'Phinney &lt;matthew@zend.=
com&gt;<br><b><span style=3D"font-weight: bold;">To:</span></b> zf-contribu=
[email-masked]<br><b><span style=3D"font-weight: bold;">Sent:</span></=
b> Mon, November 23, 2009 8:52:56 PM<br><b><span style=3D"font-weight: bold=
;">Subject:</span></b> [zf-contributors] ZF 1.9.6 sanity check tarballs rea=
dy<br></font><br>=0AGreetings!<br><br>Thanks everyone for participating in =
the Bug Hunt Days last week! Many<br>of the fruits of your labors will be r=
eleased this week, with ZF 1.9.6.<br><br>I've prepared some sanity check ta=
rballs:<br><br> * Full packages:<br><span>&nbsp;  <a target=3D"_blank" href=
=3D"http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramework-1.=
9.6.tar.gz">http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFram=
ework-1.9.6.tar.gz</a></span><br><span>&nbsp;  <a target=3D"_blank" href=3D=
"http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramework-1.9.6=
.zip">http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramework-=
1.9.6.zip</a></span><br><br> * Minimal packages:<br><span>&nbsp;  <a target=
=3D"_blank" href=3D"http://framework.zend.com/releases/ZendFramework-1.9.6/=
ZendFramework-1.9.6-minimal.tar.gz">http://framework.zend.com/releases/Zend=
Framework-1.9.6/ZendFramework-1.9.6-minimal.tar.gz</a></span><br><span>&nbs=
p;  <a target=3D"_blank"
 href=3D"http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramewo=
rk-1.9.6-minimal.zip">http://framework.zend.com/releases/ZendFramework-1.9.=
6/ZendFramework-1.9.6-minimal.zip</a></span><br><br>At this time, we plan t=
o release late tomorrow (Tuesday) or early<br>Wednesday (EST).<br><br>Pleas=
e test and let me know ASAP if you discover any show stoppers. <br><br>Than=
ks!<br><br>-- <br>Matthew Weier O'Phinney<br>Project Lead&nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; | <a ymailto=3D"mailto:[email-masked]" href=3D"ma=
ilto:[email-masked]">[email-masked]</a><br><span>Zend Framework&nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; | <a target=3D"_blank" href=3D"http://framework.=
zend.com/">http://framework.zend.com/</a></span><br></div></div>=0A<!-- cg1=
.c902.mail.ac4.yahoo.com compressed/chunked Mon Nov 23 13:15:37 PST 2009 --=
>=0A</div></body></html>
--0-1152979957-1259011086=:86738--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 7 Apr 2009 21:03:27 +0300
From: Vadim Gabriel <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] New Component proposal

--0016e6d32a1beda85a0466fad401
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hey,

I have never added a new proposal and searched the wiki about how to make
those. I found this "Image" that displays the work flow of adding a new
component, From opening a new proposal in the wiki upto getting it approved
by the Zend Team.
I have a few problems tough.

First i have lost my password, And now i can't access JIRA. I already signed
the CLA, And would have reset my password, I just couldn't find the lost
password feature anywhere. Do i need to ask someone to reset it for me?
Second, Where and how do i start a new Wiki page about the component i would
like to contribute. Do i need to add anything special like special
information about it, Besides the usual description and technical
specifications?
Third, My component that i would like to share is Zend_Payments_Paypal class
that allows to use paypal. This is the only thing i made so far by myself
for Zend Framework but since i am working a lot with Ecommerce i will
probably be writting more payment transfer options such as Google checkout,
Moneybookers, 2checkout and more. I would like to know if this is something
that might interest people and actually make it's way to the library rather
then the archive?

Thanks, Vince.

-- 
Vincent Gabriel.
Lead Developer, Senior Support.
Zend Certified Engineer.
Zend Framework Certified Engineer.

--0016e6d32a1beda85a0466fad401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey,<br><br>I have never added a new proposal and searched=
 the wiki about how to make those. I found this &quot;Image&quot; that disp=
lays the work flow of adding a new component, From opening a new proposal i=
n the wiki upto getting it approved by the Zend Team. <br>
I have a few problems tough. <br><br>First i have lost my password, And now=
 i can&#39;t access JIRA. I already signed the CLA, And would have reset my=
 password, I just couldn&#39;t find the lost password feature anywhere. Do =
i need to ask someone to reset it for me?<br>
Second, Where and how do i start a new Wiki page about the component i woul=
d like to contribute. Do i need to add anything special like special inform=
ation about it, Besides the usual description and technical specifications?=
<br>
Third, My component that i would like to share is Zend_Payments_Paypal clas=
s that allows to use paypal. This is the only thing i made so far by myself=
 for Zend Framework but since i am working a lot with Ecommerce i will prob=
ably be writting more payment transfer options such as Google checkout, Mon=
eybookers, 2checkout and more. I would like to know if this is something th=
at might interest people and actually make it&#39;s way to the library rath=
er then the archive?<br>
<br>Thanks, Vince.<br clear=3D"all"><br>-- <br>Vincent Gabriel.<br>Lead Dev=
eloper, Senior Support.<br>Zend Certified Engineer.<br>Zend Framework Certi=
fied Engineer.<br><br><br><br><br>
</div>

--0016e6d32a1beda85a0466fad401--

nFrom nobody Wed Apr  7 08:46:09 2010
From: Jon Whitcraft <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions
Date: Fri, 10 Apr 2009 15:11:19 -0400
Cc: "[email-masked]" <[email-masked]>

Matthew,

If I understand you correctly I could rename  
Zend_Service_Amazon_Abstract to Zend_Service_Amazon_Awsobject and have  
the ec2 and s3 classes extend it?

Jon Whitcraft

On Apr 10, 2009, at 2:24 PM, Matthew Weier O'Phinney  
<[email-masked]> wrote:

> Greetings, all --
>
> Below is a proposal I am making to modify the Zend Framework Coding
> Standards conventions for the naming of Interfaces and Abstract  
> classes.
>
> This decision is basically already made, but I'd appreciate any  
> feedback
> that you may have on the matter.
>
> Thanks!
>
> The problem
> ===========
> PHP 5.3 introduces namespaces to the PHP language. While this won't  
> have an
> impact much on userland code, it will have an impact on library and  
> framework
> code, as it provides a useful paradigm for organizing components as  
> well as
> simplifying syntax. Instead of having to say things like:
>
>    $analyzer = new  
> Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
>
> we can instead do something like this:
>
>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>
>    $analyzer = new Common_TextNum();
>
> or even:
>
>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>
>    class Common_TextNum extends Common
>    {
>    }
>
> The problem that arises for Zend Framework has to do with how we  
> name abstract
> classes and interfaces. Currently, the final segment of such classes  
> are
> expected to end with _Abstract and _Interface, respectively. This  
> will not work
> when we migrate to utilize namespaces, for two reasons.
>
> First, and most obviously, 'abstract' and 'interface' are reserved  
> PHP keywords.
> As such, in situations such as the following:
>
>    namespace Zend\Controller\Request;
>
>    class Abstract
>    {
>    }
>
>    // or:
>
>    namespace Zend\Controller\Dispatcher;
>
>    interface Interface
>    {
>    }
>
> we'll run into issues.
>
> Second, and less obvious, is that perhaps the easiest solution  
> breaks one of the
> key principles of namespaces (which are designed to help encapsulate
> components). This one's harder to explain, so let's look at  
> examples. Consider a
> component such as Zend_Controller_Request. The simplest solution  
> would be to
> name the abstract class or interface Zend\Controller\Request, and  
> then have the
> various concrete implementations under that namespace:
>
>    namespace Zend\Controller;
>
>    interface Request
>    {
>    }
>
>    // and concrete ones:
>
>    namespace Zend\Controller\Request;
>
>    class Http
>    {
>    }
>
> What's the problem here? The interface is not in the same namespace  
> as the
> concrete implementations.
>
> Potential solutions and recommendation
> ======================================
> So, how should Zend Framework "solve" these issues? A number of  
> proposals and
> recommendations have been floated around, both within ZF circles and  
> in the
> greater PHP community.
>
> Considerations include:
>
> * Avoiding the use of PHP reserved keywords (already noted).
> * Avoiding Hungarian Notation (i.e., having the name or a portion of  
> the name
>   describe its type -- which, to a degree, the current naming  
> conventions
>   already violate). (See http://en.wikipedia.org/wiki/Hungarian_Notation 
> , the
>   sections "Disadvantages of Systems Hungarian" and "Notable  
> Opinions" for some
>   of the arguments against using Hungarian Notation.)
>
> Approaches that have been considered include:
>
> * Using 'I' to prefix interfaces. This derives from standards in other
>   programming languages (.Net and python, in particular). This is  
> just another
>   form of Hungarian Notation, however.
>
> * Using "Interface" or "Abstract" as a class name suffix:  
> RequestInterface,
>   RequestAbstract. Again, however this is Hungarian Notation.
>
> * Using the term "Base" for abstract classes: BaseRequest,  
> RequestBase, Base.
>   This is just substituting the word Base for Abstract, however, and  
> is really
>   not much different than the above.
>
> * Use generic, descriptive names indicative of functionality or  
> behavior. As
>   examples from the SPL, "Countable", "Iterator", "ArrayObject".
>
> My recommendation is to use the latter, as it solves all  
> considerations. It will
> take more thought when naming, but will ensure that components can  
> live in a
> self-contained namespace, do not use reserved keywords, and avoid  
> Hungarian
> Notation.
>
> Plan for implementation
> =======================
> I recommend that the Coding Standards documentation be updated to  
> reflect this
> approach.
>
> All new components going into 1.8 and onwards should adopt these  
> standards. In
> releases 1.9 and forward, we will begin migrating existing  
> interfaces/abstract
> classe. First, new classes/interfaces will be created that follow  
> these
> conventions and which extend the originals; later, any type-hinting  
> based on the
> original class/interface names will be updated to point to the new  
> names; and
> finally, in 2.0, we will remove the old interfaces/abstract classes  
> entirely.
>
> -- 
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 15:58:20 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Poll: Interfaces/Abstract class naming conventions

Hey, all --

I know this has been hashed out a fair bit already, and we've already
established some guidelines, but as I play with code for ZF2, I'm
beginning to question the naming conventions for Interfaces and Abstract
Classes.

When we made the decisions before, we were looking at the following
three options for interfaces:

 1. Prefix interfaces with "I" ("IFoobar"). 
 2. Suffix interfaces with "Interface" ("FoobarInterface")
 3. Use adjective/noun names such as "Foobarable", "Foobarist"

For abstract classes, we looked at:

 4. Prefix abstract classes with "A" ("AFoobar")
 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
 6. Prefix abstract classes with "Base" ("BaseFoobar")
 7. Suffix abstract classes with "Base" ("FoobarBase")
 8. Use normal class names ("Foobar")

Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
they smack of Hungarian Notation, the long forms lead to really long
names, etc. Prefixing can lead to similar classes not being grouped when
doing directory listings (i.e., all abstract class or interface files
get clustered together). Also, for classes beginning with "I" or "A",
there can potentially be confusion over whether or not the given class
is supposed to be concrete. Finally, during refactoring, if you choose
to make an interface an abstract class or concrete class, or an abstract
class an interface or concrete class, you can't do so without renaming
files and classes. (That said, you'll most likely need to make other
changes anyways -- and ZF will likely never make an interface an
abstract class or vice versa.)

Regarding 3 and 8, the primary problems are that it's often hard to come
up with meaningful names that do not conflict with concrete
implementations, and that for non-native English speakers, this latter
problem becomes an even bigger obstacle. Additionally, you can't
determine which files contain abstract classes and/or interfaces just by
the filename -- you have to look in the file or look in API
documentation to determine this information. 

Now, as to the issues I've seen: the word "Interface" becomes a real
pain to type (yes, even with autocompletion), and it doesn't really
connote any real information. When type-hinting, I simply know what type
I want to use -- the name doesn't need to tell me it's an interface, as
I already know that information. If I'm writing code that consumes or
interacts with the class, API docs will tell me what I need to do.

That said, I don't use Abstract classes that often, but considering they
are a foundation on which to build concrete classes (presumably to take
care of many of the nitty gritty details and leave the concrete classes
to implement specifics), I don't mind using a class suffix. "Abstract"
feels like Hungarian notation, though.

Based on my experiences writing code, I'm currently recommending that we
do the following:

 3. Use adjective/noun names for Interfaces such as "Foobarable",
    "Foobarist"
 7. Suffix abstract classes with "Base" ("FoobarableBase")

The above solve most issues - names are reasonably sized, don't smack of
Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
most importantly, meaningful. Since we already implement code review for
any code coming into trunk, I think we can even solve the issues for
non-native speakers as well.

Thoughts? Votes?

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 8 Dec 2009 00:37:45 +0000
From: David Caunt <[email-masked]>
To: Simon R Jones <[email-masked]>
Cc: Juozas <[email-masked]>, 
	"Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend Framework modularity and application 
	structure

--00151747b74a5aa8a8047a2cc8a9
Content-Type: text/plain; charset=UTF-8

Hi All,

Background: I've been using ZF since a 0.2 or so release, and have followed
it's development to the present day. I think progress towards modular
applications, particularly when Zend_Application is used to its full
potential is fantastic.

We build CMS based websites for small to medium clients, in what I'm sure is
similar to how Simon Jones and many others use the framework. While our
sites are bespoke, we're clearly keen to build a flexible, solid based upon
which to add value. In the past we've used separate modules for admin
functionality (and even separate ACLs/Auth) and I'm now convinced that the
most simple approach is the best. In re-architecting our core CMS, with
Zend_Application in mind, my goal is for self contained modules which
contain both public and admin actions (or controllers). An acl will then
restrict access, and a plugin or action helper will manage layout and admin
navigation options.

The issue that this approach brings is the one that Padraic and others have
raised. Holistically, there's no way to automatically register to my admin
area (navigation helper or other) that I've installed a module, and that it
has a method to present admin navigation links or similar. Indeed, I haven't
yet seen a good event driven architecture within ZF for installation of
plugins (ala Wordpress or other), modules (in the Zend Framework sense) or
other. In addition, relationships between modules are difficult to manage at
this time. It's far too early in my research to suggest whether dependency
injection or some kind of plugin architecure, or something else is the best
way to proceed.

You may find that I write back in a week or two if I have any good ideas.
Zend Application is a great start, but there are more components needed,
whether configurator is the right name or not :) Auto-discovery and
communication between modules is necessary and valuable, and a difficult
task for Juozas to think about.

Let me know your thoughts

David

2009/12/7 Simon R Jones <[email-masked]>

> hi Juozas,
>
> my first post to this mailing list, but this topic is something I've been
> thinking a lot about recently in an effort to streamline our internal
> development at Studio 24.
>
> At present we install ZF either in the doc root, or a sub-folder, depending
> on whether we need to mix the ZF app with an existing system. Simple
> projects will just have one modules folder for default + admin, and possibly
> some custom module folders if the project needs to be split up. This is
> probably the most common ZF deployment model.
>
> Recently we have a requirement to organise things better and install
> re-usable code from project to project. But re-usable code we can customise
> for each project, without messing with the original module itself.
>
> The first step this took was admin modules, which map to /admin/module-name
> type URLs. This is achieved with two module folders, one called 'modules'
> (normal ZF use) and one called 'admin-modules'.
>
> Sample URLs may be:
>
> Admin dashboard - http://www.example.com/admin/ - maps to
> app/admin-modules/default/
> User management - http://www.example.com/admin/user/  - maps to
> app/admin-modules/user/
> CMS - http://www.example.com/admin/cms/ - maps to app/admin-modules/cms/
>
> This is technically achieved by a new Zend_Application resource which sets
> up routes and autoloading. This helps create a more consistent experience
> for the user and have one admin system to manage multiple systems.
>
> The second requirement we have is to have re-usable modules that we can
> install for a client, customise, and ideally upgrade in the future if we
> have a bug patch. The classic use case being user management.
>
> To do this we have a library/modules/ folder. This has sub-folders which
> basically contain a full MVC app with the normal ZF folder structure. I.e.
> for user management this has library/modules/user
>
> When used for a client site we SVN external the library/modules folders and
> treat this codebase as non-changeable (so we can update it in the future if
> we wished to). We then have some Zend_Application code which sorts out the
> autoloading and simply extend a few skeleton controllers in the normal
> app/modules/ folders to actually hook into the library module functionality.
>
> So app/modules/user/controllers/LoginController.php will extend
> library/Modules/User/application/default/controllers/Login.php
>
> We also have a view helper which looks in the library/modules folder first
> for views, then can be overridden by the local app/modules folder.
>
> This idea of organised admin modules/URLs and extendable library modules is
> one we've struggled a little with recently but is very important to a web
> agency like us who develop a lot of common stuff for clients - and need to
> customise it on a project-by-project basis. Zend Framework has been good for
> us in many ways, it's just sometimes difficult working out the best way to
> achieve this kind of re-usable module setup.
>
> I've been planning to write a blog post on this topic for a while, to get
> feedback from the community and see if anyone thinks this is an insane/good
> approach! I'd welcome any comments and would be happy to give any more
> feedback that may assist in ZF 2.0
>
> best wishes,
> Simon
>
> -------------------------------------------------------------------
>  Simon R Jones
>  Managing Director
>  Studio 24 Ltd
>  e  [email-masked]
>  t  0870 241 6159
>  w  www.studio24.net
>
>

-- 
Save Water...Drink Ouzo !

--00151747b74a5aa8a8047a2cc8a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi All,<div><br></div><div>Background: I&#39;ve been using ZF since a 0.2 o=
r so release, and have followed it&#39;s development to the present day. I =
think progress towards modular applications, particularly when Zend_Applica=
tion is used to its full potential is fantastic.</div>
<div><br></div><div>We build CMS based websites for small to medium clients=
, in what I&#39;m sure is similar to how Simon Jones and many others use th=
e framework. While our sites are bespoke, we&#39;re clearly keen to build a=
 flexible, solid based upon which to add value. In the past we&#39;ve used =
separate modules for admin functionality (and even separate ACLs/Auth) and =
I&#39;m now convinced that the most simple approach is the best. In re-arch=
itecting our core CMS, with Zend_Application in mind, my goal is for self c=
ontained modules which contain both public and admin actions (or controller=
s). An acl will then restrict access, and a plugin or action helper will ma=
nage layout and admin navigation options.</div>
<div><br></div><div>The issue that this approach brings is the one that Pad=
raic and others have raised. Holistically, there&#39;s no way to automatica=
lly register to my admin area (navigation helper or other) that I&#39;ve in=
stalled a module, and that it has a method to present admin navigation link=
s or similar. Indeed, I haven&#39;t yet seen a good event driven architectu=
re within ZF for installation of plugins (ala Wordpress or other), modules =
(in the Zend Framework sense) or other. In addition, relationships between =
modules are difficult to manage at this time. It&#39;s far too early in my =
research to suggest whether dependency injection or some kind of plugin arc=
hitecure, or something else is the best way to proceed.</div>
<div><br></div><div>You may find that I write back in a week or two if I ha=
ve any good ideas. Zend Application is a great start, but there are more co=
mponents needed, whether configurator is the right name or not :) Auto-disc=
overy and communication between modules is necessary and valuable, and a di=
fficult task for Juozas to think about.</div>
<div><br></div><div>Let me know your thoughts</div><div><br></div><div>Davi=
d</div><div><br></div><div><br></div><div><br><div class=3D"gmail_quote">20=
09/12/7 Simon R Jones <span dir=3D"ltr">&lt;<a href=3D"mailto:simon.jones@s=
tudio24.net">[email-masked]</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">hi Juozas,<br>
<br>
my first post to this mailing list, but this topic is something I&#39;ve be=
en thinking a lot about recently in an effort to streamline our internal de=
velopment at Studio 24.<br>
<br>
At present we install ZF either in the doc root, or a sub-folder, depending=
 on whether we need to mix the ZF app with an existing system. Simple proje=
cts will just have one modules folder for default + admin, and possibly som=
e custom module folders if the project needs to be split up. This is probab=
ly the most common ZF deployment model.<br>

<br>
Recently we have a requirement to organise things better and install re-usa=
ble code from project to project. But re-usable code we can customise for e=
ach project, without messing with the original module itself.<br>
<br>
The first step this took was admin modules, which map to /admin/module-name=
 type URLs. This is achieved with two module folders, one called &#39;modul=
es&#39; (normal ZF use) and one called &#39;admin-modules&#39;.<br>
<br>
Sample URLs may be:<br>
<br>
Admin dashboard - <a href=3D"http://www.example.com/admin/" target=3D"_blan=
k">http://www.example.com/admin/</a> - maps to app/admin-modules/default/<b=
r>
User management - <a href=3D"http://www.example.com/admin/user/" target=3D"=
_blank">http://www.example.com/admin/user/</a> =C2=A0- maps to app/admin-mo=
dules/user/<br>
CMS - <a href=3D"http://www.example.com/admin/cms/" target=3D"_blank">http:=
//www.example.com/admin/cms/</a> - maps to app/admin-modules/cms/<br>
<br>
This is technically achieved by a new Zend_Application resource which sets =
up routes and autoloading. This helps create a more consistent experience f=
or the user and have one admin system to manage multiple systems.<br>
<br>
The second requirement we have is to have re-usable modules that we can ins=
tall for a client, customise, and ideally upgrade in the future if we have =
a bug patch. The classic use case being user management.<br>
<br>
To do this we have a library/modules/ folder. This has sub-folders which ba=
sically contain a full MVC app with the normal ZF folder structure. I.e. fo=
r user management this has library/modules/user<br>
<br>
When used for a client site we SVN external the library/modules folders and=
 treat this codebase as non-changeable (so we can update it in the future i=
f we wished to). We then have some Zend_Application code which sorts out th=
e autoloading and simply extend a few skeleton controllers in the normal ap=
p/modules/ folders to actually hook into the library module functionality.<=
br>

<br>
So app/modules/user/controllers/LoginController.php will extend library/Mod=
ules/User/application/default/controllers/Login.php<br>
<br>
We also have a view helper which looks in the library/modules folder first =
for views, then can be overridden by the local app/modules folder.<br>
<br>
This idea of organised admin modules/URLs and extendable library modules is=
 one we&#39;ve struggled a little with recently but is very important to a =
web agency like us who develop a lot of common stuff for clients - and need=
 to customise it on a project-by-project basis. Zend Framework has been goo=
d for us in many ways, it&#39;s just sometimes difficult working out the be=
st way to achieve this kind of re-usable module setup.<br>

<br>
I&#39;ve been planning to write a blog post on this topic for a while, to g=
et feedback from the community and see if anyone thinks this is an insane/g=
ood approach! I&#39;d welcome any comments and would be happy to give any m=
ore feedback that may assist in ZF 2.0<br>

<br>
best wishes,<br>
Simon<br>
<br>
-------------------------------------------------------------------<br><fon=
t color=3D"#888888">
=C2=A0Simon R Jones<br>
=C2=A0Managing Director<br>
=C2=A0Studio 24 Ltd<br>
=C2=A0e =C2=A0<a href=3D"mailto:[email-masked]" target=3D"_blank"=
>[email-masked]</a><br>
=C2=A0t =C2=A00870 241 6159<br>
=C2=A0w =C2=A0<a href=3D"http://www.studio24.net" target=3D"_blank">www.stu=
dio24.net</a><br>
<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water...Dri=
nk Ouzo !<br>
</div>

--00151747b74a5aa8a8047a2cc8a9--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 19 Mar 2009 00:05:02 -0600
From: "A.J. Brown" <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Proper place to report incubator issues/requests?

--002215046c8bb073e504657294a8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hey guys,

I have some requests I want to file for a component currently in the
standard incubator (specifically Zend_Queue).  Where's the place to do so?

-- 
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

--002215046c8bb073e504657294a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey guys,<br><br>I have some requests I want to file for a component curren=
tly in the standard incubator (specifically Zend_Queue).=A0 Where&#39;s the=
 place to do so?<br clear=3D"all"><br>-- <br>A.J. Brown<br>web | <a href=3D=
"http://ajbrown.org">http://ajbrown.org</a><br>
phone | (937) 660-3969<br>

--002215046c8bb073e504657294a8--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Alexey Simonenko <[email-masked]>
To: [email-masked]
Date: Sat, 4 Apr 2009 00:14:05 +0400
Subject: [zf-contributors] What status of Zend_Db_Table_Plugin?

Hello,

Zend_Db_Table_Plugin code is in incubator long time ago. What's status =20=

of this code?

--
Best wishes, Alexey Simonenko
Chief developer, =ABSerenity Ltd=BB
Office phone: (812) 448-55-12
Mobile phone: (812) 923-95-74
ICQ: 424662283
http://serenity.su

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 12:53:16 -0600
From: Luke Crouch <[email-masked]>
To: till <[email-masked]>
Cc: Giorgio Sironi <[email-masked]>, 
	zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

I'll make a parting note and then leave the git discussion so it
doesn't overwhelm other more relevant things like Doctrine.

I would probably be happier with git for ZF since ZF is much looser in
organization and has many independent contributors. If we do git,
let's be sure to set some workflow guidelines though as I would hate
to waste a bunch of overhead (mine and MWO's) with the branching.

-L

On Thu, Feb 25, 2010 at 12:30 PM, till <[email-masked]> wrote:
> On Thu, Feb 25, 2010 at 6:37 PM, Giorgio Sironi
> <[email-masked]> wrote:
>> On Thu, Feb 25, 2010 at 5:44 PM, Luke Crouch <[email-masked]> wrote:
>>>
>>> Maybe I'm turning into a crotchety old programmer, but I'm not really
>>> impressed with git. We switched from svn to git at my day job and I
>>> haven't really seen any big benefits aside from a few sweet syntactic
>>> shortcuts like git stash. For larger projects with well-organized
>>> branching I just haven't seen much additional value from git.
>>
>> I'm also starting out with git. The point is in having the possibility to
>> branch at every moment of development, and to use those branches to merge
>> changes that would break the trunk. With distributed version control branch
>> is very cheap and people working on unstable components will be happier.
>>
>
> +1
>
> @Luke
>
> If you're not convinced, I urge you to check in something like Magento
> into subversion and then into git. =) The pure performance is reason
> enough to switch. That, and the "almost-anything-merger". :)
>
> Till
>

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 5 Dec 2009 13:09:27 +0100
From: =?UTF-8?B?Sm/DsyDDgWTDoW0=?= <[email-masked]>
To: Juozas <[email-masked]>
Cc: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend Framework modularity and application 
	structure

I use the recommended directory structure, with additional directories
if needed, e.g. /application/plugins/. Would be nice to have a place
for action helpers too, and some way to automatically apply them.

Recently I tried to use modules, but it turned out to be pain for me,
so now I really like the approach to group related controllers (and
therefore views) in folders. This way in small and medium sized sites
I mostly have all my controllers under /application/controllers/ (for
the frontend) and administrative backend under
/application/controllers/Admin/.

=C3=81d=C3=A1m

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 07 Dec 2009 10:18:23 -0600
From: Ralph Schindler <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

Hi all,

I'd like to reiterate a few of the points Matthew is making... inline:

> A few things. First, strip_tags and ZF's StripTags should _not_ be
> equated with XSS protection. The fact that people do indicates to me a
> documentation and education problem, not necessarily a bona-fide

There is no security silver-bullet.  There are only security best 
practices, and education from the ongoing battle between application 
developers and application attackers.

StripTags is only one 1/2 of the "Filter Input, Escape Output" mantra of 
application security.  I could further argue that it is less than half 
of the equation in that if you decide to permit comments and certain 
attributes, then you should further expect to have to *do more* to 
assure that the thing you do decide to allow are safe.

> I do want to clarify something: the issue reported earlier this year was
> not so much about filtering XSS attacks, but about the fact that due to how
> attributes were matched, it _introduced_ an XSS attack vector. Because
> the regex did not take into account newlines, it was possible to break
> an attribute value onto multiple lines to prevent it being matched --
> which provided the attack vector, as attributes not in the whitelist
> would be retained in the final filtered tag. 

An XSS attack vector is actually a side effect of the real problem.  The 
real problem is that attributes that not on the whitelist were not being 
stripped.  That was the root problem, and as such- we fixed that.  The 
side effect is that since multiline attributes could be passed through 
without being on the white-list, XSS too (or any data for that matter), 
would be emitted.

> I do see your point regarding the "setCommentsAllowed" functionality; it
> is, quite simply, a bad idea, as there is no semantic or structural
> value to keeping comments; sure, you could use them for conditional
> output, but that's a system ripe for abuse. I'm not entirely sure why
> this functionality was added in the first place, and agree with you that
> it should be removed.

Before ripping it out, we need to identify what the original use case 
was.  XSS is generally a problem with applications that live in the 
public domain.

** There is a significant number of applications that scratch an itch 
NOT in the public domain (enterprise software, intranet systems, and so 
on.)  There might be people in private or protected environments that 
rely on this feature.  Also note, this is an opt in feature, not on by 
default.

> May I suggest the following:
> 
>  * ZF-8483 and ZF-8484 should be resolved ASAP
> 
>  * As part of ZF-8484, which calls for better documenting the use cases
>    for StripTags, include a <warning> section clearly stating that it is
>    not intended for XSS prevention
> 
>  * Create an HtmlPurifier filter that proxies to PEAR's HTML_Purifier
>    package; this would be included in an upcoming release.

I really like this idea.

>  * Remove the setCommentsAllowed() functionality (by having it throw an
>    exception indicating the security vulnerabilities it opens)

As noted: lets be careful about removing features.

> Finally, a request: in the future, when reporting suspected security
> vulnerabilities, it's customary to notify the project _privately_ and
> allow some time for the project to address the vulnerability before
> making it public. As it is, you've created a very large, public
> discussion that will make the project seem (a) reactionary, instead of
> proactive, and (b) paint us as completely non-security minded. This is
> particularly bad in this situation, as, unless there's more to report,
> the primary issue here is one of documentation and education, not actual
> vulnerabilities in the code (with the exception of setCommentsAllowed()
> -- which isn't a vulnerability per-se, but an ill-guided idea from the
> outset).

Cheers,
Ralph

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 26 Oct 2009 12:45:46 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code Freeze for 1.9.5 LIFTED

Code freeze for 1.9.5 is now lifted; 1.9.5 has been tagged.

While packages are still building and uploading, you can start testing
now by retrieving or exporting the tag:

    http://framework.zend.com/svn/framework/standard/tags/release-1.9.5

Let me know ASAP if you run into any issues during testing of your
applications.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 29 Jan 2010 15:53:07 +0100
From: Giorgio Sironi <[email-masked]>
To: Andy Fowler <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] ZF-8938

--0016e6d77ed31fed35047e4ecb20
Content-Type: text/plain; charset=ISO-8859-1

I think we should expect feedback from the core developers in order to
discover if numerical names are officially supported.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d77ed31fed35047e4ecb20
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think we should expect feedback from the core developers in order to disc=
over if numerical names are officially supported.<br clear=3D"all"><br>-- <=
br>Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br><a href=3D"http=
://giorgiosironi.blogspot.com">http://giorgiosironi.blogspot.com</a><br>
<a href=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgiosiro=
ni</a><br>

--0016e6d77ed31fed35047e4ecb20--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 13:56:05 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

-- Pieter Kokx <[email-masked]> wrote
(on Wednesday, 31 March 2010, 05:43 PM +0200):
> Matthew Weier O'Phinney schreef:
>     -- Andy Fowler <[email-masked]> wrote
>     (on Monday, 22 March 2010, 11:38 AM -0400):
>         A quick note on "atomic commits" in git. One of the things I had to
>         learn when moving to Git was to get away from huge end-of-feature
>         commits, like one would make in SVN. Eventually, it becomes easier to
>         commit, revert, commit, revert many times during the course of a
>         feature. At the end of the feature branch you can squash those many
>         commits into a single atomic commit that contains all unit tests and
>         docs:
> 
> 
>     Yes, but that's exactly what I was getting at. If we do library/ and
>     tests/ and documentation/ all as submodules, we can't have that final
>     atomic commit that has the tests and docs and code all together. :)
> 
> 
> Well, actually you can. By making a commit to the super repository that
> includes the new commits to the submodules, you have that atomic commit that
> combines tests, code and docs.

Then you need to show me how to do it; I have yet to determine how this
would be achieved.

As an example, I did the following:

 * Created a repository for the library, which contains a single folder,
   Zend
 * Created a repository for the tests, which contains the unit test
   artifacts (phpunit.xml, Bootstrap.php, TestConfiguration.php.dist)
   and the Zend folder with all unit tests.
 * Created a "super" repository that uses git submodules to bring in the
   library and tests repositories.
 * Added a unit test, and code in the library to satisfy the unit test.

And this is where the problem occurs. To achieve the fix, you need to:

 * Commit the test
 * Commit the code
 * Update the submodules in the super repository
 * Commit the updated submodule definitions to the super repository

This is a hellacious process to go through for what is essentially a
single commit. I see it as a barrier to contribution.

If you can show that it can be done in a simpler fashion, I'm all ears.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: Andy Thompson <[email-masked]>
Date: Tue, 16 Mar 2010 07:53:06 +0000
From: Andy Thompson <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

Hi,

Suffixing the class name with its intent seems like the best way in my 
opinion. In my own libraries, I've been frustrated with the way I might 
have 3 or 4 of the same filenames open e.g. Field\DateTime.php, 
Filter\DateTime.php, Validate\DateTime.php and Element\DateTime.php 
(though that last one I've now renamed to DateTimeSelect).

In my IDE, and I'm sure a lot of others do this, this shows just the 
filename DateTime.php. I've already started using suffixes in my PHP 5.3 
code.

Also this frees us to not have to define our own whole Filter namespace 
when a package is just not designed to supply filters.

Regards

Andy

On 16/03/2010 06:31, Ralph Schindler wrote:
> Hey all-
>
> One more to discuss for today ;)
>
>
>
> On the Usage of Compound Names --
>
> With namespaces, we have the opportunity to create aliases to specific 
> namespace our code consumes.  For example, we can do something like this:
>
>
> <?php
> // in a script that consumes Zend Frameowrk
> use Zend\Filter as f;
>
> $filter = new f\Something.php
>
> ?>
>
>
> In the past, with fully prefixed names, it was easy to understand the 
> context of a particular class since the namespace is carried with it. 
> $filter = new Zend_Filter_Int(); is clearly an Integer filter, and the 
> class name fully reflects that.
>
> The question with namespaces is, should we use compound names to 
> identify classes separate of the namespace itself.  This can be better 
> demonstrated with the following code:
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\Int();
>
> ?>
>
>
> -- VS --
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\IntFilter();
>
> ?>
>
>
> In the latter example, the original class name (without the prefix) 
> might have been Int, but this class name has been 'suffixed' with a 
> term that gives the class name more meaning.  (In english, this means 
> that the class name now has the adjective 'Int' and the noun 'Filter', 
> or a noun-noun combination).
>
> Which is a better route to explore in your opinion? Which has more 
> meaning to you as a developer consuming ZF?
>
> As a technical side-note, this might be required for some prefixed 
> names that reduce down into PHP reserved words, for example 
> Zend_CodeGenerator_Php_Class cannot become namespace 
> Zend\CodeGenerator\PHP class Class due to its restrictions on class 
> naming.
>
> Thoughts?
> -ralph

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Simone Carletti <[email-masked]>
Date: Mon, 22 Mar 2010 13:46:43 +0100
To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

--00163649a3390470750482631842
Content-Type: text/plain; charset=ISO-8859-1

Hello Matthew,

I don't know the details about how you are going to manage the git push/pull
task from a local machine to a git server, however I suggest you to have a
look at the following document.
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

It describes how gitosis works and, AFAIK, it roughly resemble to the
current GitHub and Gitorious system.
Basically, you have one unique unix user which handles all the communication
from the local machine to the master repository.
All users pull and push changes using this user. Internally the system
checks the public ssh key of the committer agains a whitelist which is
stored itself in a Git repos.

In your case, the whitelist can be the list of all users which signed the
CLA and are allowed to send commits to the repository.

I hope this can help you,
-- Simone

On Mon, Mar 22, 2010 at 1:36 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

>  If you have any ideas on handling ACLs, I'd love to
> hear them, and sooner rather than later!
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

-- 
Simone Carletti

Site & Blog: http://www.simonecarletti.com
Email: [email-masked]
LinkedIn: http://linkedin.com/in/weppos
Nick: weppos | Skype: weppos

--00163649a3390470750482631842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello=A0Matthew,<div><br></div><div>I don&#39;t know the details about how =
you are going to manage the git push/pull task from a local machine to a gi=
t server, however I suggest you to have a look at the following document.</=
div>

<div><a href=3D"http://scie.nti.st/2007/11/14/hosting-git-repositories-the-=
easy-and-secure-way">http://scie.nti.st/2007/11/14/hosting-git-repositories=
-the-easy-and-secure-way</a></div><div><br></div><div>It describes how gito=
sis works and, AFAIK, it=A0roughly=A0resemble to the current GitHub and Git=
orious system.</div>

<div>Basically, you have one unique unix user which handles all the communi=
cation from the local machine to the master repository.</div><div>All users=
 pull and push changes using this user. Internally the system checks the pu=
blic ssh key of the committer agains a whitelist which is stored itself in =
a Git repos.</div>

<div><br></div><div>In your case, the whitelist can be the list of all user=
s which signed the CLA and are allowed to send commits to the repository.</=
div><div><br></div><div>I hope this can help you,</div><div>-- Simone</div>

<div><br></div><div><div><div><br><div class=3D"gmail_quote">On Mon, Mar 22=
, 2010 at 1:36 PM, Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex;">

=A0If you have any ideas on handling ACLs, I&#39;d love to<br>
hear them, and sooner rather than later!<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Simone Carletti<=
br><br>Site &amp; Blog: <a href=3D"http://www.simonecarletti.com">http://ww=
w.simonecarletti.com</a><br>Email: <a href=3D"mailto:[email-masked]">wep=
[email-masked]</a><br>

LinkedIn: <a href=3D"http://linkedin.com/in/weppos">http://linkedin.com/in/=
weppos</a><br>Nick: weppos | Skype: weppos<br>
</div></div></div>

--00163649a3390470750482631842--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 10:10:06 -0800
From: Matthew Ratzloff <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--0016361e893c5d0943048070b179
Content-Type: text/plain; charset=UTF-8

I don't think it would be beneficial to include Doctrine 1.x support in Zend
Framework 1.x for this reason.  There is no real "upgrade" path from version
1 to 2; they are very different.  It also divides contributors' limited
time, and the idea that you'll be working hard on something that will
quickly be deprecated is not very motivating.

-Matt

On Thu, Feb 25, 2010 at 8:46 AM, Giorgio Sironi <
[email-masked]> wrote:

> On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]>wrote:
>
>> I like the idea (as David Caunt mentioned) of releasing a 1.X branch with
>> Doctrine 1 to test the waters and judging by the amount of work required
>> decide to go with Doc2+ZF2 when the time comes.
>>
>
> Beware that Doctrine 1 and Doctrine 2 are very different: the fomer is
> ActiveRecord-based while the latter on the UnitOfWork pattern. Their
> metadata management is not the same and 2.x is a complete rewrite of 1.x.
>
> Regards,
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>

--0016361e893c5d0943048070b179
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don&#39;t think it would be beneficial to include Doctrine 1.x support in=
 Zend Framework 1.x for this reason. =C2=A0There is no real &quot;upgrade&q=
uot; path from version 1 to 2; they are very different. =C2=A0It also divid=
es contributors&#39; limited time, and the idea that you&#39;ll be working =
hard on something that will quickly be deprecated is not very motivating.<d=
iv>
<br></div><div>-Matt<br><br><div class=3D"gmail_quote">On Thu, Feb 25, 2010=
 at 8:46 AM, Giorgio Sironi <span dir=3D"ltr">&lt;<a href=3D"mailto:piccolo=
[email-masked]">[email-masked]</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"gmail_quote"><div class=3D"gm=
ail_quote"><div class=3D"im"><div>On Thu, Feb 25, 2010 at 5:24 PM, Anthony =
Shireman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" targe=
t=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>

</div></div><div class=3D"im"><div><blockquote class=3D"gmail_quote" style=
=3D"border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;paddi=
ng-left:1ex">
I like the idea (as David Caunt mentioned) of releasing a 1.X branch with D=
octrine 1 to test the waters and judging by the amount of work required dec=
ide to go with Doc2+ZF2 when the time comes.<br clear=3D"all"></blockquote>

</div></div><div><br>Beware that Doctrine 1 and Doctrine 2 are very differe=
nt: the fomer is ActiveRecord-based while the latter on the UnitOfWork patt=
ern. Their metadata management is not the same and 2.x is a complete rewrit=
e of 1.x.<br>

</div></div><div><div></div><br clear=3D"all"></div></div><div><div></div><=
div class=3D"h5">Regards,<br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp=
; Web Engineer<br><a href=3D"http://giorgiosironi.blogspot.com" target=3D"_=
blank">http://giorgiosironi.blogspot.com</a><br>
<a href=3D"http://twitter.com/giorgiosironi" target=3D"_blank">http://twitt=
er.com/giorgiosironi</a><br>

</div></div></blockquote></div><br></div>

--0016361e893c5d0943048070b179--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Wed, 23 Sep 2009 09:56:44 +0200
From: Benjamin Eberlei <[email-masked]>
Subject: [zf-contributors] Discussion about Quality/Review Process - Community
	RM proposal

Hello contributors,

regarding the Backwards-Compabilitiy or not change problem with the 1.9.3
release we had a fairly extensive discussion on IRC yesterday that I
would like to share with everyone who was not able to participate.

To explain the issue, the 1.9.3 release had a BC break by changing
how the Zend_Db::factory works. A Use-Case that was never described
in documentation but was valid according to the methods docblock
was changed.

Now we had such problems in previous releases also and they are bound
to happen again, however the question was how we could extend the quality
process to minimize the effect of such problems and detect them as soon
as possible.

Several approaches were proposed for example:
1. commit kudos system
2. review system
3. community release master

The third got the most attention. I'll shortly describe what was discusse=
d.
A trusted community member would be appointed Release Master by the
contributors
for each .y release of the x.y.z release cycle. An additional Zend employ=
ee
is appointed to help this release master out. A new RM would be chosen
whenever the previous .y.0 release is shipped so that he can begin
reviewing changes to the trunk/library/ for potential BC or other problem=
s,
i.e. non component maintainers committing new undiscussed features
into a component.

When the RMs branch is released as a new .y.0 release every merge from th=
e
trunk to his release branch has to be done by him, or at least been
approved
by him and otherwise gets reverted.

In practice there would always be two RMs at one point in time, one that
maintains the current release branch and one that prepares the next
release branch.

Time Frame for such a community involvment would therefore be about 6-12
month
depending on the release cycle.

I hope this discussion can continue here, so that we may even get some
results for the 1.10 release.

greetings,
Benjamin

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Carlton Gibson <[email-masked]>
Date: Tue, 15 Sep 2009 09:01:44 +0100
Cc: "Matthew Weier O'Phinney" <[email-masked]>,
	Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Announcement: Monthly Bug Hunt!

--Apple-Mail-1--183402807
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1;
	format=flowed;
	delsp=yes

On 14 Sep 2009, at 18:10, P=E1draic Brady wrote:

> * If you already have commit access, commit the test and fix to the
>   repository, and either resolve the issue or ask somebody from Zend =20=

> to
>   review and resolve.  Don't forget to merge your changes to the 1.9
>   release branch!

Just a few questions:

1) I'm a bit slow (as I've mentioned before) but, having committed =20
changes back to trunk, how exactly does one merge back into the =20
release branch?

2) The issue tracker has "Resolve" and "Close". Which should we use? =20
(There seem to be a lot of resolved issues that have never been closed.)

3) How much time do you Zend guys realistically have to review fixes? =20=

I like to have another human review all my code (especially in a _high =20=

profile_ project like this one :-) but if we're waiting ages for a =20
review on a fix we're confident with should we just resolve it? =20
(Should we just harass you? Is their a pool of willing reviewers? -- =20
everyone is busy right?)

Thanks,
Carlton=

--Apple-Mail-1--183402807
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 14 Sep 2009, at 18:10, P=E1draic Brady =
wrote:</div><br><blockquote type=3D"cite"><span class=3D"Apple-style-span"=
 style=3D"border-collapse: separate; font-family: Helvetica; font-size: =
medium; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" =
style=3D"font-family: tahoma, 'new york', times, serif; font-size: 11px; =
">* If you already have commit access, commit the test and fix to =
the<br>&nbsp; repository, and either resolve the issue or ask somebody =
from Zend to<br>&nbsp; review and resolve.&nbsp; Don't forget to merge =
your changes to the 1.9<br>&nbsp; release =
branch!<br></span></span></blockquote></div><div><br></div><div>Just a =
few questions:</div><br><div>1) I'm a bit slow (as I've mentioned =
before) but, having committed changes back to trunk, how exactly does =
one merge back into the release =
branch?&nbsp;</div><div><br></div><div>2) The issue tracker has =
"Resolve" and "Close". Which should we use? (There seem to be a lot of =
resolved issues that have never been =
closed.)</div><div><br></div><div>3) How much time do you Zend guys =
realistically have to review fixes? I like to have another human review =
all my code (especially in a _high profile_ project like this one :-) =
but if we're waiting ages for a review on a fix we're confident with =
should we just resolve it? (Should we just harass you? Is their a pool =
of willing reviewers? -- everyone is busy =
right?)&nbsp;</div><div><br></div><div>Thanks,</div><div>Carlton</div></bo=
dy></html>=

--Apple-Mail-1--183402807--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Mon, 8 Jun 2009 10:11:09 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.8.3 sanity check packages

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9E85C.34E4F913
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all!

=20

The sanity check packages for ZF 1.8.3 are now available here:

http://framework.zend.com/releases/preview/ZendFramework-1.8.3.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-apidoc.ta
r.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-apidoc.zi
p

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-de
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-de
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-en
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-en
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-fr
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-fr
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-ja
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-ja
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-ru
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-ru
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-zh
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.3-manual-zh
.zip

=20

=20

Note that this is *NOT* the official release of 1.8.3. If we find no
major issues with these builds, we will issue official 1.8.3 release
from this tag soon.=20

Please do *NOT* log any issues found in these archives in the issue
tracker; instead post any major functional or packaging issues to this
list or mail them to me directly ([email-masked]).

=20

=20

With best regards,

   Alexander Veremyev.

------_=_NextPart_001_01C9E85C.34E4F913
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@SimSun";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:2.0cm 69.6pt 2.0cm 69.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Hi all!</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>The sanity check packages for ZF 1.8.3 are =
now
available here:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3.ta=
r.gz">http://framework.zend.com/releases/preview/ZendFramework-1.8.3.tar.=
gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3.zi=
p">http://framework.zend.com/releases/preview/ZendFramework-1.8.3.zip</a>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ap=
idoc.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.3-apidoc.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ap=
idoc.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8.3-=
apidoc.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-de.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.3-manual-de.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-de.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.3-manual-de.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-en.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.3-manual-en.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-en.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.3-manual-en.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-fr.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.3-manual-fr.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-fr.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.3-manual-fr.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-ja.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.3-manual-ja.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-ja.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.3-manual-ja.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-ru.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.3-manual-ru.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-ru.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.3-manual-ru.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-zh.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.3-manual-zh.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.3-ma=
nual-zh.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.3-manual-zh.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Note that this is *NOT* the official release =
of 1.8.3.
If we find no major issues with these builds, we will issue official =
1.8.3
release from this tag soon. </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Please do *NOT* log any issues found in these =
archives
in the issue tracker; instead post any major functional or packaging =
issues to
this list or mail them to me directly =
([email-masked]).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>With best regards,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Alexander Veremyev.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9E85C.34E4F913--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 6 Oct 2009 14:34:25 +0200
From: Jonathan Maron <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] PDF, DOCX and DOC Generation with Zend Framework

Hello all

I have just posted an article about the soon to be released
Zend_Service_LiveDocx_* components.

http://www.phplivedocx.org/articles/pdf-generation-with-zend-framework/

The components are scheduled for ZF 1.10. For the time being, you can
check them out of the Standard Incubator (http://is.gd/40hXz).

Comments and critique are welcome.

Very best regards

Jonathan Maron

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 6 Feb 2010 03:47:33 +1100
From: Nigel Chapman <[email-masked]>
To: David Caunt <[email-masked]>
Cc: Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

Hi David,

To my mind Zend_Array is trying to do three things:

1. Put things into arrays,
2. Manipulate arrays of things,
3. Get things out of arrays.

All three are essential for useful data pipelining. Regarding your comments:

The 'take' functions (#1) are basically factory methods, which could
be generalized using the adapter pattern. But one of the aims of
Zend_Array is readability, so I think I'd still wrap the adapters in
takeWhatever($objects) methods to encourage clarity-at-a-glance. Zend
style for this might be Zend_Array::take('Xml', $objects), where 'Xml
' says to use Zend_Array_Adapter_Xml.

Having a terminator (#3) that sends the array through a specified
viewHelper could work well; but I still think the class should support
a set of common input/output types intrinsically; the convenience of a
few HTML functions is shown by the demo page itself.

-- Nigel.

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Wed, 8 Apr 2009 09:29:52 +0200
Subject: Re: [zf-contributors] New Component proposal

Vadim,

I would go for a adapter plugin.
This OOP approach is used very commonly through the complete framework.

So all base functions are defined in the base class and it handles how this 
calls are delegated to the set adapter.

And you only have to create one adapter per each provider 
(Zend_Payment_Adapter_Visa / Zend_Payment_Adapter_Mastercard / 
Zend_Payment_Adapter_PayPal and so on). Your use will still only have to 
handle only the base class without to know about the adapter details.

For example:
$pay = new Zend_Payment($myOptions);
$pay->checkPayment($data);
$pay->transferMoney();

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Vadim Gabriel" <[email-masked]>
To: "Ben Scholzen 'DASPRiD'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 08, 2009 7:30 AM
Subject: Re: [zf-contributors] New Component proposal

> Hey,
>
> Thanks, For the help with the password thing, I will email Matthew.
>
> About the component, I have no problem in writing a unified API, My full
> time job is building Ecommerce stores, So i have quite a log of code 
> already
> written that utilize all sort of payment providers, I could probably write
> down the ones i have worked with and completely sure that i will be able 
> to
> include them in the unifed API component. The thing is i don't know where 
> to
> start really, Where do i open a proposal? What do i need to write down in
> there?
>
> For the unified thing, I was thinking on creating a seperate class for 
> every
> payment provider, Like Zend_Payment_Paypal, Zend_Payment_2Checkout etc,
> Would that work? or does it have to be just one class and using a
> constructor method to initialize the required payment provider class? Such
> as
>
> $paypal = new Zend_Payment('paypal');
> $2checkout = new Zend_Payment('2checkout');
>
> I can do either, Which ever sounds better is fine with me.
>
> Thanks again for the help.
>
> Vince.
>
> On Tue, Apr 7, 2009 at 11:57 PM, Ben Scholzen 'DASPRiD' 
> <[email-masked]>wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> You may probably ask Matthew or Wil about the password thingy.
>>
>> Then, to your proposal:
>> There were some proposals for payment components, but mostly the just
>> included single payment methods, and did not cover multiple ones. We
>> discussed that a few times, and what we need is a component which offers
>> (if possible) a unified API for all payment providers. When you are
>> willing to do so, feel free to get on with your proposal, I will follow
>> it with interest.
>>
>> Regards,
>> Ben
>> ...................................
>> :  ___   _   ___ ___ ___ _ ___    :
>> : |   \ /_\ / __| _ \ _ (_)   \   :
>> : | |) / _ \\__ \  _/   / | |) |  :
>> : |___/_/:\_\___/_| |_|_\_|___/   :
>> :........:........................:
>> : Web    : http://www.dasprids.de :
>> : E-mail : [email-masked]       :
>> : Jabber : [email-masked]     :
>> : ICQ    : 105677955              :
>> :........:........................:
>>
>>
>> Vadim Gabriel schrieb:
>> > Hey,
>> >
>> > I have never added a new proposal and searched the wiki about how to
>> > make those. I found this "Image" that displays the work flow of adding 
>> > a
>> > new component, From opening a new proposal in the wiki upto getting it
>> > approved by the Zend Team.
>> > I have a few problems tough.
>> >
>> > First i have lost my password, And now i can't access JIRA. I already
>> > signed the CLA, And would have reset my password, I just couldn't find
>> > the lost password feature anywhere. Do i need to ask someone to reset 
>> > it
>> > for me?
>> > Second, Where and how do i start a new Wiki page about the component i
>> > would like to contribute. Do i need to add anything special like 
>> > special
>> > information about it, Besides the usual description and technical
>> > specifications?
>> > Third, My component that i would like to share is Zend_Payments_Paypal
>> > class that allows to use paypal. This is the only thing i made so far 
>> > by
>> > myself for Zend Framework but since i am working a lot with Ecommerce i
>> > will probably be writting more payment transfer options such as Google
>> > checkout, Moneybookers, 2checkout and more. I would like to know if 
>> > this
>> > is something that might interest people and actually make it's way to
>> > the library rather then the archive?
>> >
>> > Thanks, Vince.
>> >
>> > --
>> > Vincent Gabriel.
>> > Lead Developer, Senior Support.
>> > Zend Certified Engineer.
>> > Zend Framework Certified Engineer.
>> >
>> >
>> >
>> >
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAknbvj4ACgkQ0HfT5Ws789AIsQCffrVw9VETkPXTCgn/i9yD9XHh
>> FwoAnRZ2/VyJngOvolSD2Vg7ww7OLgLe
>> =Qkwd
>> -----END PGP SIGNATURE-----
>>
>
>
>
> -- 
> Vincent Gabriel.
> Lead Developer, Senior Support.
> Zend Certified Engineer.
> Zend Framework Certified Engineer.
> 

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 20:51:52 +0100
From: Carlos Medina <[email-masked]>
Reply-To: [email-masked]
Organization: SimplyNetworks
To: Kevin McArthur <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

1.- Unified constructor. *All* ...

Yes Kevin Agree that. Instead of Configurable Interface, you can add an 
Object of Zend_Config, if you need to configure some thing.

2 ) Exception interfacing
Absolutlely

4) Getting rid of singletons.

Well yes. I agree that. I think that the ZF should be easy and simple to 
use. At this moment i think that ZF pretend to be a big Framework for 
all and at the end will be used only for two or tree developer.

Carlos

Kevin McArthur schrieb:
> I guess I'll chime in, and stir the pot a bit. All IMHO of course....
>
> The good:
>
> Namespaces, Creation of components for general-purpose 
> cross-functional actions, Usage of new language features within plugin 
> architectures, Autoload-only.
>
> The Bad:
>
> 1 ) Unified constructor. *All* constructors will (optionally) accept 
> an array of options or Zend_Config object as the first argument.
>
> I take exception to this because, well, it's just going to kill 
> performance -- and it doesn't follow industry standard techniques for 
> this type of thing. This shouldn't be a rule as a ton of classes have 
> no reason to be configurable, or make a lot more sense to take real 
> parameters, rather than instantiating a new object. Instead, I 
> recommend a *Configurable interface* which _may_ mark classes as 
> configurable as needed.
>
> 2 ) Exception interfacing
>
> Why mess with it? All the SPL exceptions descend from Exception and 
> can be caught/thrown as any normal exception can be. Exceptions should 
> continue to contain the Exception class inheritance hierarchy.
>
> From the markup:
>
> try {    throw new InvalidArgumentException(); } catch 
> (\Foo\Bar\Exception $e) { }
>
> Can just be:
>
> try {    throw new InvalidArgumentException(); } catch (Exception $e) { }
>
> Without the marker interface. I must be missing something?
>
> 3) Design By Contract
>
> I'm actually a big fan of contract programming, but, a framework must 
> be fast -- and optimized. Contract programming is great as part of 
> business process management, but it has serious runtime performance 
> implications -- and worse, increases contribution overhead. Makes 
> testing, acceptance testing easier, sure. But this could be realllllly 
> limiting.
>
> 4) Getting rid of singletons.
>
> Why does it make more sense to access the front controller via a 
> registry? Surely this can't meet the 80/20 rule? Keep the singletons, 
> they make it easier to pick up the framework.
>
> The Ugly:
>
> The proposed changes to the core api (and to a large extent the 
> framework additions since 1.0) really add complexity to the framework 
> to the benefit of testing and other 'advanced' use. These changes do 
> little, if anything to advance three goals I see as core requirements 
> for 2.0:
>
> a) Can a skilled PHP developer read and understand Zend Framework 
> application code without more than an hour's primer on ZFW? Could they 
> trace execution of the framework logically without a debugger? Jumps 
> like GOTO's, fancy routers, registries, helpers, plugins, and DI 
> models all work against this goal. Keep it simple.
>
> b) Can a skilled PHP developer contribute a change to the framework 
> easily without being involved in the ZFW core politics, contribution 
> processes, proposal processes, test writing, doc writing, etc. 
> Currently, ZFW sucks for this, but didn't until after the 1.0 line was 
> out. What will ZFW 2.0 do to reduce the contribution overhead and 
> encourage community participation?
>
> c) Can a ZFW developer create products and services that leverage ZFW 
> in an ecosystem of components? Is there a financial incentive for 
> this? Currently, there's very little going on in terms of 
> commercialized redistributable components -- How will ZFW 2.0 create, 
> and integrate itself into a marketplace for ZFW apps, components, and 
> tools? Official ZFW app/component store? ZFW cloud services?
>
> The Atrocious:
>
> Still nothing about an upgrading / security patches system. Still no 
> components for detecting if an application is vulnerable, notifying 
> system admins, or shutting down an installed base of vulnerable apps 
> dependent on the framework. If the problems of the other major 
> framework and cms vendors continue to be ignored, there will almost 
> certainly be some sort of incident that will tarnish the frameworks 
> reputation for security. At some point the framework is going to have 
> to take version management more seriously than publishing patches to 
> the website (a good first step, but miles away from where it needs to 
> be).
>
> -- 
>
> I'd also add that there's probably an opportunity to look at 
> phar-ization within the 2.0 line. Will the new loader support phar'd 
> components, and how will that look? Zend_Tool? Configurable site images?
>
> I'm sure theres more, but thats my $0.02 for now
>
> Kevin McArthur
>
>
> Matthew Weier O'Phinney wrote:
>> Hey, all --
>>
>> There have been a ton of questions about the ZF 2.0 roadmap, and my
>> answer has been consistently, "I'm working on it; I'll have something to
>> publish soon."
>>
>> "Soon" is now:
>>
>>     
>> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>>
>> I'd like you, as contributors, to look over it, and start discussing the
>> various ramifications; we can do that either in comments to the pages or
>> on this list.
>>
>> The roadmap is primarily a conceptual one right now, though a
>> proof-of-concept has been created for the proposed MVC. I'd like to stay
>> fairly high-level for now, and then start getting a flow of proposals
>> into the system for specific migration-related tasks.
>>
>> Thanks everyone who has provided me input over the past many months, and
>> let's get started on the next generation of ZF!
>>
>>   
>
>

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Sun, 26 Jul 2009 15:31:24 +0200
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
	ZendX Proposal

Hello Jon and Contributors,

I know you are actively developing the S3 and EC2 components and my criticism 
of the Services explicitly excluded your components :-)

Refering to the Zend_Service_Amazon component i meant the Product Advertising 
API, which is out of date and under the current state won't work anymore by 
Mid August 2009.

Thus I have extended the component to support the new authentication mechanism 
and merged it back into the 1.9 release branch. I know this is technically a 
violation of the commit freeze and stuff, but i guess its more embarassing to 
release a non-working component than to violate "feature freeze".

greetings,
Benjamin

On Sunday 26 July 2009 02:32:51 pm Whitcraft, Jon wrote:
> Benjamin,
>
> I am not the maintainer for Zend_Service_Amazon but I do maintain the S3
> and Ec2 components and I would like to state that the Ec2 and S3 classes
> are using the latest API versions. I did finish up the twitter stuff I
> don't have time to maintain it as I'm busy with a full time job. I am still
> actively developing the Ec2 classes as my full time job requires using Ec2
> and S3 APIs.  If someone wants to take over the Twitter Service then by all
> means please do so, it does need some love.
>
> Jon Whitcraft
> Indianapolis Motor Speedway
> [email-masked]
> P: (317) 492-8623 - F: (317) 492-6419
>
>
>
> -----Original Message-----
> From: Benjamin Eberlei [mailto:[email-masked]]
> Sent: Sunday, July 26, 2009 5:36 AM
> To: [email-masked]
> Subject: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
> ZendX Proposal
>
> Hello Everyone,
>
> i took the time today to look at the Problem of Zend_Service_Amazon. Due to
> an API upgrade the ZF component won't work anymore come August 15th. I just
> saw that the component uses the API from 2005, so its hopelessly out of
> date. I'll look into a possible fix, but i can't guarantee for this to work
> with the 2005 API and i dont know how complex a migration to the latest
> 2009 API is.
>
> This out of date problem is the case with most of the other Service
> components besides Twitter, S3 and EC2. Their code-base is mostly crap and
> they are all unmaintained.
>
> I want to propose a change to ZFs handling of Service components. Since
> they all rely on third party API (through them having to rely on the
> stability of external webservices) they should all be moved into ZendX for
> 2.0. Also every new service component from now on should only be included
> in ZendX, with the exception of service integration being programmed from
> companies that have an agreement with Zend, such as the Infocard, Google
> and AMF components, where the stability and up-to-date API can be somewhat
> guaranteed.
>
> greetings,
> Benjamin
>
> --
> Benjamin Eberlei
> http://www.beberlei.de
>
>
> ********************
> ********************
> This E-mail (and attachments) may contain confidential/privileged
> information intended only for the named addressee(s). If you are not an
> intended recipient, do not read, copy, disseminate or take any action based
> on the content of this E-mail. Please notify the sender by reply E-mail and
> erase this E-mail from your system. Your assistance is appreciated. E-mail
> transmission may not be secure or error-free. The company is not
> responsible for any loss/damage arising from any virus transmitted.
> ********************
> ********************

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 15 Jan 2010 10:54:45 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.10 roadmap

Hey, all --

As announced on fw-announce, fw-general, Zend's Developer Zone, and
twitter, 1.10.0beta1 was released a couple hours ago.

Since we are in beta, that means that public APIs should no longer
change on the release-1.10 branch. Please do not introduce any
BC-breaking changes at this time, even if the component has not yet been
in a stable release.

If you are fixing issues in trunk, please be sure to merge them to the
release-1.10 branch as well, to ensure the fixes propagate to the final,
stable release.

Finally, THANK YOU to everyone who has contributed to the release so
far! It looks absolutely stellar!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 1 Apr 2010 11:43:40 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

-- Dolf Schimmel <[email-masked]> wrote
(on Thursday, 01 April 2010, 04:48 PM +0200):
> > Now, since the Symfony Live conference, I've also been thinking about
> > something Fabien said about Symfony 2: "less magic." To clarify, the
> > idea is to design components so that they are explicit about what the=
y
> > can do. As an example, instead of using __get() and __set(), using
> > explicit getters and setters; instead of using __call(), explicitly
> > defining methods; instead of having __call() proxy to helpers, having=
 a
> > broker from which you pull them as needed.
>=20
> Apparently the rumors on twitter were in place; the conference did
> have a bad influence on you :D

Umm... there are good ideas everywhere, and bad ones as well. Neither ZF
nor SF have a monopoloy on either.

> More seriously, I think this can in no way be compared with SF's
> "magic" (does the fact that our Zend_Magic only is imaginative mean ZF
> does at this moment not contain any magic?).

I wasn't trying to explicitly link the two. In fact, the examples I gave
were examples of applying Fabien's ideas to ZF.

> Firstly, if you have a class called foo\Filter which contains an
> __invoke() method,
> that method should obviously filter. As long as it does that and only
> that, there's no magic imho involved.=20

I can see this POV. For somebody who doesn't know what the interface's
purpose is, however, it's less clear. Let me point that out with your
next examples:

> Same goes for foo\Validator (its
> __invoke() method is supposed to validate), and foo\Bootstrap (guess
> what: __invoke() should bootstrap here).=20

Validator defines two method types: validation, and error message
retrieval. In the original interface, this is pretty clear: isValid()
and getMessages(). If we change to __invoke() and getMessages(), the
latter method is clear, but the former is not -- what exactly is
happening here?

Looking at the bootstrap, this is also a bit more unclear: right now, we
have a bootstrap() method and a run() method: which one does __invoke()
define? Resources might be a bit more clear: the init() method might
make sense to instead map to __invoke() -- but the intent is less clear.
init() at least implies that we're initializing something; what does
__invoke() do?

> If we can get it done consistently I'm pretty sure everybody will be
> used to it within the first 5 seconds they look at a random piece of
> code.

I *do* want to see consistency. I just don't want to sacrifice end-user
comprehension of the code. Our current usage of __call(), __get(), and
__set() throughout the framework *does* make the code less easy to
understand. I've had plenty of people indicate that they have had
trouble understanding view helpers because they can't find the methods
in the view object; I don't want the same thing happening with usage of
__invoke().

> Secondly Symfony's magic is on an entirely different scale of
> magnitude than the naming of one type of method.  Compare
> $random->method() generating an entire application for you with
> $object() which exactly does what the name of the object implies.

Please see my notes above. I wasn't talking about this type of magic.

> Situations in which you have two methods doing exactly the same are
> often/usually a result of willing to change, but also struggling with
> inability to do so due to backwards compatibility constraints.
> However, now that we're busy on something where potentially all BC may
> be broken, I really don't think having two methods doing exactly the
> same would be beneficial to anybody. In fact, it would increase the
> amount of options to do something with (give or take) N! which is an
> awful lot, without any added value.

This is the primary argument I can see against having both an explicit
method name defined and __invoke(), and it hits home with other
complaints about the current state of ZF: understanding how ZF is
difficult when there's more than one way to do things.

I want to be clear that the primary reason for using __invoke() in the
first place is for dynamic calls using call_user_func() and
call_user_func_array(). While using __invoke() with these is faster than
a traditional callback, it's still way slower than calling the method
directly -- around 3 times slower. __invoke() simply provides a slight
optimization in a pattern that we're likely to use many, many times
throughout a given request.

For single usage, though, would you rather do this:

    $value =3D $plugin($data);

    or:

    $value =3D $plugin->filter($data);

I realize it's a bit contrived -- you might name the object to better
describe its purpose. However, the latter more clearly explains what
you're doing to the data: you're filtering it. Let's look at a
validator:

    $test =3D $plugin($value);

    or:

    $test =3D $plugin->isValid($value);

I actually think this one benefits a ton -- even with a well-named
variable:

    $test =3D $validator($value);

What is "$validator"? and what is it doing here? When we call the
method, we know we're checking for validity; when we call it via
__invoke(), we could be filtering it, validating it, pushing in a
value... who knows?

In my earlier post, I probably should have made it more clear: I see
__invoke() as a way to more easily and efficiently define and execute
*callbacks*, and hence my rationale that it makes sense to define both
an explicit method as well as __invoke() for those class types that will
be used with filter chains and/or brokers.

> On Thu, Apr 1, 2010 at 3:07 PM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
> > I've been following this thread as well as discussions on IRC with
> > interest, as, honestly, I can completely buy into all arguments, whic=
h
> > are, to sum things up:
> >
> > =A0* Use only __invoke()
> > =A0* Use a method name specific to the interface
> > =A0* Use a standardized method name, such as "run" or "execute"
> > =A0* Use a combination of __invoke() and either a meaningful or
> > =A0 standardized method name.
> >
> > I got to thinking about why I suggested "__invoke()" in the first pla=
ce,
> > and went back to the plugin architecture page:
> >
> > =A0* http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectur=
es
> >
> > The original rationale was for using pubsub/filter chain systems. In
> > such systems, you attach callbacks:
> >
> > =A0 =A0$chain->attach($callback);
> >
> > If your objects implement __invoke(), $callback can simply be your
> > object -- you're done. Otherwise, you also have to provide the method=
:
> >
> > =A0 =A0$chain->attach($object, $method);
> >
> > Interestingly, in this document, I also recommended that for existing
> > interfaces, __invoke() be added as an _additional_ method, and that i=
t
> > should proxy to the appropriate interface method. In this case, we'd
> > simply be taking advantage of a language feature in places it makes
> > sense.
> >
> > Now, since the Symfony Live conference, I've also been thinking about
> > something Fabien said about Symfony 2: "less magic." To clarify, the
> > idea is to design components so that they are explicit about what the=
y
> > can do. As an example, instead of using __get() and __set(), using
> > explicit getters and setters; instead of using __call(), explicitly
> > defining methods; instead of having __call() proxy to helpers, having=
 a
> > broker from which you pull them as needed.
> >
> > This has several implications:
> >
> > =A0* Less need for explicit documentation. If you have behaviors rely=
ing
> > =A0 on the magic methods, developers *must* read the the documentatio=
n in
> > =A0 order to know how a class/component works. If everything is expli=
cit,
> > =A0 the class is self-documenting, and you can get the information yo=
u
> > =A0 need from API docs, your IDE, etc.
> >
> > =A0* Performance. Magic methods are reportedly less performant than u=
sing
> > =A0 straight method calls (more on this later).
> >
> > These are important factors, and the test-driven developer in me
> > particularly likes less magic; it's much easier to test when you have
> > explicit behaviors.
> >
> > That said, I decided to run some tests. These were the scenarios:
> >
> > =A0* No Proxying:
> > =A0 * Defined "filter" method returns value
> > =A0 * Defined "__call" method returns value
> > =A0 * Defined "__invoke" method returns value
> > =A0* Proxying:
> > =A0 * Defined "filter" method returns value
> > =A0 * Defined "__call" method proxies to "filter"
> > =A0 * Defined "__invoke" method proxies to "filter"
> > =A0* Inverse proxying
> > =A0 * Defined "filter" method calls invoke (as "$this();")
> > =A0 * Defined "__invoke" method returns value
> > =A0* call_user_func_array()
> > =A0 * Using array($obj, 'filter') callback
> > =A0 * Using __invoke() with no proxying
> > =A0 * Using __invoke() with proxying
> >
> > The results were quite interesting. Across the board, using __call() =
is
> > awful -- even if you simply return a value, it's on average 6x slower
> > than a straight method call; proxying to another method, however,
> > doesn't take significantly longer (so long as you're not using
> > call_user_func_array() internally, that is).
> >
> > __invoke(), however, turns out to be quite different. When not proxyi=
ng,
> > it's actually *faster* than a method call (about 25% on average).
> > Proxing __invoke() to a method call or doing the inverse are roughly =
the
> > same speed -- about 2.5x slower than a straight method call (which, a=
s
> > you'll note, is still over twice as fast as using __call()).
> >
> > What was *really* interesting, however, was using
> > call_user_func_array(), which is commonly used in filter chains and/o=
r
> > brokers. =A0__invoke(), with or without proxying, *always* was around=
 30%
> > *faster* than using an explicit array($obj, $method) callback.
> >
> > So, what does this tell me?
> >
> > =A0* AVOID using __call(), particularly for often-used method calls. =
For
> > =A0 helper systems, it will always be better to use a helper broker a=
nd
> > =A0 command pattern.
> >
> > =A0* For classes meant to be used primarily with filter chains or bro=
kers,
> > =A0 DO use __invoke(), even if it simply proxies to another interface
> > =A0 method.
> >
> > So, based on the design goals and the performance benchmarking, I'm
> > going to recommend that Filter and Validator (we renamed Validate to
> > Validator) define an __invoke() method in addition to a more explicit
> > interface method, and that helpers also follow this pattern.
> >
> > -- Matthew Weier O'Phinney <[email-masked]> wrote
> > (on Wednesday, 31 March 2010, 10:21 AM -0400):
> >> Greetings, all --
> >>
> >> Per the roadmap, one change we're planning on making is making plugi=
n
> >> usage consistent across components: plugins will implement __invoke(=
),
> >> which makes them inherently callable.
> >>
> >> In our refactoring branch, I've done this now with Zend_Filter. Howe=
ver,
> >> it required a ton of refactoring on the unit tests (had to either ca=
ll
> >> __invoke() directly, or $filter($value)), and it got me to thinking:
> >>
> >> Would it make sense to keep the original interfaces (filter, isValid=
,
> >> render, etc.), but also implement __invoke() -- having it proxy to t=
he
> >> appropriate interface method?
> >>
> >> As an example:
> >>
> >> =A0 =A0 interface Filter
> >> =A0 =A0 {
> >> =A0 =A0 =A0 =A0 public function filter($value);
> >> =A0 =A0 =A0 =A0 public function __invoke($value);
> >> =A0 =A0 }
> >>
> >> =A0 =A0 class Digits implements Filter
> >> =A0 =A0 {
> >> =A0 =A0 =A0 =A0 public function filter($value)
> >> =A0 =A0 =A0 =A0 {
> >> =A0 =A0 =A0 =A0 =A0 =A0 // ... logic...
> >> =A0 =A0 =A0 =A0 }
> >>
> >> =A0 =A0 =A0 =A0 public function __invoke($value)
> >> =A0 =A0 =A0 =A0 {
> >> =A0 =A0 =A0 =A0 =A0 =A0 return $this->filter($value);
> >> =A0 =A0 =A0 =A0 }
> >> =A0 =A0 }
> >>
> >> The benefits:
> >>
> >> =A0* Fewer changes necessary to existing unit tests
> >> =A0* interface method names may be more descriptive of intent
> >>
> >> Problems:
> >>
> >> =A0* Using __invoke() introduces overhead -- 2 method calls instead =
of one
> >> =A0* Redundancy (two methods doing the same thing)
> >> =A0* A few extra tests to write (to ensure __invoke works as expecte=
)
> >>
> >> After discussion with Ralph and Alex, I'm leaning towards having
> >> __invoke() as an _additional_ method, instead of replacing existing
> >> methods.
> >>
> >> Any thoughts or comments?
> >>
> >> --
> >> Matthew Weier O'Phinney
> >> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> >> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> >> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >>
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> > Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 15 Jan 2010 00:27:18 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] 1.10 has been branched!

Great :)

Can you add the new components of 1.10 on issue tracker and move the
incubator components to Zend Framework project please.

Greetings
Marc B.

Am 14.01.2010 22:55, schrieb Matthew Weier O'Phinney:
> Greetings, all!
>
> I've just created the official 1.10 branch, and will be tagging the beta
> off of this branch momentarily.
>
> >From this point forward, no API changes are allowed in the release-1.10
> branch -- but DO please assist in fixing bugs, translating, etc.!
>
> Thanks!
>
>   

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Thu, 27 Aug 2009 22:06:44 +0200
Subject: [zf-contributors] Discussions of the possible Query API in Zend_Entity

Hello everyone,

i am currently scratching my head on howto abstract the query API for different 
storages and often think about CouchDb which has a fundamently different Query 
concept than a RDBMS.

For clarification to the not so familiar, it the EntityManager is the sole 
public API to the user of Zend_Entity and its facilities. It manages the life-
cycle of domain objects.

Currently, it has the following API for queries:

EntityManager::load($entityClass, $id);
EntityManager::createNamedQuery($name);
EntityManager::createNativeQuery($input, $resultSetMapping);
EntityManager::createNativeQueryBuilder($entityClass=null);
EntityManager::createQuery($zql); // not implemented yet
EntityManager::createQueryBuilder(); // not implemented yet

This is very large and still very RDBMS specific interface. To break that up
I was thinking to go the following way, only have three methods:

EntityManager::load($entityClass, $id);
EntityManager::createNamedQuery($name);
EntityManager::createNativeQuery($input, $resultSetMapping);

And all the other Query related stuff is implemented and used explicitly by 
calling for example:

$sqlQueryBuilder = new Zend_Db_Mapper_SqlQueryBuilder($entityManager);
$queryBuilder = new Zend_Db_Mapper_QueryBuilder($entityManager);
$zqlQuery = new Zend_Db_Mapper_ZqlQuery($entityManager);

This way the API can be hinted explicitly in IDEs (since its often quite 
complex) and storage specific features can be implemented.

Now you ask yourself, how is this storage independent? It is via the 
"createNamedQuery()" method. This method internally uses the plugin loader to 
instantiate queries via the command pattern. In a storage independent 
database, all operations have to be build as named query and executed such. 
For each storage a corresponding implementation has to exist. I can't do more 
since even newer approaches like LINQ in .NET for example don't lend 
themselfes to CouchDb at all. I dont see a way to generate a better query API.

What are your thoughts on this issue? :-)

greetings,
Benjamin

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 16 Nov 2009 23:10:11 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0016e6d784e3fd7122047884455a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 12, 2009 at 10:41 PM, Kevin McArthur <[email-masked]> wrote:

>  4) Getting rid of singletons.
>
> Why does it make more sense to access the front controller via a registry?
> Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier
> to pick up the framework.
>
>
>  We're not accessing the front controller via a registry. It's simply not
> going to be a singleton. The ideas posted use injection to pass objects
> around, and do so in a very simple manner. Take a look at the
> proof-of-concept I posted before jumping to conclusions.
>
> Singletons have been the source of a ton of pain in testing and
> bugfixing -- and there's very little reason for most of them to exist.
>
>
>
>  I'm poking around in it, but I'm not sure I see how 'the' front controller
> will be accessed. Whats the equivilent call to
> Zend_Controller_Front::getInstance().... somewhere's gonna have to be a
> registry (or at least a responsible object) if thats not singleton-ized.
>
> I'm looking at
>
> http://github.com/weierophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php
> for example, and I definitely don't think this is easier to grasp than the
> singleton fc approach.
>

To argument on singletons and dependency injection, I put together a couple
of posts as an example on how automatic dependency injection can take care
of the construction process:
http://giorgiosironi.blogspot.com/2009/11/how-to-eliminate-singletons.html
http://giorgiosironi.blogspot.com/2009/11/how-to-eliminate-singletons-part-2.html
so that manual creation of objects in the bootstrap would not be required.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d784e3fd7122047884455a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Nov 12, 2009 at 10:41 PM, Kevin McArthur=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">kevin@stormtid=
e.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"bo=
rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding=
-left: 1ex;">
<div bgcolor=3D"#ffffff" text=3D"#000000">

 =20

<div class=3D"im"><blockquote type=3D"cite">
  <blockquote type=3D"cite">
    <pre>4) Getting rid of singletons.

Why does it make more sense to access the front controller via a registry?
Surely this can&#39;t meet the 80/20 rule? Keep the singletons, they make i=
t easier
to pick up the framework.
    </pre>
  </blockquote>
  <pre>We&#39;re not accessing the front controller via a registry. It&#39;=
s simply not
going to be a singleton. The ideas posted use injection to pass objects
around, and do so in a very simple manner. Take a look at the
proof-of-concept I posted before jumping to conclusions.

Singletons have been the source of a ton of pain in testing and
bugfixing -- and there&#39;s very little reason for most of them to exist.

  </pre>
</blockquote></div>
I&#39;m poking around in it, but I&#39;m not sure I see how &#39;the&#39; f=
ront
controller will be accessed. Whats the equivilent call to
Zend_Controller_Front::getInstance().... somewhere&#39;s gonna have to be a
registry (or at least a responsible object) if thats not singleton-ized.<br=
<br>
I&#39;m looking at <br>
<a href=3D"http://github.com/weierophinney/phly/blob/mvcfsm/Phly_Mvc/demo/a=
pplication/Bootstrap.php" target=3D"_blank">http://github.com/weierophinney=
/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php</a><br>
for example, and I definitely don&#39;t think this is easier to grasp than
the singleton fc approach.<br></div></blockquote><div><br>To argument on si=
ngletons and dependency injection, I put together a couple of posts as an e=
xample on how automatic dependency injection can take care of the construct=
ion process:<br>
<a href=3D"http://giorgiosironi.blogspot.com/2009/11/how-to-eliminate-singl=
etons.html">http://giorgiosironi.blogspot.com/2009/11/how-to-eliminate-sing=
letons.html</a><br><a href=3D"http://giorgiosironi.blogspot.com/2009/11/how=
-to-eliminate-singletons-part-2.html">http://giorgiosironi.blogspot.com/200=
9/11/how-to-eliminate-singletons-part-2.html</a><br>
so that manual creation of objects in the bootstrap would not be required.<=
br></div></div><br clear=3D"all"><br>-- <br>Giorgio Sironi<br>Piccolo Princ=
ipe &amp; Web Engineer<br><a href=3D"http://giorgiosironi.blogspot.com">htt=
p://giorgiosironi.blogspot.com</a><br>
<a href=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgiosiro=
ni</a><br>

--0016e6d784e3fd7122047884455a--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: David Caunt <[email-masked]>
Date: Fri, 26 Feb 2010 13:49:04 +0000
To: Julien Pauli <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--00151747b64ad0c9ce0480812a42
Content-Type: text/plain; charset=UTF-8

Indeed Julien, it sounds like it would make sense to utilise sfYaml when the
extension is not present, and use the extension where possible.

This is how Zend_Json works.

David

On 26 February 2010 12:56, Julien Pauli <[email-masked]> wrote:

> Just translated ext/yaml doc (http://www.php.net/yaml), perhaps we
> could detect the presence of the extension and make an adapter that
> would use it ?
> Does it cope with the need ?
>
> J.Pauli
>
> On Thu, Feb 25, 2010 at 8:38 PM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
> > -- Ryan Albertson <[email-masked]> wrote
> > (on Thursday, 25 February 2010, 02:20 PM -0500):
> >> Another consideration of mine would be if Doctrine is used, would ZF use
> yaml
> >> like symfony does for the generation of schemas and model classes by
> making
> >> Zend_Tool work with yaml like the symfony CLI?
> >
> > One consideration I have for 2.0 is to do a YAML backend for
> > Zend_Config, which would consume sfYaml. This would allow you to do what
> > you're suggesting, while simultaneously using the same configuration
> > file(s) with your ZF application.
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead            | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
>

-- 
Save Water...Drink Ouzo !

--00151747b64ad0c9ce0480812a42
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Indeed Julien, it sounds like it would make sense to utilise sfYaml when th=
e extension is not present, and use the extension where possible.<div><br><=
/div><div>This is how Zend_Json works.</div><div><br></div><div>David<br>

<br><div class=3D"gmail_quote">On 26 February 2010 12:56, Julien Pauli <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">doctorrock83@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Just translated ext/yaml doc (<a href=3D"http://www.php.net/yaml" target=3D=
"_blank">http://www.php.net/yaml</a>), perhaps we<br>
could detect the presence of the extension and make an adapter that<br>
would use it ?<br>
Does it cope with the need ?<br>
<br>
J.Pauli<br>
<div><div></div><div class=3D"h5"><br>
On Thu, Feb 25, 2010 at 8:38 PM, Matthew Weier O&#39;Phinney<br>
&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; -- Ryan Albertson &lt;<a href=3D"mailto:[email-masked]">rmalber=
[email-masked]</a>&gt; wrote<br>
&gt; (on Thursday, 25 February 2010, 02:20 PM -0500):<br>
&gt;&gt; Another consideration of mine would be if Doctrine is used, would =
ZF use yaml<br>
&gt;&gt; like symfony does for the generation of schemas and model classes =
by making<br>
&gt;&gt; Zend_Tool work with yaml like the symfony CLI?<br>
&gt;<br>
&gt; One consideration I have for 2.0 is to do a YAML backend for<br>
&gt; Zend_Config, which would consume sfYaml. This would allow you to do wh=
at<br>
&gt; you&#39;re suggesting, while simultaneously using the same configurati=
on<br>
&gt; file(s) with your ZF application.<br>
&gt;<br>
&gt; --<br>
&gt; Matthew Weier O&#39;Phinney<br>
&gt; Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"mai=
lto:[email-masked]">[email-masked]</a><br>
&gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://f=
ramework.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" =
target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
&gt;<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water.=
..Drink Ouzo !<br>
</div>

--00151747b64ad0c9ce0480812a42--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Cc: "Zend Framework Contributors" <[email-masked]>
Date: Tue, 28 Jul 2009 13:56:21 +0200
Subject: Re: [zf-contributors] Contributor list

Hy P=E1draic,

Feel free to edit this list to reflect also your component.
Just add a new line with the informations of this component.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "P=E1draic Brady" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>
Cc: "Zend Framework Contributors" <[email-masked]>
Sent: Tuesday, July 28, 2009 1:05 PM
Subject: Re: [zf-contributors] Contributor list

Hi Thomas,

Just a reference to something I edited while adding myself since I'm uncl=
ear=20
on how it should be handled. In components with muliple parts (for exampl=
e=20
Zend_Feed also hosts the completely independent Zend_Feed_Reader) we may =
not=20
have a single lead. In that case was it okay for me to add Zend_Feed_Read=
er=20
as a separate entry on the table? Easily reversed if not :).

Paddy

 P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

________________________________
From: Thomas Weidner <[email-masked]>
To: [email-masked]
Sent: Tuesday, July 28, 2009 8:12:05 AM
Subject: Re: [zf-contributors] Contributor list

Like for all other pages within our wiki you need to login.
It's the same process as if you edit one of your proposals.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- From: "Daniel Lo" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>
Sent: Tuesday, July 28, 2009 8:00 AM
Subject: Re: [zf-contributors] Contributor list

Hello Thomas,

How do we edit this page? or do we turn in this information to you=20
personally?

-daniel

Jira: danlo

Monday, July 27, 2009, 8:25:10 AM, you wrote:

> Hy all,

> we have since several months a contributor list.
> http://framework.zend.com/wiki/pages/viewpage.action?pageId=3D11036

> Now for 1.9 it's time again to update this list.
> Every contributor/maintainer/component lead is announced to update this=
=20
> list
> with his own informations within the proper component.

> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com

-- Best regards,
Daniel                            mailto:[email-masked]

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 1 Apr 2010 10:58:53 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

-- till <[email-masked]> wrote
(on Thursday, 01 April 2010, 04:30 PM +0200):
> On Mon, Mar 22, 2010 at 1:36 PM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
> > =A0* Submodules...
> > =A0 For those unfamiliar with git submodules, they are roughly equiva=
lent
> > =A0 to svn:externals. I say "roughly", because they differ in many wa=
ys:
> > =A0 they have to be manually initialized on each person's repository
> > =A0 (though they can be defined in the master repository); they need =
to
> > =A0 be manually updated periodically (unlike svn:externals, where any=
time
> > =A0 you do an "svn up", it also syncs the external); etc.
>=20
> http://github.com/blog/626-announcing-svn-support
>=20
> I know Zend will do their own git, but since it's trivial to make a
> mirror on Github, this might be something interesting for everyone who
> misses svn:externals. ;-)

Interesting -- I thought this was an April Fools joke, but tried it,
and, indeed, it works. There's one problem, however: you can only
checkout the entire repo -- you can't checkout a subtree within the
repo. But it would make it trivial to maintain a read-only SVN mirror --
from which you *could* do a sparse checkout.

Thanks for the heads-up!

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 12:04:29 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

-- Andy Fowler <[email-masked]> wrote
(on Monday, 22 March 2010, 11:38 AM -0400):
> Eric, that sounds right to me -- it's how most Github workflows
> operate, and it'd be terrific if we could use Github to submit pull
> requests to Matthew, even though he'll be merging them into the
> Zend-hosted repo.

Please see my previous response to Eric.

> A quick note on "atomic commits" in git. One of the things I had to
> learn when moving to Git was to get away from huge end-of-feature
> commits, like one would make in SVN. Eventually, it becomes easier to
> commit, revert, commit, revert many times during the course of a
> feature. At the end of the feature branch you can squash those many
> commits into a single atomic commit that contains all unit tests and
> docs:

Yes, but that's exactly what I was getting at. If we do library/ and
tests/ and documentation/ all as submodules, we can't have that final
atomic commit that has the tests and docs and code all together. :) 

I thoroughly enjoy the flexibility Git offers, but when it comes to
the master repository, we need the atomicity -- and the proposed
submodule layout I provided earlier in the thread answers that.

> http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
> 
> As a CLA'd but rare contributor, I'm really looking forward to the
> move to Git. In the past few months, I had given up on submitting
> patches. Nagging the IRC channel to pull something from JIRA was
> terribly inefficient -- hopefully this can smooth things along!

That's my hope as well.

> On Mar 22, 2010, at 11:21 AM, Eric Clemmons wrote:
> 
> > So, would a hypothetical (Github) workflow be as follows?
> > ...
> > 3.  Make atomic commits for unit tests, code changes, and new documentation
> > ...
> > On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:
> > 
> >> ...
> >>  Now, for an explanation of the "whys" behind this. As contributors,
> >>  it's important to make atomic commits: your code fix should also
> >>  include a corresponding unit test, and potentially a documentation
> >>  commit as well. If we split the library and tests directories out
> >>  into their own submodules, we cannot do so; the code and test must be
> >>  committed separately, which is (a) more work, and (b) unintuitive.
> >>  The same goes for related documentation commits.
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 13 Apr 2009 20:07:01 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

-- Matthew Ratzloff <[email-masked]> wrote
(on Monday, 13 April 2009, 03:19 PM -0700):
> That's fine, and I agree with the reasoning (standardization).=A0 There=
 are still
> a couple of issues to resolve:
>=20
> - I think Zend Framework should standardize on underscores or no
> underscores in namespaces.

This is where the differences between PEAR and ZF come into play. Since
each component in PEAR can be shipped separately, and because the
top-level packages are sometimes more than one level deep, they need it.
we won't need it in ZF's namespaces.

> - Arrangement of abstract classes and interfaces: nested or not?=A0 For=
 example,
> zend\controller\request and zend\controller\request\Http, or zend\contr=
oller\
> request\RequestAbstract (or whatever) and zend\controller\request\Http?

The latter. This is so the interfaces/abstract classes share the same
namespace as the concrete versions.

> - PEAR standards also stipulate capitalized abbreviations in mixed-case=
 class
> names, e.g., zend\controller\request\HTTP.=A0 Do we adhere to that as w=
ell?=A0
> $httpRequest =3D new request\HTTP()?

No, we can differentiate there. I think having the MixedCaseNames for
protocols is easier to read and provides a nice visual cue that this is
a class and not a constant.

> On Mon, Apr 13, 2009 at 5:49 AM, Matthew Weier O'Phinney <matthew@zend.=
com>
> wrote:
>=20
>     I'm going to break a couple of rules here: I'm replying to my own e=
mail,
>     as well as top-posting. Bear with me...
>=20
>     Robin S. raised an interesting point that Matt R. picked up and agr=
eed
>     with:
>=20
>     =A0 =A0I also notice that namespaces are written in Uppercase\Notat=
ion --
>     =A0 =A0Zend\Controller\Request. Will this be the standard? Another
>     =A0 =A0alternative is zend\controller\Request, which clearly distin=
guishes
>     =A0 =A0what's the namespace and what's the class/interface.
>=20
>     Additionally, it seems the primary push-back is with abstract class
>     naming, particularly when there are also interfaces defined in the =
same
>     namespace.
>=20
>     After reading these responses, I reached out to some friends in the=
 PEAR
>     community, some of whom I've spoken with before about these issues.=
 "Why
>     PEAR?" some may ask. ZF standards are based on PEAR standards. One =
goal
>     since the beginning of the ZF project has been to promote
>     interoperability with established standards. PEAR CS are the "gold
>     standard" in the PHP community, and whether you like or agree with =
them
>     or not, they are used widely.
>=20
>     The PEAR Group has been debating new standards to adopt for PEAR2 f=
or
>     some time now. PEAR2 is targeting a minimum required version of PHP=
 5.3,
>     so they are addressing the very same issues we're discussing. They =
have
>     also basically reached consensus, though they have not formally ado=
pted
>     the new standards yet. When it comes to namespaces and class naming=
, it
>     is the ZF team's opinion that we need to be as close to PEAR standa=
rds
>     as possible.
>=20
>     The relevant documents are here:
>=20
>     =A0 =A0http://wiki.php.net/pear/rfc/pear2_class_naming
>     =A0 =A0http://wiki.php.net/pear/rfc/pear2_naming_standards
>=20
>     In a nutshell, here's what they define:
>=20
>     =A0* Namespaces are lowercase: zend\codegenerator\php
>     =A0* Class names are MixedCase: zend\codegenerator\php\File
>     =A0* Namespaces may contain underscores, but they do not translate =
to the
>     =A0 directory separator
>     =A0* Class names may contain underscores, and they *do* translate t=
o the
>     =A0 directory separator
>     =A0* Interfaces should be named descriptively, and not contain the =
word
>     =A0 "Interface" or the sigil "I".
>     =A0* It is preferred that Abstract classes are also named descripti=
vely,
>     =A0 but *may* contain the *suffix* Abstract.
>=20
>     There are some good arguments for each point in the linked RFCs.
>=20
>     I think that adopting these standards addresses most concerns the Z=
F
>     team has, as well as many if not most concerns posted in this threa=
d.
>=20
>     -- Matthew Weier O'Phinney <[email-masked]> wrote
>     (on Friday, 10 April 2009, 02:24 PM -0400):
>     > Greetings, all --
>     >
>     > Below is a proposal I am making to modify the Zend Framework Codi=
ng
>     > Standards conventions for the naming of Interfaces and Abstract c=
lasses.
>     >
>     > This decision is basically already made, but I'd appreciate any f=
eedback
>     > that you may have on the matter.
>     >
>     > Thanks!
>     >
>     > The problem
>     > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>     > PHP 5.3 introduces namespaces to the PHP language. While this won=
't have
>     an
>     > impact much on userland code, it will have an impact on library a=
nd
>     framework
>     > code, as it provides a useful paradigm for organizing components =
as well
>     as
>     > simplifying syntax. Instead of having to say things like:
>     >
>     > =A0 =A0 $analyzer =3D new Zend_Search_Lucene_Analysis_Analyzer_Co=
mmon_TextNum
>     ();
>     >
>     > we can instead do something like this:
>     >
>     > =A0 =A0 namespace Zend\Search\Lucene\Analysis\Analyzer;
>     >
>     > =A0 =A0 $analyzer =3D new Common_TextNum();
>     >
>     > or even:
>     >
>     > =A0 =A0 namespace Zend\Search\Lucene\Analysis\Analyzer;
>     >
>     > =A0 =A0 class Common_TextNum extends Common
>     > =A0 =A0 {
>     > =A0 =A0 }
>     >
>     > The problem that arises for Zend Framework has to do with how we =
name
>     abstract
>     > classes and interfaces. Currently, the final segment of such clas=
ses are
>     > expected to end with _Abstract and _Interface, respectively. This=
 will
>     not work
>     > when we migrate to utilize namespaces, for two reasons.
>     >
>     > First, and most obviously, 'abstract' and 'interface' are reserve=
d PHP
>     keywords.
>     > As such, in situations such as the following:
>     >
>     > =A0 =A0 namespace Zend\Controller\Request;
>     >
>     > =A0 =A0 class Abstract
>     > =A0 =A0 {
>     > =A0 =A0 }
>     >
>     > =A0 =A0 // or:
>     >
>     > =A0 =A0 namespace Zend\Controller\Dispatcher;
>     >
>     > =A0 =A0 interface Interface
>     > =A0 =A0 {
>     > =A0 =A0 }
>     >
>     > we'll run into issues.
>     >
>     > Second, and less obvious, is that perhaps the easiest solution br=
eaks one
>     of the
>     > key principles of namespaces (which are designed to help encapsul=
ate
>     > components). This one's harder to explain, so let's look at examp=
les.
>     Consider a
>     > component such as Zend_Controller_Request. The simplest solution =
would be
>     to
>     > name the abstract class or interface Zend\Controller\Request, and=
 then
>     have the
>     > various concrete implementations under that namespace:
>     >
>     > =A0 =A0 namespace Zend\Controller;
>     >
>     > =A0 =A0 interface Request
>     > =A0 =A0 {
>     > =A0 =A0 }
>     >
>     > =A0 =A0 // and concrete ones:
>     >
>     > =A0 =A0 namespace Zend\Controller\Request;
>     >
>     > =A0 =A0 class Http
>     > =A0 =A0 {
>     > =A0 =A0 }
>     >
>     > What's the problem here? The interface is not in the same namespa=
ce as
>     the
>     > concrete implementations.
>     >
>     > Potential solutions and recommendation
>     > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>     > So, how should Zend Framework "solve" these issues? A number of p=
roposals
>     and
>     > recommendations have been floated around, both within ZF circles =
and in
>     the
>     > greater PHP community.
>     >
>     > Considerations include:
>     >
>     > =A0* Avoiding the use of PHP reserved keywords (already noted).
>     > =A0* Avoiding Hungarian Notation (i.e., having the name or a port=
ion of the
>     name
>     > =A0 =A0describe its type -- which, to a degree, the current namin=
g
>     conventions
>     > =A0 =A0already violate). (See http://en.wikipedia.org/wiki/Hungar=
ian_Notation
>     , the
>     > =A0 =A0sections "Disadvantages of Systems Hungarian" and "Notable=
 Opinions"
>     for some
>     > =A0 =A0of the arguments against using Hungarian Notation.)
>     >
>     > Approaches that have been considered include:
>     >
>     > =A0* Using 'I' to prefix interfaces. This derives from standards =
in other
>     > =A0 =A0programming languages (.Net and python, in particular). Th=
is is just
>     another
>     > =A0 =A0form of Hungarian Notation, however.
>     >
>     > =A0* Using "Interface" or "Abstract" as a class name suffix:
>     RequestInterface,
>     > =A0 =A0RequestAbstract. Again, however this is Hungarian Notation=
.
>     >
>     > =A0* Using the term "Base" for abstract classes: BaseRequest, Req=
uestBase,
>     Base.
>     > =A0 =A0This is just substituting the word Base for Abstract, howe=
ver, and is
>     really
>     > =A0 =A0not much different than the above.
>     >
>     > =A0* Use generic, descriptive names indicative of functionality o=
r
>     behavior. As
>     > =A0 =A0examples from the SPL, "Countable", "Iterator", "ArrayObje=
ct".
>     >
>     > My recommendation is to use the latter, as it solves all consider=
ations.
>     It will
>     > take more thought when naming, but will ensure that components ca=
n live
>     in a
>     > self-contained namespace, do not use reserved keywords, and avoid
>     Hungarian
>     > Notation.
>     >
>     > Plan for implementation
>     > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
>     > I recommend that the Coding Standards documentation be updated to=
 reflect
>     this
>     > approach.
>     >
>     > All new components going into 1.8 and onwards should adopt these
>     standards. In
>     > releases 1.9 and forward, we will begin migrating existing interf=
aces/
>     abstract
>     > classe. First, new classes/interfaces will be created that follow=
 these
>     > conventions and which extend the originals; later, any type-hinti=
ng based
>     on the
>     > original class/interface names will be updated to point to the ne=
w names;
>     and
>     > finally, in 2.0, we will remove the old interfaces/abstract class=
es
>     entirely.
>     >
>     > --
>     > Matthew Weier O'Phinney
>     > Software Architect =A0 =A0 =A0| [email-masked]
>     > Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>     >
>=20
>     --
>     Matthew Weier O'Phinney
>     Software Architect =A0 =A0 =A0| [email-masked]
>     Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>=20
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 1 Dec 2009 15:31:52 +0100
From: Dolf Schimmel <[email-masked]>
To: Andrea Turso <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Re: [fw-general] Discontinuing Zend Entity in 
	favour of Doctrine integration

Discussions on ZF2.0 have started already and roadmaps are in the
making, which means that ZF2.0 will be released soon (where soon is <
12 months). ZF2.0 will have as minimum requirement php >=5.3, so there
doctrine could be integrated easily, and the version wouldn't really
be a problem I guess.

Dolf
On Tue, Dec 1, 2009 at 3:22 PM, Andrea Turso <[email-masked]> wrote:
> Hi everybody, it seems that this thread went quite off topic.
>
> I'm quite disappointed by the decision to discontinue the development of
> a Data Mapper for the Zend Framework. I read this thread and agree with most
> of the reasons against building a new one and waiting for the release
> of Doctrine2.
>
> But AFAIK Doctrine2 is for PHP 5.3 hence excluding the great userbase
> of the Zend Framework for PHP 5 could not benefit of a persistence api
> for the Zend Framework.
> That's pity. It's not always possible to use the cutting-edge release
> of PHP. Say Doctrine2 will
> be stable in 14 months, do you think every hosting provider on the
> plan will have done the leap
> to PHP 5.3 then? I don't think so.
>
> IMHO it's awful to discontinue this great project and wait for
> Doctrine2 to be realeased and
> integrated with the Zend Framework, there're people who need a Data
> Mapper now (me included!)
>
> I've been building a poor-man metadata mapper these days, it doesn't
> implement the JSR220 specs
> but it works. You know, building a data mapper is not my primary
> concern when working.
>
> By the way I'm a kind of abstraction addicted and quite bigot about
> objects, so I started reading
> the JSR220 Java Persistent Api specifications, but I don't want to
> clutter the simple data mapper
> I've written, and instead spending my spare time implementing a JPA
> compliant data mapper.
>
> I could try to continue developing what started by Benjamin.
>
> Just a side note: I know the Reflection API limitation for non-public
> properties in PHP prior to 5.3,
> and I really don't want to break encapsulation by using specific
> methods that must be inherited by
> entities from a non domain-specific class.
>
> So I was wondering about using serialization to break the
> encapsulation and retrieve properties value.
> Could it be a viable solution?
>
>
> Andrea
>

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 11:46:34 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--0016e6d7eb681ff4a104806a7f12
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley <[email-masked]>wrote:

> In my opinion if Doctrine integration is to be left until ZF 2.0, then the
> integrated version of Doctrine should be the 2.0 version. Since both 2.0
> versions will require PHP 5.3.
>

I agree. Doctrine 2 will fill the lack of model infrastructure in Zend
Framework.
Anyway, the set of changes listed by Matthew is already a big step towards
simpler development (exploiting phpunit new features for example.)

Regards,
-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d7eb681ff4a104806a7f12
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ashley@ls1=
2style.co.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;=
 padding-left: 1ex;">

In my opinion if Doctrine integration is to be left until ZF 2.0, then the =
integrated version of Doctrine should be the 2.0 version. Since both 2.0 ve=
rsions will require PHP 5.3.<br></blockquote></div><br clear=3D"all">I agre=
e. Doctrine 2 will fill the lack of model infrastructure in Zend Framework.=
<br>
Anyway, the set of changes listed by Matthew is already a big step towards =
simpler development (exploiting phpunit new features for example.)<br><br>R=
egards,<br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br>
<a href=3D"http://giorgiosironi.blogspot.com">http://giorgiosironi.blogspot=
.com</a><br><a href=3D"http://twitter.com/giorgiosironi">http://twitter.com=
/giorgiosironi</a><br>

--0016e6d7eb681ff4a104806a7f12--

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Sat, 11 Apr 2009 18:07:03 +0200
Subject: Re: [zf-contributors] [[email-masked]: Re: [zf-contributors]
	Proposal to update Abstract/Interface Naming Conventions]

i fully agree with matt on this issue :-)

it should be obvious for a user by looking at the classes, free-style naming 
isn't really obvious

regards,
Benjamin

On Saturday 11 April 2009 17:57:16 Matthew Ratzloff wrote:
> "There have been a TON of debates amongst ZF contributors about naming,
> and making the names meaningful. I would expect that this proposal would
> probably be very welcome to those individuals. (Matt R., I'm looking at
> you...)"
> Meaningful names are great!  It just depends on what you mean by
> "meaningful".  For me, it mean clearly communicating the role of a class,
> so that users can instantly determine how classes are interrelated, even if
> they're navigating the code online.  Right now we have that: it is clear
> that Zend_Controller_Request_Http extends Zend_Controller_Request_Abstract,
> even before you open either, and even if you aren't using an IDE.
>  Zend_Controller_Request_Http extending Zend_Controller_Request would also
> communicate that.  I would like to retain that quality of the file
> organization.
>
> With the following names...
>
>  * Zend\Controller\Request\RequestEnvironment, RequestObject
>    (interface, abstract)
>  * Zend\Controller\Response\ResponsePayload, ResponseObject
>    (interface, abstract)
>  * Zend\Controller\Dispatcher\DispatchMapper (interface)
>
> ...excepting this one...
>
>  * Zend\Validate\Validatible, Validator (interface, abstract)
>
> ...it is not really apparent what relates to what.  RequestEnvironment does
> not communicate Interface to me, and RequestObject does not communicate
> abstract.  While you may say that that's irrelevant because we have IDEs, I
> would say that these names have the potential to be more confusing, because
> there are no rules for how environments and objects and payloads and
> mappers are related.  If I'm looking to extend one of these classes (which
> happens frequently), I have to study a few classes to figure out how
> everything interacts.  Today I can open the abstract or interface and get
> right to work.
>
> One other thing.  There are going to be cases where these names are going
> to be really awkward.  One of the great things about frameworks in general
> is that they remove choices so that you can focus on getting the job done.
> IRequest, IResponse--there is no thought required for these names.  But in
> the other scenario contributors must determine whether RequestEnvironment,
> RequestObject, Requestable, or whatever most effectively communicates its
> role.
>
> If we go this route, I also think we're going to end up standardizing on
> some things simply in an effort to avoid the above.  I think Object will
> become a stand-in for Abstract, for example (RequestObject).  I think
> standardization of this kind results in a clear API, but in effect, it is a
> form of limited Hungarian notation through the back door.  If we are
> ultimately going to go that route, we should just do it up front. 
> Honestly, I would even be OK with AbstractRequest and RequestInterface,
> although I know you would hate that idea.  :-)
>
> -Matt
>
> On Fri, Apr 10, 2009 at 4:13 PM, Matthew Weier O'Phinney
>
> <[email-masked]>wrote:
> > -- Matthew Weier O'Phinney <[email-masked]> wrote
> >
> > (on Friday, 10 April 2009, 04:39 PM -0400):
> > > Forwarding from Ben, who intended to copy the list...
> > >
> > > ----- Forwarded message from Benjamin Eberlei <[email-masked]>
> >
> > -----
> >
> > > From: Benjamin Eberlei <[email-masked]>
> > > To: Matthew Weier O'Phinney <[email-masked]>
> > > Date: Fri, 10 Apr 2009 18:58:02 +0000
> > > Subject: Re: [zf-contributors] Proposal to update Abstract/Interface
> >
> > Naming
> >
> > >       Conventions
> > >
> > >
> > > moving to this new namespace implementation and breaking all old ones
> > > is
> >
> > a
> >
> > > serious BC,
> > > so why do we only allow slight changes for everything else? I thought
> > > we would just go to "change the serious technical debt, but as BC as
> > > possible", changing the name of an interface is the exact difference of
> > > that.
> >
> > It is, but we're going to need to do it once we move to namespaces
> > anyways -- because our CS were written before namespaces were even
> > proposed for inclusion in PHP.
> >
> > This is also why I propose the gradual changes over a series of
> > versions. This allows us to provide migration instructions that users
> > can gradually implement, making their code more future-proof. If the
> > new versions of the interfaces and abstract classes extend the
> > originals, there is no BC break until we finally drop the old classes --
> > which, as I mentioned, will not happen until 2.0.
> >
> > > additionally, the generic name one seems strange in my eyes. How would
> >
> > you
> >
> > > do that for
> > > the example of request, response, dispatcher? Validation interface?
> >
> > First off, the request and response objects need interfaces, and then
> > potentially abstract implementations. Either way, this is easy:
> >
> >  * Zend\Controller\Request\RequestEnvironment, RequestObject
> >    (interface, abstract)
> >  * Zend\Controller\Response\ResponsePayload, ResponseObject
> >    (interface, abstract)
> >  * Zend\Controller\Dispatcher\DispatchMapper (interface)
> >  * Zend\Validate\Validatible, Validator (interface, abstract)
> >
> > The names take a little creativity, but they also make it clearer in
> > your code what you're doing:
> >
> >    namespace Zend\Controller\Request;
> >
> >    class HttpEnvironment implements RequestEnvironment
> >    {
> >    }
> >
> >    // or
> >    namespace Zend\Validate;
> >
> >    class Alpha extends Validator
> >    {
> >     }
> >
> > > i don't seem to find good ones. ResponseObject, RequestObject,
> > > Validatable are ok, but from the typehints its very hard to suggest
> > > that these are interfaces in contrast to concrete implementation.
> >
> > Typehints should typically be to interfaces anyways...
> >
> > > furthermore, why break with the ways of java, python, and .net? this is
> > > what many programmers are used to.
> >
> > Because Java and .Net are strongly typed languages, and PHP isn't.
> > Because just because a convention worked for one language doesn't mean
> > it's appropriate for another. Because PHP is not Java, is not Python, is
> > not .NET.
> >
> > There have been a TON of debates amongst ZF contributors about naming,
> > and making the names meaningful. I would expect that this proposal would
> > probably be very welcome to those individuals. (Matt R., I'm looking at
> > you...)
> >
> > > As a last point, having implementation and interface in different
> > > packages is actually the single most important issue about having an
> > > interface anyways and a huge benefit for object oriented design.  this
> > > separates the concerns and reduces dependencies, so I would love to
> > > see this in a 2.0 version.
> >
> > There's a difference between using an interface in userland code, and
> > using one within a framework or library. In your userland code, you
> > *will* have the interface in a different package:
> >
> >    namespace Foo\Controller\Request;
> >    import Zend\Controller\Request as ZfRequest;
> >
> >    CustomHttpRequest extends ZfRequest\HttpEnvironment
> >    {
> >    }
> >
> > *Within* the framework, it's better for them to be in the same
> > namespace, to allow selectively packaging components for distribution or
> > deployment.
> >
> > > That is what i am greatly missing in ZF, that for example the
> > > controller is implemented with several very large abstract classes
> > > only and the dependencies are so hard-wired that its impossible to
> > > exchange just one part of the controller to add specific functionality
> > > without having to change considerable other parts also.
> >
> > This has nothing to do with naming conventions, and is a topic we
> > already plan to address for (or before) 2.0. (Please search for
> > "Zend_Controller 2.0" on the wiki for some of the plans.)
> >
> > > On Fri, 10 Apr 2009 14:24:34 -0400, Matthew Weier O'Phinney
> > >
> > > <[email-masked]> wrote:
> > > > Greetings, all --
> > > >
> > > > Below is a proposal I am making to modify the Zend Framework Coding
> > > > Standards conventions for the naming of Interfaces and Abstract
> >
> > classes.
> >
> > > > This decision is basically already made, but I'd appreciate any
> >
> > feedback
> >
> > > > that you may have on the matter.
> > > >
> > > > Thanks!
> > > >
> > > > The problem
> > > > ===========
> > > > PHP 5.3 introduces namespaces to the PHP language. While this won't
> >
> > have
> >
> > > > an
> > > > impact much on userland code, it will have an impact on library and
> > > > framework
> > > > code, as it provides a useful paradigm for organizing components as
> >
> > well
> >
> > > > as
> > > > simplifying syntax. Instead of having to say things like:
> > > >
> > > >     $analyzer = new
> > >
> > > Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> > >
> > > > we can instead do something like this:
> > > >
> > > >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > > >
> > > >     $analyzer = new Common_TextNum();
> > > >
> > > > or even:
> > > >
> > > >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > > >
> > > >     class Common_TextNum extends Common
> > > >     {
> > > >     }
> > > >
> > > > The problem that arises for Zend Framework has to do with how we name
> > > > abstract
> > > > classes and interfaces. Currently, the final segment of such classes
> >
> > are
> >
> > > > expected to end with _Abstract and _Interface, respectively. This
> > > > will
> > >
> > > not
> > >
> > > > work
> > > > when we migrate to utilize namespaces, for two reasons.
> > > >
> > > > First, and most obviously, 'abstract' and 'interface' are reserved
> > > > PHP keywords.
> > > > As such, in situations such as the following:
> > > >
> > > >     namespace Zend\Controller\Request;
> > > >
> > > >     class Abstract
> > > >     {
> > > >     }
> > > >
> > > >     // or:
> > > >
> > > >     namespace Zend\Controller\Dispatcher;
> > > >
> > > >     interface Interface
> > > >     {
> > > >     }
> > > >
> > > > we'll run into issues.
> > > >
> > > > Second, and less obvious, is that perhaps the easiest solution breaks
> >
> > one
> >
> > > > of the
> > > > key principles of namespaces (which are designed to help encapsulate
> > > > components). This one's harder to explain, so let's look at examples.
> > > > Consider a
> > > > component such as Zend_Controller_Request. The simplest solution
> > > > would
> >
> > be
> >
> > > > to
> > > > name the abstract class or interface Zend\Controller\Request, and
> > > > then have the
> > > > various concrete implementations under that namespace:
> > > >
> > > >     namespace Zend\Controller;
> > > >
> > > >     interface Request
> > > >     {
> > > >     }
> > > >
> > > >     // and concrete ones:
> > > >
> > > >     namespace Zend\Controller\Request;
> > > >
> > > >     class Http
> > > >     {
> > > >     }
> > > >
> > > > What's the problem here? The interface is not in the same namespace
> > > > as
> > >
> > > the
> > >
> > > > concrete implementations.
> > > >
> > > > Potential solutions and recommendation
> > > > ======================================
> > > > So, how should Zend Framework "solve" these issues? A number of
> >
> > proposals
> >
> > > > and
> > > > recommendations have been floated around, both within ZF circles and
> > > > in the
> > > > greater PHP community.
> > > >
> > > > Considerations include:
> > > >
> > > >  * Avoiding the use of PHP reserved keywords (already noted).
> > > >  * Avoiding Hungarian Notation (i.e., having the name or a portion of
> >
> > the
> >
> > > > name
> > > >    describe its type -- which, to a degree, the current naming
> > >
> > > conventions
> > >
> > > >    already violate). (See
> > >
> > > http://en.wikipedia.org/wiki/Hungarian_Notation,
> > >
> > > > the
> > > >    sections "Disadvantages of Systems Hungarian" and "Notable
> > > > Opinions" for some
> > > >    of the arguments against using Hungarian Notation.)
> > > >
> > > > Approaches that have been considered include:
> > > >
> > > >  * Using 'I' to prefix interfaces. This derives from standards in
> > > > other programming languages (.Net and python, in particular). This is
> > > > just another
> > > >    form of Hungarian Notation, however.
> > > >
> > > >  * Using "Interface" or "Abstract" as a class name suffix:
> > > > RequestInterface,
> > > >    RequestAbstract. Again, however this is Hungarian Notation.
> > > >
> > > >  * Using the term "Base" for abstract classes: BaseRequest,
> >
> > RequestBase,
> >
> > > > Base.
> > > >    This is just substituting the word Base for Abstract, however, and
> >
> > is
> >
> > > > really
> > > >    not much different than the above.
> > > >
> > > >  * Use generic, descriptive names indicative of functionality or
> > >
> > > behavior.
> > >
> > > > As
> > > >    examples from the SPL, "Countable", "Iterator", "ArrayObject".
> > > >
> > > > My recommendation is to use the latter, as it solves all
> >
> > considerations.
> >
> > > > It will
> > > > take more thought when naming, but will ensure that components can
> > > > live
> > >
> > > in
> > >
> > > > a
> > > > self-contained namespace, do not use reserved keywords, and avoid
> > > > Hungarian
> > > > Notation.
> > > >
> > > > Plan for implementation
> > > > =======================
> > > > I recommend that the Coding Standards documentation be updated to
> >
> > reflect
> >
> > > > this
> > > > approach.
> > > >
> > > > All new components going into 1.8 and onwards should adopt these
> > > > standards. In
> > > > releases 1.9 and forward, we will begin migrating existing
> > > > interfaces/abstract
> > > > classe. First, new classes/interfaces will be created that follow
> > > > these conventions and which extend the originals; later, any
> > > > type-hinting
> >
> > based
> >
> > > > on the
> > > > original class/interface names will be updated to point to the new
> >
> > names;
> >
> > > > and
> > > > finally, in 2.0, we will remove the old interfaces/abstract classes
> > > > entirely.
> > > >
> > > > --
> > > > Matthew Weier O'Phinney
> > > > Software Architect      | [email-masked]
> > > > Zend Framework          | http://framework.zend.com/
> > >
> > > ----- End forwarded message -----
> > >
> > > --
> > > Matthew Weier O'Phinney
> > > Software Architect      | [email-masked]
> > > Zend Framework          | http://framework.zend.com/
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | [email-masked]
> > Zend Framework          | http://framework.zend.com/

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 11 Dec 2009 11:41:43 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Security policy posted

I just sent the following announcement to the fw-general list:

    Greetings!

    The Zend Framework team has posted a security policy for the framework.
    This include:

    * How and when to report
    * Pages detailing each reported security advisory
    * An RSS2 feed for tracking security advisories

    You can read up for more details on the policy at:

        http://framework.zend.com/security

    We welcome your input on the policy, and thank you in advance for
    helping us make and keep ZF and ZF users secure.

Currently, the zf-security alias goes to the various members of the ZF
team at Zend. We will be inviting several community members to help
monitor it as well in the coming weeks; if you are interested, please
contact one of us, and indicate how and why you would be of assistance
in this role. 

Additionally, we're still trying to hammer down some details of our
policy -- Ralph, for instance, brought up the idea that we may want to
have our own security ratings for advisories, and have good definitions
for each rating. We welcome any feedback you may offer.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:09 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 7 Dec 2009 16:02:09 +0100
From: Giorgio Sironi <[email-masked]>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In 
	Zend_Filter_StripTags

--0016e6d7eaebd58d0f047a24bd8b
Content-Type: text/plain; charset=ISO-8859-1

But why it has been created at all?

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d7eaebd58d0f047a24bd8b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

But why it has been created at all?<br clear=3D"all"><br>-- <br>Giorgio Sir=
oni<br>Piccolo Principe &amp; Web Engineer<br><a href=3D"http://giorgiosiro=
ni.blogspot.com">http://giorgiosironi.blogspot.com</a><br><a href=3D"http:/=
/twitter.com/giorgiosironi">http://twitter.com/giorgiosironi</a><br>

--0016e6d7eaebd58d0f047a24bd8b--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 14:34:56 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Bug Hunt Days this week

Just a reminder to everyone -- November's Bug Hunt Days are this week on
Thursday and Friday. Please help out as you can -- log into #zftalk.dev
on Freenode, or triage issues via this mailing list. Let's close *200*
bugs this month! :)

Thanks in advance for all the help -- and for all the assistance each of
you provides each day!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 15:45:11 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Kevin McArthur <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0-1159218232-1258069511=:9816
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

We should probably get rid of the "design by contract" terminology - many o=
f us will take it at face value as referring to the software engineering co=
ncept with all the bells and whistles attached.=0A=0A>This is where it will=
 get in the way. Now not only do you have to write the code you want to con=
tribute =0A>(something many of us do as an ancillary benefit to 'Actually G=
etting Stuff Done') but also an Interface, =0A>Tests, Documentation and pro=
bably some ZF tracker stuff. Wow, overhead. I don't have time for it -- and=
 =0A>I'm not alone in that, I assure you. Don't get me wrong, its nice to h=
ave all those things, but not at =0A>the expense of the actual functionalit=
y getting checked in. Maybe I'm ****ing in the wind, but can we try =0A>to =
lower the contribution overhead? I'm willing to send in commented, code-lev=
el patches as I go about my=0A>normal dev, but those who sponsor that work =
aren't willing to pay for me to write tests and docs for the =0A>stuff I im=
prove. This leads to most of my zfw improvements going uncontributed, or wh=
en they encompass =0A>major libs, forked off from the core and released ind=
ependently where they don't do as many people as =0A>good as they could if =
they were part of zfw. =0A=0ATo be honest, I don't follow Kevin's objection=
s. Every line of code written is a constant fight between two metrics - per=
formance and flexibility. Interfaces assist flexibility by allowing for sub=
stitution - an amazingly powerful capability in a framework (as a certain f=
ramework outside of PHP has quickly learned with a little prompting from a =
more flexible sibling). Eliminating flexibility for the sake of performance=
 is a dangerous road to follow blindly. Conventions play a role in minimisi=
ng the risks, and experience eliminates the remainder - and this is exactly=
 what Matthew is identifying. With a few years of ZF 1.0 behind us, 2.0 can=
 balance both a lot better where it really really counts.=0A=0AThe main wal=
l Kevin just hit is simply never going away. If it ever did, ZF wouldn't be=
 far behind it as a untested, undocumented morass of code that (allegedly) =
does stuff. We need all the "contribution overhead". It is absolutely essen=
tial. There are components in the ZF which, to be generous, are pretty bad =
in terms of testing, documentation and flexibility already - and that's wit=
h the requirement! I have worse descriptions. Catch me on IRC during a bug =
hunt and I'll share some ;).=0A=0AThe fact is, if you cannot handle the add=
itional work that underpins, supports and ensures ease of maintenance for a=
 component - then you are begging for a developer to start swearing over IR=
C. I had the joy of dealing with such a component a few weeks back. It took=
 me hours to figure out a bug. Why? Because the unit tests DID NOT TEST the=
 functionality of the component. I could have deleted every single test wit=
h no ill effect - they were all busy with XML parsing or something (perform=
ed by a completely different component with its own perfectly functional un=
it tests).=0A=0ABut worse than all this, is the assumption that lowering th=
e contribution overhead is a positive thing. It's not - it merely shifts th=
at work onto someone else. Someone else with precious little time and a cha=
rgeout rate to justify work with. And surprise - they won't like that in th=
e slightest. Sometimes you get lucky - I spent about 10 hours of otherwise =
chargeable time in September's bug hunt (which I enjoyed a lot by the way) =
along with several evenings but generally everyday work will always lean to=
wards ignoring contributions where no supporting "contribution overhead" ha=
s also been committed. Such contributions/patches/whatever can be horrible =
to work on. No tests, poor explanations, lack of communication, differing a=
ssumptions - ugh. If it's not worth contributing in full, don't expect some=
one else to do it - they probably won't.=0A=0ASorry for the ranty piece - b=
ut code doesn't write itself. It is great to have a contribution - so long =
as you don't pin it all on someone else ;).=0A=0A>Interfaces are useful sur=
e, but like tests, they're only useful when written from a different perspe=
ctive =0A>than the implementation. My attempt to fix a bug in zend's wildfi=
re layer only to run into a case where a =0A>test checked for not implement=
ed as a response being a prime example. The same will happen with rigid =0A=
>interfaces as with rigid tests.=0A=0AInterfaces are supposed to be rigid. =
What Matthew is attempting to emphasis to you is that an interface should a=
ddress the "core" functionality. Adding interface defs for every single pub=
lic method is all too common, and all too unnecessary.=0A=0AIf you describe=
d the example a bit, it might help you see what is being aimed at here - an=
d where that wildfire component probably went awry.=0A=0A>I agree that it m=
akes testing easier, but disagree that it leads to performance. Loading lar=
ge interfaces =0A>(picture the size of an interface for Zend_Pdf or Zend_Db=
 for examples) .... really adds to loading =0A>overhead.  Also, if you star=
t really talking about interfaces and DI, you get into a lot of runtime use=
 =0A>of the instanceof operator -- and that saps performance too.=0A=0AMiss=
ing the point. Interfaces are rigid - less scope for edge cases, mishaps, m=
isunderstandings - i.e. the resulting code can afford to be leaner, focused=
 and (by praying to XDebug and sacrificing goats on the alter of "try, try =
again") hopefully be more performant.=0A=0A>>In terms of contribution overh=
ead, it means that part of any component=0A>>design will be ascertaining th=
e basic, essential functionality and=0A>>creating an interface that encapsu=
lates it; this is just good=0A>>programming.=0A>=0A>This is where it will g=
et in the way. [...]=0A=0ANo, this is where it's supposed to begin. If, lik=
e me, you are a total TDD fanboy ;). In TDD, the API comes first. From the =
targeted API flows the Interface. From the Interface flows an obedient impl=
ementing class. Granted it's a very specific methodology I'm using as an ex=
ample. For someone using TDD, an Interface is almost a certainty - it will =
warp and change over time but that evolution will reflect the very core fun=
ctionality of the implementation. Even without TDD, that should be pretty c=
ommon - where else is the API coming from?=0A=0A>I'm poking around in it, b=
ut I'm not sure I see how 'the' front controller will be accessed. Whats th=
e =0A>equivilent call to Zend_Controller_Front::getInstance().... somewhere=
's gonna have to be a registry (or =0A>at least a responsible object) if th=
ats not singleton-ized.=0A=0AWhich one? Nobody said there would be one fron=
t controller. My guess, is that it will be accessible from your bootstrap, =
which is registered to the front controller, which is registered to...I'm l=
ost now. It will be injected into wherever it tends to be most useful. Just=
 not globally as a singleton. Bear in the current singleton usage encourage=
s a disregard for injection - which is used by the other 99% of inputs into=
 classes like helpers, plugins, etc. Replace Frontcontroller with any other=
 component - you should get the same answer for the new Frontcontroller. It=
's not some oddball, hyper-weird class that needs special treatment.=0A=0A>=
The DI stuff is definitely not straightforward compared to whats there now.=
=0A=0AWhat's there right now is DI - as a patchwork of different approaches=
 however which make the APIs more unpredictable than they should be. If you=
 mean a DI Framework - pretty sure that is not on the agenda. The closest t=
o a DI Framework is Zend_Application - which is stretching that concept an =
awful lot.=0A=0A>I don't agree with this. IMHO, If you can't trace it under=
 the hood -- it's too complicated. I can't =0A>stress enough how important =
it is for people working with ZFW to actually=0A>understand how ZFW works, =
and to be able to trace their application's execution conceptually. PHP isn=
't =0A>an SDK language and ZFW shouldn't aim to be a SDK framework. The who=
le execution process should follow an =0A>easily traced path from start to =
finish.=0A=0ATrace what under the hood? Request->Route->Dispatch->Controlle=
r->Action <- stick plugins in between. It's not rocket science. If you doub=
led the complexity of the implementation today, it would still quack like t=
he same duck it was yesterday. Right now you can still conceptually grasp M=
VC and use it, without ever reading the source code. In fact, right now MVC=
 is a pretty complex beast in ZF. It would take a serious effort to complic=
ate it further :).=0A=0A>Can a skilled PHP developer contribute a change to=
 the framework easily=0A>without being involved in the ZFW core politics, c=
ontribution processes,=0A>proposal processes, test writing, doc writing, et=
c.=0A=0AZF may be one of the few non-political projects around. I've had so=
me fun of course butting heads in the past, but the last two years have bee=
n politics free. Everything else is answered "no". Who else is going to mir=
aculously write someone else's tests/docs/proposals? Not me :P.=0A=0APaddy.=
=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survi=
vethedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=
=0A=0A=0A________________________________=0AFrom: Kevin McArthur <kevin@sto=
rmtide.ca>=0ATo: [email-masked]=0ASent: Thu, November 12, 2=
009 9:41:59 PM=0ASubject: Re: [zf-contributors] Zend Framework 2.0 Roadmap=
=0A=0A Reply inline.=0A=0AMatthew Weier O'Phinney wrote: =0A<snip>=0A>=0A>T=
hat makes sense, and I'm open to that. =0A>=0A>That said, if a component ha=
s dependencies on other components or makes=0A>use of other components, I t=
hink the pattern should be mandatory.=0A>Dependency Injection -- note, I'm =
NOT saying DI containers -- is much=0A>simpler with this pattern.=0A>=0A>=
=0ACan we define components? Classes within their own namespace? If so, I'm=
 cool with that. Off the top of my head my main thinking is like PDF Points=
, Rects, Cirlces etc... these make no sense to be 'configurable'. But they =
all exist within their own namespace.  Configuration standards when crossin=
g namespaces... that makes sense.=0A=0AThe rationale is because it allows u=
s to catch either based on the SPL=0A>exception type OR the component excep=
tion type. It's more flexible.=0A>=0A>Each component Exception would inheri=
t from the zend\Exception marker=0A>interface -- so, again, there'd still b=
e the Exception inheritance=0A>hierarchy, but also a hierarchy for general =
purpose exceptions.=0A>=0A>Finally, the paradigm encourages creating except=
ions for each type of=0A>exceptional situation, instead of having a generic=
 exception per=0A>component. This will make debugging easier, as well as =
=0A>=0A>As an example, using an SPL-based exception:=0A>=0A>    try {=0A>  =
      throw new InvalidArgumentException();=0A>    } catch (\zend\foo\Excep=
tion $e) {        // or=0A>    } catch (\zend\Exception $e) {            //=
 or=0A>    } catch (\InvalidArgumentException $e) {  // or=0A>    } catch (=
\Exception $e) {=0A>    }=0A>=0A>All are viable - it gives you, the develop=
er, more choices in how you=0A>handle exceptions.=0A>=0ASo we're trying to =
add an extra catch-case for zend specific=0Aexceptions? If so dont we alrea=
dy have Zend_Exception? I don't see any=0Areason not to do this, but then, =
I'm not sure its really necessary?=0AWith autoloading the overhead should b=
e relatively small (classes arent=0Acomputed till needed)... so... whatever=
?=0A=0A=0AUmmmmm.... I don't think we're talking about the same thing here.=
=0A>=0AWe are.=0A=0ADesign by contract, in its most simplified form, refers=
 to the idea of=0A>programming to interfaces. This simply means that we'll =
be ensuring that=0A>we have solid, concise interfaces for each component, w=
hich will allow=0A>developers to create their own implementations when they=
're needs=0A>deviate from those shipped.=0A>=0A>=0AThe issue is that progra=
mming by contract adds little value when=0Aapplied universally (i've got so=
me really nasty db-binding interfaces=0Agrowing around here)=0A=0AInterface=
s are useful sure, but like tests, they're only useful when=0Awritten from =
a different perspective than the implementation. My=0Aattempt to fix a bug =
in zend's wildfire layer only to run into a case=0Awhere a test checked for=
 not implemented as a response being a prime=0Aexample. The same will happe=
n with rigid interfaces as with rigid tests.=0A=0AI strongly suggest only u=
sing interfaces where there are actual points=0Aof interoperability, instea=
d of for each public method for example.=0A=0AThis actually will have some =
substantial benefits. First, we can have a=0A>more conventions based approa=
ch, which allows us to develop more=0A>targetted, performant code since we'=
re no longer worrying about edge=0A>cases created by configurability. This =
brings me to my second point: it=0A>pushes the burden of custom and fringe =
use cases onto individual=0A>developers instead of the framework -- which a=
llows us to focus on=0A>maintaining the core functionality. This will lead =
to a better product=0A>with fewer open issues. Third, it makes testing much=
 easier,=0A>particularly when considering components with adapters -- you c=
an=0A>implement a given interface in order to test the functionality instea=
d=0A>of needing to override an existing class.=0A>=0AI agree that it makes =
testing easier, but disagree that it leads to=0Aperformance. Loading large =
interfaces (picture the size of an interface=0Afor Zend_Pdf or Zend_Db for =
examples) .... really adds to loading=0Aoverhead.  Also, if you start reall=
y talking about interfaces and DI,=0Ayou get into a lot of runtime use of t=
he instanceof operator -- and=0Athat saps performance too.=0A=0AIn terms of=
 contribution overhead, it means that part of any component=0A>design will =
be ascertaining the basic, essential functionality and=0A>creating an inter=
face that encapsulates it; this is just good=0A>programming.=0A>=0AThis is =
where it will get in the way. Now not only do you have to write=0Athe code =
you want to contribute (something many of us do as an=0Aancillary benefit t=
o 'Actually Getting Stuff Done') but also an=0AInterface, Tests, Documentat=
ion and probably some ZF tracker stuff.=0AWow, overhead. I don't have time =
for it -- and I'm not alone in that, I=0Aassure you. Don't get me wrong, it=
s nice to have all those things, but=0Anot at the expense of the actual fun=
ctionality getting checked in.=0AMaybe I'm ****ing in the wind, but can we =
try to lower the contribution=0Aoverhead? I'm willing to send in commented,=
 code-level patches as I go=0Aabout my normal dev, but those who sponsor th=
at work aren't willing to=0Apay for me to write tests and docs for the stuf=
f I improve. This leads=0Ato most of my zfw improvements going uncontribute=
d, or when they=0Aencompass major libs, forked off from the core and releas=
ed=0Aindependently where they don't do as many people as good as they could=
=0Aif they were part of zfw. =0A=0A=0ABasically, everything you cite as pot=
ential problems are actually=0A>addressed with this decision=0A>=0A4) Getti=
ng rid of singletons.=0A>>=0A>>Why does it make more sense to access the fr=
ont controller via a registry?=0A>>Surely this can't meet the 80/20 rule? K=
eep the singletons, they make it easier=0A>>to pick up the framework.=0A>>=
=0A>We're not accessing the front controller via a registry. It's simply no=
t=0A>going to be a singleton. The ideas posted use injection to pass object=
s=0A>around, and do so in a very simple manner. Take a look at the=0A>proof=
-of-concept I posted before jumping to conclusions.=0A>=0A>Singletons have =
been the source of a ton of pain in testing and=0A>bugfixing -- and there's=
 very little reason for most of them to exist.=0A>=0A>=0AI'm poking around =
in it, but I'm not sure I see how 'the' front=0Acontroller will be accessed=
. Whats the equivilent call to=0AZend_Controller_Front::getInstance().... s=
omewhere's gonna have to be a=0Aregistry (or at least a responsible object)=
 if thats not singleton-ized.=0A=0AI'm looking at =0Ahttp://github.com/weie=
rophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php=0Afor ex=
ample, and I definitely don't think this is easier to grasp than=0Athe sing=
leton fc approach.=0A=0AThe Ugly:=0A>>=0A>>The proposed changes to the core=
 api (and to a large extent the framework=0A>>additions since 1.0) really a=
dd complexity to the framework to the benefit of=0A>>testing and other 'adv=
anced' use. =0A>>=0A>We're getting rid of complexity and focussing on a sim=
plified,=0A>consistent API. I fail to see how you're reaching your conclusi=
ons.=0A>=0AMaybe you see it that way... I'm not sure I do. The DI stuff is=
=0Adefinitely not straightforward compared to whats there now. The comment=
=0Arefers to the new things since 1.0 really that haven't helped make=0Athi=
ngs better. See the end of (a) below. The <=3D1.0 line was dead=0Asimple, w=
asn't much use of helpers, plugins, brokers, registries etc...=0Aeverything=
 kinda flowed from a->b->c and it was more mvc-ish in=0Aits code separation=
. now its definitely a lot more RDMVCHP..=0A(router-dispatcher-model-view-c=
ontroller-helper-plugin) ... add a few=0Alayers of Zend_Application+Zend_Co=
nfig integration and the like and it=0Agets even worse.=0A=0A=0A  =0A>These=
 changes do little, if anything to advance three goals I see as=0A>>core re=
quirements for 2.0:=0A>>=0A>>a) Can a skilled PHP developer read and unders=
tand Zend Framework application=0A>>code without more than an hour's primer=
 on ZFW? Could they trace execution of=0A>>the framework logically without =
a debugger? Jumps like GOTO's, fancy routers,=0A>>registries, helpers, plug=
ins, and DI models all work against this goal. Keep it=0A>>simple.=0A>>=0A>=
Please, please, please read the code and examples before you make these=0A>=
assumptions.=0A>=0AI have read what is linked from that page you posted. So=
 some of this=0Amight be assumption, but im not sure much is.=0A=0AThe new =
MVC design is not going to be something a developer will need to=0A>underst=
and in order to use it; they will simply need to *use* it.=0AI don't agree =
with this. IMHO, If you can't trace it under the hood --=0Ait's too complic=
ated. I can't stress enough how important it is for=0Apeople working with Z=
FW to actually =0Aunderstand how ZFW works, and to be able to trace their a=
pplication's=0Aexecution conceptually. PHP isn't an SDK language and ZFW sh=
ouldn't aim=0Ato be a SDK framework. The whole execution process should fol=
low an=0Aeasily traced path from start to finish.=0A=0A=0A They won't need =
to know that it uses a finite state machine under the hood --=0A>they'll on=
ly need to know what events and states are available (and=0A>there's *ahem*=
 a finite number of them). Tracing the code execution=0A>should rarely be n=
ecessary, but the new prototype is actually far, far=0A>simpler than the cu=
rrent Zend_Controller execution cycle.=0A>=0AI disagree. I think its import=
ant that the average user can _easily_=0Aunderstand how the application wor=
ks through all phases of execution.=0A=0A=0Ab) Can a skilled PHP developer =
contribute a change to the framework easily=0A>>without being involved in t=
he ZFW core politics, contribution processes,=0A>>proposal processes, test =
writing, doc writing, etc. Currently, ZFW sucks for=0A>>this, but didn't un=
til after the 1.0 line was out. What will ZFW 2.0 do to=0A>>reduce the cont=
ribution overhead and encourage community participation?=0A>>=0A>Please ela=
borate on how "ZFW sucks for this."=0AOur policy has been that contribution=
s require unit tests and=0A>documentation, plain and simple. Yes, it's a ba=
rrier to entry -- but it=0A>also helps to ensure the quality of the code an=
d that users have the=0A>information they need to use it. If we don't requi=
re that level of=0A>contribution, we'll be doing everyone a dis-service.=0A=
Right now, there really are no "core politics". Everything goes through=0A>=
the contribution process. Yes, myself and my team help determine the=0A>roa=
dmap -- but even the roadmap is open for discussion. This is open=0A>source=
.=0A>=0A>=0ASee previous comments on the interface stuff. Same stuff applie=
s.=0A=0A=0Ac) Can a ZFW developer create products and services that leverag=
e ZFW in an=0A>>ecosystem of components? Is there a financial incentive for=
 this? Currently,=0A>>there's very little going on in terms of commercializ=
ed redistributable=0A>>components -- How will ZFW 2.0 create, and integrate=
 itself into a marketplace=0A>>for ZFW apps, components, and tools? Officia=
l ZFW app/component store? ZFW=0A>>cloud services?=0A>>=0A>My team has had =
zero time to focus on a forge-like site for components,=0A>though it's some=
thing we'd all like to see.  A large part of the reason=0A>for our lack of =
time is due to the amount of maintenance required on ZF.=0A>Most of the cha=
nges proposed for 2.0 are intended to lighten that=0A>burden, which would m=
ake the above much more possible in the future.=0A>=0AFair enough, though, =
I'm less concerned with the 'forge' site and more=0Aconcerned about flushin=
g out the component model (packs, modules,=0Aphars?, plugins... what are we=
 calling an encapsulated archive of zfw=0A'stuff' now). That should definit=
ely be considered pre-2.0 as it will=0Arequire considerations on everything=
 from routers, dispatchers,=0Alayouts, controllers and views.=0A=0A  =0A>Th=
e Atrocious:=0A>>=0A>>Still nothing about an upgrading / security patches s=
ystem. =0A>>=0A>This is my bad -- I meant to include information on this as=
 part of the=0A>proposal. A big effort for 2.0 will be creating resources t=
o aid in=0A>migration. A big part of the MVC proof of concept was creating =
something=0A>that could live side-by-side the current implementation and po=
tentially=0A>even make use of it (the demo uses a number of existing compon=
ents).=0A>We're taking that very seriously.=0A>=0A:) Glad to hear this.=0A=
=0AAs for security patches, the plan is to patch existing stable code, as=
=0A>well as the previous 2 minor branches, and make releases of each.=0A>=
=0AA good first step as I said below, but we need the USN's, the 'is this=
=0Asite afflicted' data. (Eg does line x of /library/zend/whatever.php =3D=
=0Athis, if so, vuln)... we need this type of data on an ongoing basis to=
=0Abuild out the tools -> see below..=0A=0A=0A  =0A>Still no components for=
 detecting if an application is vulnerable,=0A>>notifying system admins, or=
 shutting down an installed base of=0A>>vulnerable apps dependent on the fr=
amework.  If the problems of the=0A>>other major framework and cms vendors =
continue to be ignored, there=0A>>will almost certainly be some sort of inc=
ident that will tarnish the=0A>>frameworks reputation for security. At some=
 point the framework is=0A>>going to have to take version management more s=
eriously than=0A>>publishing patches to the website (a good first step, but=
 miles away=0A>>from where it needs to be).=0A>>=0A>If you're interested in=
 such components, then please help make them a=0A>possibility. Don't expect=
 everyone else to do the work for you. As=0A>noted, my team is small and ou=
r resources spread thin. Help us and the=0A>rest of the community out.=0A>=
=0AI don't expect them to, and I've been trying to help get this done for=
=0Asome time. That said, theres no tool I can make without vulnerability=0A=
data. There's no disclosure list, no feed or web service that we could=0Asc=
ript against. This has to come from the release management side of=0Athings=
. I've had some productive discussions about doing the scripting=0Awithin t=
he Zend_Tool framework -- but thats as far as it gets.=0A=0AIf you publish =
the data, I'll write the tools (though, i'll leave it to=0Ayour team to wri=
te the tests <grin>)=0A=0AIdeally a csv (or xml) like....=0A=0AZFV (zend fr=
amework vulnerability) Number  | File | Line | Match |=0APatch | Remarks=0A=
ZFV-123 | library/Zend/Whatever.php | 12 | if($this->somethingIsBad)=0A| ZF=
V-123.patch | You'll have to also change your bootstrap from this=0Ato that=
. =0A=0AGiven that, we can write sites, and potentially tools that would ch=
eck=0Athemselves automatically.=0A=0AI've previously proposed adding this t=
o Zend_Version, but maybe theres=0Aa more appropriate place?  IMHO this sho=
uld be a 2.0 line build=0Arequirement. =0A=0A=0A=0A--=0A>>=0A>>I'd also add=
 that there's probably an opportunity to look at phar-ization=0A>>within th=
e 2.0 line. Will the new loader support phar'd components, and how=0A>>will=
 that look? Zend_Tool? Configurable site images?=0A>>=0A>I've already exper=
imented with Phar and ZF 1.X. It requires minimal=0A>changes to the autoloa=
der for it to work out of the box.=0A>=0AOooOOo gimme gimme.... Docs, blog =
post? How does it work with=0Aoverlaying views, layouts, controllers, model=
s, extending/replacing=0Acore zend libraries, etc?=0A=0AAnyway, hope that e=
laborates and is more helpful than it is not =3DP=0A=0AKevin
--0-1159218232-1258069511=:9816
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">We should probably get rid of the "design by contract" termino=
logy - many of us will take it at face value as referring to the software e=
ngineering concept with all the bells and whistles attached.<br><br>&gt;Thi=
s is where it will get in the way. Now not only do you have to write the co=
de you want to contribute <br>&gt;(something many of us do as an ancillary =
benefit to 'Actually Getting Stuff Done') but also an Interface, <br>&gt;Te=
sts, Documentation and probably some ZF tracker stuff. Wow, overhead. I don=
't have time for it -- and <br>&gt;I'm not alone in that, I assure you. Don=
't get me wrong, its nice to have all those things, but not at <br>&gt;the =
expense of the actual functionality getting checked in. Maybe I'm ****ing i=
n the wind, but can we try <br>&gt;to lower the contribution overhead?
 I'm willing to send in commented, code-level patches as I go about my<br>&=
gt;normal dev, but those who sponsor that work aren't willing to pay for me=
 to write tests and docs for the <br>&gt;stuff I improve. This leads to mos=
t of my zfw improvements going uncontributed, or when they encompass <br>&g=
t;major libs, forked off from the core and released independently where the=
y don't do as many people as <br>&gt;good as they could if they were part o=
f zfw. <br><br>To be honest, I don't follow Kevin's objections. Every line =
of code written is a constant fight between two metrics - performance and f=
lexibility. Interfaces assist flexibility by allowing for substitution - an=
 amazingly powerful capability in a framework (as a certain framework outsi=
de of PHP has quickly learned with a little prompting from a more flexible =
sibling). Eliminating flexibility for the sake of performance is a dangerou=
s road to follow blindly. Conventions play a role in minimising the
 risks, and experience eliminates the remainder - and this is exactly what =
Matthew is identifying. With a few years of ZF 1.0 behind us, 2.0 can balan=
ce both a lot better where it really really counts.<br><br>The main wall Ke=
vin just hit is simply never going away. If it ever did, ZF wouldn't be far=
 behind it as a untested, undocumented morass of code that (allegedly) does=
 stuff. We need all the "contribution overhead". It is absolutely essential=
. There are components in the ZF which, to be generous, are pretty bad in t=
erms of testing, documentation and flexibility already - and that's with th=
e requirement! I have worse descriptions. Catch me on IRC during a bug hunt=
 and I'll share some ;).<br><br>The fact is, if you cannot handle the addit=
ional work that underpins, supports and ensures ease of maintenance for a c=
omponent - then you are begging for a developer to start swearing over IRC.=
 I had the joy of dealing with such a component a few weeks back. It
 took me hours to figure out a bug. Why? Because the unit tests DID NOT TES=
T the functionality of the component. I could have deleted every single tes=
t with no ill effect - they were all busy with XML parsing or something (pe=
rformed by a completely different component with its own perfectly function=
al unit tests).<br><br>But worse than all this, is the assumption that lowe=
ring the contribution overhead is a positive thing. It's not - it merely sh=
ifts that work onto someone else. Someone else with precious little time an=
d a chargeout rate to justify work with. And surprise - they won't like tha=
t in the slightest. Sometimes you get lucky - I spent about 10 hours of oth=
erwise chargeable time in September's bug hunt (which I enjoyed a lot by th=
e way) along with several evenings but generally everyday work will always =
lean towards ignoring contributions where no supporting "contribution overh=
ead" has also been committed. Such contributions/patches/whatever
 can be horrible to work on. No tests, poor explanations, lack of communica=
tion, differing assumptions - ugh. If it's not worth contributing in full, =
don't expect someone else to do it - they probably won't.<br><br>Sorry for =
the ranty piece - but code doesn't write itself. It is great to have a cont=
ribution - so long as you don't pin it all on someone else ;).<br><br>&gt;I=
nterfaces are useful sure, but like tests, they're only useful when written=
 from a different perspective <br>&gt;than the implementation. My attempt t=
o fix a bug in zend's wildfire layer only to run into a case where a <br>&g=
t;test checked for not implemented as a response being a prime example. The=
 same will happen with rigid <br>&gt;interfaces as with rigid tests.<br><br=
>Interfaces are supposed to be rigid. What Matthew is attempting to emphasi=
s to you is that an interface should address the "core" functionality. Addi=
ng interface defs for every single public method is all too common,
 and all too unnecessary.<br><br>If you described the example a bit, it mig=
ht help you see what is being aimed at here - and where that wildfire compo=
nent probably went awry.<br><br>&gt;I agree that it makes testing easier, b=
ut disagree that it leads to performance. Loading large interfaces <br>&gt;=
(picture the size of an interface for Zend_Pdf or Zend_Db for examples) ...=
. really adds to loading <br>&gt;overhead.&nbsp; Also, if you start really =
talking about interfaces and DI, you get into a lot of runtime use <br>&gt;=
of the instanceof operator -- and that saps performance too.<br><br>Missing=
 the point. Interfaces are rigid - less scope for edge cases, mishaps, misu=
nderstandings - i.e. the resulting code can afford to be leaner, focused an=
d (by praying to XDebug and sacrificing goats on the alter of "try, try aga=
in") hopefully be more performant.<br><br>&gt;&gt;In terms of contribution =
overhead, it means that part of any component<br>&gt;&gt;design will
 be ascertaining the basic, essential functionality and<br>&gt;&gt;creating=
 an interface that encapsulates it; this is just good<br>&gt;&gt;programmin=
g.<br>&gt;<br>&gt;This is where it will get in the way. [...]<br><br>No, th=
is is where it's supposed to begin. If, like me, you are a total TDD fanboy=
 ;). In TDD, the API comes first. From the targeted API flows the Interface=
. From the Interface flows an obedient implementing class. Granted it's a v=
ery specific methodology I'm using as an example. For someone using TDD, an=
 Interface is almost a certainty - it will warp and change over time but th=
at evolution will reflect the very core functionality of the implementation=
. Even without TDD, that should be pretty common - where else is the API co=
ming from?<br><br>&gt;I'm poking around in it, but I'm not sure I see how '=
the' front controller will be accessed. Whats the <br>&gt;equivilent call t=
o Zend_Controller_Front::getInstance().... somewhere's gonna have to
 be a registry (or <br>&gt;at least a responsible object) if thats not sing=
leton-ized.<br><br>Which one? Nobody said there would be one front controll=
er. My guess, is that it will be accessible from your bootstrap, which is r=
egistered to the front controller, which is registered to...I'm lost now. I=
t will be injected into wherever it tends to be most useful. Just not globa=
lly as a singleton. Bear in the current singleton usage encourages a disreg=
ard for injection - which is used by the other 99% of inputs into classes l=
ike helpers, plugins, etc. Replace Frontcontroller with any other component=
 - you should get the same answer for the new Frontcontroller. It's not som=
e oddball, hyper-weird class that needs special treatment.<br><br>&gt;The D=
I stuff is definitely not straightforward compared to whats there now.<br><=
br>What's there right now is DI - as a patchwork of different approaches ho=
wever which make the APIs more unpredictable than they should be. If
 you mean a DI Framework - pretty sure that is not on the agenda. The close=
st to a DI Framework is Zend_Application - which is stretching that concept=
 an awful lot.<br><br>&gt;I don't agree with this. IMHO, If you can't trace=
 it under the hood -- it's too complicated. I can't <br>&gt;stress enough h=
ow important it is for people working with ZFW to actually<br>&gt;understan=
d how ZFW works, and to be able to trace their application's execution conc=
eptually. PHP isn't <br>&gt;an SDK language and ZFW shouldn't aim to be a S=
DK framework. The whole execution process should follow an <br>&gt;easily t=
raced path from start to finish.<br><br>Trace what under the hood? Request-=
&gt;Route-&gt;Dispatch-&gt;Controller-&gt;Action &lt;- stick plugins in bet=
ween. It's not rocket science. If you doubled the complexity of the impleme=
ntation today, it would still quack like the same duck it was yesterday. Ri=
ght now you can still conceptually grasp MVC and use it, without
 ever reading the source code. In fact, right now MVC is a pretty complex b=
east in ZF. It would take a serious effort to complicate it further :).<br>=
<br>&gt;Can a skilled PHP developer contribute a change to the framework ea=
sily<br>&gt;without being involved in the ZFW core politics, contribution p=
rocesses,<br>&gt;proposal processes, test writing, doc writing, etc.<br><br=
>ZF may be one of the few non-political projects around. I've had some fun =
of course butting heads in the past, but the last two years have been polit=
ics free. Everything else is answered "no". Who else is going to miraculous=
ly write someone else's tests/docs/proposals? Not me :P.<br><br>Paddy.<br><=
div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-=
family: times new roman,new york,times,serif;" size=3D"3"><span style=3D"fo=
nt-weight: bold;">P=E1draic Brady<br><br></span></font><span style=3D"font-=
style: italic;"><font style=3D"font-family: times new roman,new
 york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=
=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a re=
l=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com">=
http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_blan=
k" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Repr=
esentative</a><br></font></span></span><div><br></div><div style=3D"font-fa=
mily: times new roman,new york,times,serif; font-size: 12pt;"><br><div styl=
e=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;"><=
font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font-weigh=
t: bold;">From:</span></b> Kevin McArthur &lt;[email-masked]&gt;<br><b>=
<span style=3D"font-weight: bold;">To:</span></b> [email-masked]=
d.com<br><b><span style=3D"font-weight: bold;">Sent:</span></b> Thu, Novemb=
er 12, 2009 9:41:59 PM<br><b><span style=3D"font-weight: bold;">Subject:</s=
pan></b> Re: [zf-contributors]
 Zend Framework 2.0 Roadmap<br></font><br>=0A<meta http-equiv=3D"x-dns-pref=
etch-control" content=3D"off">=0A=0A=0A  =0A=0AReply inline.<br>=0A<br>=0AM=
atthew Weier O'Phinney wrote:=0A<blockquote type=3D"cite">&lt;snip&gt;<br>=
=0A  <pre>That makes sense, and I'm open to that. <br><br>That said, if a c=
omponent has dependencies on other components or makes<br>use of other comp=
onents, I think the pattern should be mandatory.<br>Dependency Injection --=
 note, I'm NOT saying DI containers -- is much<br>simpler with this pattern=
.<br><br>  </pre>=0A</blockquote>=0A<pre>Can we define components? Classes =
within their own namespace? If so, I'm cool with that. Off the top of my he=
ad my main thinking is like PDF Points, Rects, Cirlces etc... these make no=
 sense to be 'configurable'. But they all exist within their own namespace.=
  Configuration standards when crossing namespaces... that makes sense.<br>=
</pre>=0A<blockquote type=3D"cite">=0A  <pre>The rationale is because it al=
lows us to catch either based on the SPL<br>exception type OR the component=
 exception type. It's more flexible.<br><br>Each component Exception would =
inherit from the zend\Exception marker<br>interface -- so, again, there'd s=
till be the Exception inheritance<br>hierarchy, but also a hierarchy for ge=
neral purpose exceptions.<br><br>Finally, the paradigm encourages creating =
exceptions for each type of<br>exceptional situation, instead of having a g=
eneric exception per<br>component. This will make debugging easier, as well=
 as <br><br>As an example, using an SPL-based exception:<br><br>    try {<b=
r>        throw new InvalidArgumentException();<br>    } catch (\zend\foo\E=
xception $e) {        // or<br>    } catch (\zend\Exception $e) {          =
  // or<br>    } catch (\InvalidArgumentException $e) {  // or<br>    } cat=
ch (\Exception $e) {<br>    }<br><br>All are viable - it gives you, the dev=
eloper, more choices in how
 you<br>handle exceptions.<br>  </pre>=0A</blockquote>=0ASo we're trying to=
 add an extra catch-case for zend specific=0Aexceptions? If so dont we alre=
ady have Zend_Exception? I don't see any=0Areason not to do this, but then,=
 I'm not sure its really necessary?=0AWith autoloading the overhead should =
be relatively small (classes arent=0Acomputed till needed)... so... whateve=
r?<br>=0A<br>=0A<blockquote type=3D"cite">=0A  <pre>Ummmmm.... I don't thin=
k we're talking about the same thing here.<br>  </pre>=0A</blockquote>=0AWe=
 are.<br>=0A<blockquote type=3D"cite">=0A  <pre>Design by contract, in its =
most simplified form, refers to the idea of<br>programming to interfaces. T=
his simply means that we'll be ensuring that<br>we have solid, concise inte=
rfaces for each component, which will allow<br>developers to create their o=
wn implementations when they're needs<br>deviate from those shipped.<br><br=
>  </pre>=0A</blockquote>=0AThe issue is that programming by contract adds =
little value when=0Aapplied universally (i've got some really nasty db-bind=
ing interfaces=0Agrowing around here)<br>=0A<br>=0AInterfaces are useful su=
re, but like tests, they're only useful when=0Awritten from a different per=
spective than the implementation. My=0Aattempt to fix a bug in zend's wildf=
ire layer only to run into a case=0Awhere a test checked for not implemente=
d as a response being a prime=0Aexample. The same will happen with rigid in=
terfaces as with rigid tests.<br>=0A<br>=0AI strongly suggest only using in=
terfaces where there are actual points=0Aof interoperability, instead of fo=
r each public method for example.<br>=0A<blockquote type=3D"cite">=0A  <pre=
>This actually will have some substantial benefits. First, we can have a<br=
>more conventions based approach, which allows us to develop more<br>target=
ted, performant code since we're no longer worrying about edge<br>cases cre=
ated by configurability. This brings me to my second point: it<br>pushes th=
e burden of custom and fringe use cases onto individual<br>developers inste=
ad of the framework -- which allows us to focus on<br>maintaining the core =
functionality. This will lead to a better product<br>with fewer open issues=
. Third, it makes testing much easier,<br>particularly when considering com=
ponents with adapters -- you can<br>implement a given interface in order to=
 test the functionality instead<br>of needing to override an existing class=
.<br>  </pre>=0A</blockquote>=0AI agree that it makes testing easier, but d=
isagree that it leads to=0Aperformance. Loading large interfaces (picture t=
he size of an interface=0Afor Zend_Pdf or Zend_Db for examples) .... really=
 adds to loading=0Aoverhead.&nbsp; Also, if you start really talking about =
interfaces and DI,=0Ayou get into a lot of runtime use of the instanceof op=
erator -- and=0Athat saps performance too.<br>=0A<blockquote type=3D"cite">=
=0A  <pre>In terms of contribution overhead, it means that part of any comp=
onent<br>design will be ascertaining the basic, essential functionality and=
<br>creating an interface that encapsulates it; this is just good<br>progra=
mming.<br>  </pre>=0A</blockquote>=0AThis is where it will get in the way. =
Now not only do you have to write=0Athe code you want to contribute (someth=
ing many of us do as an=0Aancillary benefit to 'Actually Getting Stuff Done=
') but also an=0AInterface, Tests, Documentation and probably some ZF track=
er stuff.=0AWow, overhead. I don't have time for it -- and I'm not alone in=
 that, I=0Aassure you. Don't get me wrong, its nice to have all those thing=
s, but=0Anot at the expense of the actual functionality getting checked in.=
=0AMaybe I'm ****ing in the wind, but can we try to lower the contribution=
=0Aoverhead? I'm willing to send in commented, code-level patches as I go=
=0Aabout my normal dev, but those who sponsor that work aren't willing to=
=0Apay for me to write tests and docs for the stuff I improve. This leads=
=0Ato most of my zfw improvements going uncontributed, or when they=0Aencom=
pass major libs, forked off from the core and released=0Aindependently wher=
e they don't do as many people as good as they could=0Aif they were part of=
 zfw. <br>=0A<br>=0A<blockquote type=3D"cite">=0A  <pre>Basically, everythi=
ng you cite as potential problems are actually<br>addressed with this decis=
ion<br>  </pre>=0A</blockquote>=0A<blockquote type=3D"cite">=0A  <blockquot=
e type=3D"cite">=0A    <pre>4) Getting rid of singletons.<br><br>Why does i=
t make more sense to access the front controller via a registry?<br>Surely =
this can't meet the 80/20 rule? Keep the singletons, they make it easier<br=
>to pick up the framework.<br>    </pre>=0A  </blockquote>=0A  <pre>We're n=
ot accessing the front controller via a registry. It's simply not<br>going =
to be a singleton. The ideas posted use injection to pass objects<br>around=
, and do so in a very simple manner. Take a look at the<br>proof-of-concept=
 I posted before jumping to conclusions.<br><br>Singletons have been the so=
urce of a ton of pain in testing and<br>bugfixing -- and there's very littl=
e reason for most of them to exist.<br><br>  </pre>=0A</blockquote>=0AI'm p=
oking around in it, but I'm not sure I see how 'the' front=0Acontroller wil=
l be accessed. Whats the equivilent call to=0AZend_Controller_Front::getIns=
tance().... somewhere's gonna have to be a=0Aregistry (or at least a respon=
sible object) if thats not singleton-ized.<br>=0A<br>=0AI'm looking at <br>=
<span>=0A<a target=3D"_blank" href=3D"http://github.com/weierophinney/phly/=
blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php">http://github.com/weie=
rophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php</a></spa=
n><br>=0Afor example, and I definitely don't think this is easier to grasp =
than=0Athe singleton fc approach.<br>=0A<blockquote type=3D"cite">=0A  <pre=
></pre>=0A  <blockquote type=3D"cite">=0A    <pre>The Ugly:<br><br>The prop=
osed changes to the core api (and to a large extent the framework<br>additi=
ons since 1.0) really add complexity to the framework to the benefit of<br>=
testing and other 'advanced' use. <br>    </pre>=0A  </blockquote>=0A  <pre=
>We're getting rid of complexity and focussing on a simplified,<br>consiste=
nt API. I fail to see how you're reaching your conclusions.<br>  </pre>=0A<=
/blockquote>=0AMaybe you see it that way... I'm not sure I do. The DI stuff=
 is=0Adefinitely not straightforward compared to whats there now. The comme=
nt=0Arefers to the new things since 1.0 really that haven't helped make<br>=
=0Athings better. See the end of (a) below. The &lt;=3D1.0 line was dead=0A=
simple, wasn't much use of helpers, plugins, brokers, registries etc...=0Ae=
verything kinda flowed from a-&gt;b-&gt;c and it was more mvc-ish in=0Aits =
code separation. now its definitely a lot more RDMVCHP..=0A(router-dispatch=
er-model-view-controller-helper-plugin) ... add a few=0Alayers of Zend_Appl=
ication+Zend_Config integration and the like and it=0Agets even worse.<br>=
=0A<br>=0A<blockquote type=3D"cite">=0A  <pre>  </pre>=0A  <blockquote type=
=3D"cite">=0A    <pre>These changes do little, if anything to advance three=
 goals I see as<br>core requirements for 2.0:<br><br>a) Can a skilled PHP d=
eveloper read and understand Zend Framework application<br>code without mor=
e than an hour's primer on ZFW? Could they trace execution of<br>the framew=
ork logically without a debugger? Jumps like GOTO's, fancy routers,<br>regi=
stries, helpers, plugins, and DI models all work against this goal. Keep it=
<br>simple.<br>    </pre>=0A  </blockquote>=0A  <pre>Please, please, please=
 read the code and examples before you make these<br>assumptions.<br>  </pr=
e>=0A</blockquote>=0AI have read what is linked from that page you posted. =
So some of this=0Amight be assumption, but im not sure much is.<br>=0A<bloc=
kquote type=3D"cite">=0A  <pre>The new MVC design is not going to be someth=
ing a developer will need to<br>understand in order to use it; they will si=
mply need to *use* it.</pre>=0A</blockquote>=0AI don't agree with this. IMH=
O, If you can't trace it under the hood --=0Ait's too complicated. I can't =
stress enough how important it is for=0Apeople working with ZFW to actually=
 <br>=0Aunderstand how ZFW works, and to be able to trace their application=
's=0Aexecution conceptually. PHP isn't an SDK language and ZFW shouldn't ai=
m=0Ato be a SDK framework. The whole execution process should follow an=0Ae=
asily traced path from start to finish.<br>=0A<br>=0A<blockquote type=3D"ci=
te">=0A  <pre> They won't need to know that it uses a finite state machine =
under the hood --<br>they'll only need to know what events and states are a=
vailable (and<br>there's *ahem* a finite number of them). Tracing the code =
execution<br>should rarely be necessary, but the new prototype is actually =
far, far<br>simpler than the current Zend_Controller execution cycle.<br>  =
</pre>=0A</blockquote>=0AI disagree. I think its important that the average=
 user can _easily_=0Aunderstand how the application works through all phase=
s of execution.<br>=0A<br>=0A<blockquote type=3D"cite">=0A  <pre></pre>=0A =
 <blockquote type=3D"cite">=0A    <pre>b) Can a skilled PHP developer contr=
ibute a change to the framework easily<br>without being involved in the ZFW=
 core politics, contribution processes,<br>proposal processes, test writing=
, doc writing, etc. Currently, ZFW sucks for<br>this, but didn't until afte=
r the 1.0 line was out. What will ZFW 2.0 do to<br>reduce the contribution =
overhead and encourage community participation?<br>    </pre>=0A  </blockqu=
ote>=0A  <pre>Please elaborate on how "ZFW sucks for this."</pre>=0A</block=
quote>=0A<blockquote type=3D"cite">=0A  <pre>Our policy has been that contr=
ibutions require unit tests and<br>documentation, plain and simple. Yes, it=
's a barrier to entry -- but it<br>also helps to ensure the quality of the =
code and that users have the<br>information they need to use it. If we don'=
t require that level of<br>contribution, we'll be doing everyone a dis-serv=
ice.</pre>=0A</blockquote>=0A<blockquote type=3D"cite">=0A  <pre>Right now,=
 there really are no "core politics". Everything goes through<br>the contri=
bution process. Yes, myself and my team help determine the<br>roadmap -- bu=
t even the roadmap is open for discussion. This is open<br>source.<br><br> =
 </pre>=0A</blockquote>=0A<pre></pre>=0ASee previous comments on the interf=
ace stuff. Same stuff applies.<br>=0A<br>=0A<blockquote type=3D"cite">=0A  =
<blockquote type=3D"cite">=0A    <pre>c) Can a ZFW developer create product=
s and services that leverage ZFW in an<br>ecosystem of components? Is there=
 a financial incentive for this? Currently,<br>there's very little going on=
 in terms of commercialized redistributable<br>components -- How will ZFW 2=
.0 create, and integrate itself into a marketplace<br>for ZFW apps, compone=
nts, and tools? Official ZFW app/component store? ZFW<br>cloud services?<br=
>    </pre>=0A  </blockquote>=0A  <pre>My team has had zero time to focus o=
n a forge-like site for components,<br>though it's something we'd all like =
to see.  A large part of the reason<br>for our lack of time is due to the a=
mount of maintenance required on ZF.<br>Most of the changes proposed for 2.=
0 are intended to lighten that<br>burden, which would make the above much m=
ore possible in the future.<br>  </pre>=0A</blockquote>=0AFair enough, thou=
gh, I'm less concerned with the 'forge' site and more=0Aconcerned about flu=
shing out the component model (packs, modules,=0Aphars?, plugins... what ar=
e we calling an encapsulated archive of zfw=0A'stuff' now). That should def=
initely be considered pre-2.0 as it will=0Arequire considerations on everyt=
hing from routers, dispatchers,=0Alayouts, controllers and views.<br>=0A<bl=
ockquote type=3D"cite">=0A  <pre>  </pre>=0A  <blockquote type=3D"cite">=0A=
    <pre>The Atrocious:<br><br>Still nothing about an upgrading / security =
patches system. <br>    </pre>=0A  </blockquote>=0A  <pre>This is my bad --=
 I meant to include information on this as part of the<br>proposal. A big e=
ffort for 2.0 will be creating resources to aid in<br>migration. A big part=
 of the MVC proof of concept was creating something<br>that could live side=
-by-side the current implementation and potentially<br>even make use of it =
(the demo uses a number of existing components).<br>We're taking that very =
seriously.<br>  </pre>=0A</blockquote>=0A:) Glad to hear this.<br>=0A<block=
quote type=3D"cite">=0A  <pre>As for security patches, the plan is to patch=
 existing stable code, as<br>well as the previous 2 minor branches, and mak=
e releases of each.<br>  </pre>=0A</blockquote>=0AA good first step as I sa=
id below, but we need the USN's, the 'is this=0Asite afflicted' data. (Eg d=
oes line x of /library/zend/whatever.php =3D=0Athis, if so, vuln)... we nee=
d this type of data on an ongoing basis to=0Abuild out the tools -&gt; see =
below..<br>=0A<br>=0A<blockquote type=3D"cite">=0A  <pre>  </pre>=0A  <bloc=
kquote type=3D"cite">=0A    <pre>Still no components for detecting if an ap=
plication is vulnerable,<br>notifying system admins, or shutting down an in=
stalled base of<br>vulnerable apps dependent on the framework.  If the prob=
lems of the<br>other major framework and cms vendors continue to be ignored=
, there<br>will almost certainly be some sort of incident that will tarnish=
 the<br>frameworks reputation for security. At some point the framework is<=
br>going to have to take version management more seriously than<br>publishi=
ng patches to the website (a good first step, but miles away<br>from where =
it needs to be).<br>    </pre>=0A  </blockquote>=0A  <pre>If you're interes=
ted in such components, then please help make them a<br>possibility. Don't =
expect everyone else to do the work for you. As<br>noted, my team is small =
and our resources spread thin. Help us and the<br>rest of the community out=
.<br>  </pre>=0A</blockquote>=0AI don't expect them to, and I've been tryin=
g to help get this done for=0Asome time. That said, theres no tool I can ma=
ke without vulnerability=0Adata. There's no disclosure list, no feed or web=
 service that we could=0Ascript against. This has to come from the release =
management side of=0Athings. I've had some productive discussions about doi=
ng the scripting=0Awithin the Zend_Tool framework -- but thats as far as it=
 gets.<br>=0A<br>=0AIf you publish the data, I'll write the tools (though, =
i'll leave it to=0Ayour team to write the tests &lt;grin&gt;)<br>=0A<br>=0A=
Ideally a csv (or xml) like....<br>=0A<br>=0AZFV (zend framework vulnerabil=
ity) Number&nbsp; | File | Line | Match |=0APatch | Remarks<br>=0AZFV-123 |=
 library/Zend/Whatever.php | 12 | if($this-&gt;somethingIsBad)=0A| ZFV-123.=
patch | You'll have to also change your bootstrap from this=0Ato that. <br>=
=0A<br>=0AGiven that, we can write sites, and potentially tools that would =
check=0Athemselves automatically.<br>=0A<br>=0AI've previously proposed add=
ing this to Zend_Version, but maybe theres=0Aa more appropriate place?&nbsp=
; IMHO this should be a 2.0 line build=0Arequirement. <br>=0A<br>=0A<br>=0A=
<blockquote type=3D"cite">=0A  <blockquote type=3D"cite">=0A    <pre>--<br>=
<br>I'd also add that there's probably an opportunity to look at phar-izati=
on<br>within the 2.0 line. Will the new loader support phar'd components, a=
nd how<br>will that look? Zend_Tool? Configurable site images?<br>    </pre=
>=0A  </blockquote>=0A  <pre>I've already experimented with Phar and ZF 1.X=
. It requires minimal<br>changes to the autoloader for it to work out of th=
e box.<br>  </pre>=0A</blockquote>=0AOooOOo gimme gimme.... Docs, blog post=
? How does it work with=0Aoverlaying views, layouts, controllers, models, e=
xtending/replacing=0Acore zend libraries, etc?<br>=0A<br>=0AAnyway, hope th=
at elaborates and is more helpful than it is not =3DP<br>=0A<br>=0AKevin<br=
>=0A<br>=0A<br>=0A<meta http-equiv=3D"x-dns-prefetch-control" content=3D"on=
"></div></div>=0A<!-- cg4.c902.mail.ac4.yahoo.com compressed/chunked Thu No=
v 12 08:24:37 PST 2009 -->=0A</div></body></html>
--0-1159218232-1258069511=:9816--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Eric Clemmons <[email-masked]>
Date: Thu, 1 Apr 2010 09:38:19 -0500
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

I totally thought it was an April Fool's joke, until it actually worked :)

Well, that's one thing solved with the Git migration.  Back to __invoke()! :)

On Apr 1, 2010, at 9:30 AM, till wrote:

> On Mon, Mar 22, 2010 at 1:36 PM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
>> Greetings, all --
>> 
>> Based on the wiki and the poll on this list, it looks like it makes
>> sense to move forward with git. We're still trying to iron on some
>> details about how this will work, but some details are falling into
>> place.
>> 
>> First, the things we plan:
>> 
>>  * Git will be hosted on the ZF servers. This is so that we can have
>>   full control over hooks (i.e., no network latency from web hooks),
>>   integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
>>   will offer both anonymous access as well as selective writable
>>   access.
>> 
>>   Some will say, "why not just use Github?" The above does not preclude
>>   using github in any way; git allows you to specify multiple remotes
>>   from your repository. I already plan to have a mirror of my personal
>>   repo on github, as well as push to the ZF repo from the same
>>   location. This will allow people to use some of githubs powerful
>>   features such as pull queues while still allowing us to retain some
>>   control over the repository. (It also insulates us from githubs
>>   growing pains a bit -- I love github, but they are certainly
>>   suffering from rapid growth the last few months!)
>> 
>>  * We plan to have a read-only subversion mirror of the git repository.
>>   This will allow those using svn:externals to continue to do so, as
>>   well as allow folks more familiar with svn to continue to provide
>>   patches.
>> 
>> Next, things we're still researching:
>> 
>>  * How to handle contributions. Since we require a signed CLA, we need
>>   some way of verifying that a patch came from an author who has signed
>>   the CLA. There have been some suggestions that this may be possible
>>   with some sort of pre-commit verifications when committing to the
>>   master repository (or when someone with commit privileges commits to
>>   their own repository). We're still researching how this might be
>>   implemented.
>> 
>>  * Submodules...
>>   For those unfamiliar with git submodules, they are roughly equivalent
>>   to svn:externals. I say "roughly", because they differ in many ways:
>>   they have to be manually initialized on each person's repository
>>   (though they can be defined in the master repository); they need to
>>   be manually updated periodically (unlike svn:externals, where anytime
>>   you do an "svn up", it also syncs the external); etc.
> 
> http://github.com/blog/626-announcing-svn-support
> 
> I know Zend will do their own git, but since it's trivial to make a
> mirror on Github, this might be something interesting for everyone who
> misses svn:externals. ;-)
> 
> Till

nFrom nobody Wed Apr  7 08:46:10 2010
Date: Tue, 22 Sep 2009 11:25:28 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>

--0-1628973437-1253643928=:92379
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I don't envy you the decision.=0A=0AMy 2c, is that the usage is probably no=
t obscure or uncommon. There was bound to be attempted uses of such a commo=
n method that just worked (whether the behaviour was intentional or not) an=
d never changed. In that sense, it should not have changed in a minor relea=
se, but been reserved for a point release with the current minor version's =
method docblock, and the documentation (to raise awareness), both modified =
to signal it would change for definite with 1.10.=0A=0AI also don't think i=
t's such a major problem, yet, to require a complete rebuild. So a patch le=
vel release to deprecate the current seems like a suitable and prompt respo=
nse.=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.s=
urvivethedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=0A=
=0A=0A=0A=0A________________________________=0AFrom: Matthew Weier O'Phinne=
y <[email-masked]>=0ATo: [email-masked]=0ASent: Tuesday, =
September 22, 2009 7:01:47 PM=0ASubject: [zf-contributors] Considering yank=
ing 1.9.3 -- thoughts?=0A=0AI'd like the opinion of the various contributor=
s, if you could.=0A=0AThere's been a lot of debate about the BC break regar=
ding=0AZend_Db::factory(), and I'm even hearing rumblings about forks over =
it.=0APutting all personal issues aside, I'd like to hear your thoughts abo=
ut=0Ahow we should proceed.=0A=0AFirst, I need to give some background abou=
t the situation we find=0Aourselves in, and not just from the code side.=0A=
=0AOn the code side, the matter is spelled out in the release announcement:=
=0A=0A    http://dz.zend.com/a/10050=0A=0AOn the non-code side, we have a n=
umber of issues going on. =0A=0AFirst, on my side, I did not realize a BC b=
reak had occurred until this=0Amorning -- and not from any official report =
in response to the sanity=0Acheck packages, but from an innocent post on fw=
-general. At that time,=0Awe were already in progress deploying the package=
s and site updates.=0AFor better or worse, re-packaging and releasing takes=
 ~6-8 hours. It's=0Anon-trivial, and this is why we do it on a schedule (wh=
at takes so long?=0Aprimarily building the manuals, building the API docs, =
and creating the=0Amanual search indexes). =0A=0ASecond, we have an added o=
nus this week: our colo facility is being=0Arelocated at the end of the wee=
k, and we have a very small window for=0Agetting new packages released befo=
re we have to sync and do a site=0Afreeze.=0A=0AThe options I can see are:=
=0A=0A* Yank the current package, and rebuild.=0A* Create a patch-level pac=
kage (1.9.3pl1), and deprecate 1.9.3.=0A* Do nothing, and continue on.=0A=
=0AI understand that many do not see original behavior as buggy, and relied=
=0Aon it. I also feel that the new solution is much better -- but if=0Asome=
body can propose and implement a better one, I'm open to it.=0A=0AI'd like =
to make a decision in the next few hours; if new packages are=0Aneeded, we =
need to make them ASAP. =0A=0APlease spread the word about this post and he=
lp in the process.=0A=0AThanks!=0A=0A-- =0AMatthew Weier O'Phinney=0AProjec=
t Lead            | [email-masked]=0AZend Framework          | http://fra=
mework.zend.com/=0A
--0-1628973437-1253643928=:92379
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">I don't envy you the decision.<br><br>My 2c, is that the usage=
 is probably not obscure or uncommon. There was bound to be attempted uses =
of such a common method that just worked (whether the behaviour was intenti=
onal or not) and never changed. In that sense, it should not have changed i=
n a minor release, but been reserved for a point release with the current m=
inor version's method docblock, and the documentation (to raise awareness),=
 both modified to signal it would change for definite with 1.10.<br><br>I a=
lso don't think it's such a major problem, yet, to require a complete rebui=
ld. So a patch level release to deprecate the current seems like a suitable=
 and prompt response.<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 1=
91);"><font style=3D"font-family: times new roman,new york,times,serif;"
 size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></spa=
n></font><span style=3D"font-style: italic;"><font style=3D"font-family: ti=
mes new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=
=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.=
com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survive=
thedeepend.com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow"=
 target=3D"_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Found=
ation Irish Representative</a><br></font></span></span><div><br></div><div =
style=3D"font-family: times new roman,new york,times,serif; font-size: 12pt=
;"><br><div style=3D"font-family: tahoma,new york,times,serif; font-size: 8=
pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font=
-weight: bold;">From:</span></b> Matthew Weier O'Phinney &lt;[email-masked]=
om&gt;<br><b><span style=3D"font-weight: bold;">To:</span></b> zf-contribut=
[email-masked]<br><b><span
 style=3D"font-weight: bold;">Sent:</span></b> Tuesday, September 22, 2009 =
7:01:47 PM<br><b><span style=3D"font-weight: bold;">Subject:</span></b> [zf=
-contributors] Considering yanking 1.9.3 -- thoughts?<br></font><br>=0AI'd =
like the opinion of the various contributors, if you could.<br><br>There's =
been a lot of debate about the BC break regarding<br>Zend_Db::factory(), an=
d I'm even hearing rumblings about forks over it.<br>Putting all personal i=
ssues aside, I'd like to hear your thoughts about<br>how we should proceed.=
<br><br>First, I need to give some background about the situation we find<b=
r>ourselves in, and not just from the code side.<br><br>On the code side, t=
he matter is spelled out in the release announcement:<br><br><span>&nbsp; &=
nbsp; <a target=3D"_blank" href=3D"http://dz.zend.com/a/10050">http://dz.ze=
nd.com/a/10050</a></span><br><br>On the non-code side, we have a number of =
issues going on. <br><br>First, on my side, I did not realize a BC break ha=
d occurred until this<br>morning -- and not from any official report in res=
ponse to the sanity<br>check packages, but from an innocent post on fw-gene=
ral. At that time,<br>we were already in progress deploying the
 packages and site updates.<br>For better or worse, re-packaging and releas=
ing takes ~6-8 hours. It's<br>non-trivial, and this is why we do it on a sc=
hedule (what takes so long?<br>primarily building the manuals, building the=
 API docs, and creating the<br>manual search indexes). <br><br>Second, we h=
ave an added onus this week: our colo facility is being<br>relocated at the=
 end of the week, and we have a very small window for<br>getting new packag=
es released before we have to sync and do a site<br>freeze.<br><br>The opti=
ons I can see are:<br><br> * Yank the current package, and rebuild.<br> * C=
reate a patch-level package (1.9.3pl1), and deprecate 1.9.3.<br> * Do nothi=
ng, and continue on.<br><br>I understand that many do not see original beha=
vior as buggy, and relied<br>on it. I also feel that the new solution is mu=
ch better -- but if<br>somebody can propose and implement a better one, I'm=
 open to it.<br><br>I'd like to make a decision in the next few
 hours; if new packages are<br>needed, we need to make them ASAP. <br><br>P=
lease spread the word about this post and help in the process.<br><br>Thank=
s!<br><br>-- <br>Matthew Weier O'Phinney<br>Project Lead&nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; | <a ymailto=3D"mailto:[email-masked]" href=3D"mai=
lto:[email-masked]">[email-masked]</a><br><span>Zend Framework&nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; | <a target=3D"_blank" href=3D"http://framework.z=
end.com/">http://framework.zend.com/</a></span><br></div></div></div></body=
></html>
--0-1628973437-1253643928=:92379--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Sat, 23 Jan 2010 01:36:26 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors]
	=?UTF-8?Q?Zend=5FDate=20=26=20build-in=20class=20Da?=
	=?UTF-8?Q?teTime?=

The only thing DateTime can't handle that Zend_Date can as of 5.3 is
localized output
and maybe some special features.

>From the performance point of view, i have tested three use-cases against
each
other:

1. Printing the same instance 100 times

$s =3D microtime(true);
$d =3D new DateTime("now");
for($i =3D 0; $i < 100; $i++) {
   $d->format('d.m.Y, H:i');=20
}

$date =3D new Zend_Date(1234567890, false);
for($i =3D 0; $i < 100; $i++) {=20
    $date->toString('d.m.Y, H:i');
}

Gives:=20
DateTime 0.0004s
Zend_Date 0.0599s

2. Changing the date by Unix-Timestamp on each run for 100 times:

$d =3D new DateTime("now");
for($i =3D 0; $i < 100; $i++) {
   $d->setTimestamp($now + $i * 7200);
   $d->format('d.m.Y, H:i');=20
}

$date =3D new Zend_Date(1234567890, false);
for($i =3D 0; $i < 100; $i++) {=20
    $date->setTimestamp($now + $i * 7200);
    $date->toString('d.m.Y, H:i');
}

Gives:
DateTime 0.0010s
Zend_Date 0.0591s

3. Changing Date on each call by a defined format (MySQL Database) for 10=
0
new instances.

Now this is the most evil performance hit.

$s =3D microtime(true);
for($i =3D 0; $i < 100; $i++) {
   $d =3D DateTime::createFromFormat('Y-m-d H:i:s', '2009-04-01 12:12:12'=
);
   $d->format('d.m.Y, H:i');=20
}

for($i =3D 0; $i < 100; $i++) {=20
    $date =3D new Zend_Date('2009-04-01 12:12:12', Zend_Date::ISO_8601);
    $date->toString('d.m.Y, H:i');
}

DateTime: 0.0020s
Zend_Date: 0.1982s

DateTime is faster than Zend_Date by a magnitute of 60-100!!

On Fri, 22 Jan 2010 15:59:32 -0800 (PST), P=C3=A1draic Brady
<[email-masked]> wrote:
> Personally I don't see DateTime as massively important to Zend_Date. It
> would be nice to have, but the class itself is pretty basic that I'm no=
t
> sure what exactly it would add to Zend_Date other than offer a
(measured?)
> performance boost and some import/export functionality for
interoperability
> (would have been nicer to have a DateTime interface).
>=20
>  P=C3=A1draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>=20
>=20
>=20
>=20
>=20
> ________________________________
> From: Marc Bennewitz <[email-masked]>
> To: [email-masked]
> Sent: Fri, January 22, 2010 10:16:02 PM
> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>=20
>  Hi all,
>=20
> Does is matter that Zend_Date doesn't extends the build-in DateTime
> class ?
> -> The DateTime class is available since PHP=20
> 5.2.0 and ZF require PHP 5.2.4.
>=20
> It would be very nice because than Zend_Date would be compatible to
> other php libraries using DateTime and within ZF tests like the
> following can simplify:
>=20
> if ($date instanceof Zend_Date_DateObject) {
>     $timestamp =3D $date->getUnixTimestamp();
> } elseif ($date instanceof DateTime) {
>     $timestamp =3D $date->getTimestamp();
> } else {
>     $timestamp =3D (float)$date;
> }
>=20
> Greetings,
> Marc

nFrom nobody Wed Apr  7 08:46:10 2010
Date: Tue, 8 Dec 2009 05:32:34 -0800 (PST)
From: =?utf-8?B?UMOhZHJhaWMgQnJhZHk=?= <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>

--0-523238198-1260279154=:67884
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Matthew,=0A=0A> >I'm missing the most important thing: write a unit test wi=
th known attack=0A>> vectors. If I'd want an improvement as important as se=
curity I'd write a unit=0A>> test to prove that it works (or fails).=0A>> >=
 Putting the burden on someone else by hiding testable examples in a blog p=
ost=0A>> > or email leaves a bad aftertaste.=0A>>=0A>> I apologise for expo=
sing the stupidity of relying on Zend_Filter_StripTags to=0A>> prevent XSS,=
 or even, like, strip tags. Truly. Sorry.=0A>>=0A>> Now read the blog and s=
ee where I three frigging times make it absolutely clear=0A>> that at the t=
ime I wrote this I did NOT consider this a security issue for the=0A>> Zend=
 Framework. I am ENTITLED to change my mind after over a day of discussing=
=0A>> it which is exactly what I did. In the future, however, I will keep m=
y mouth=0A>> shut. When I see something wrong, I will remain silent.=0A>=0A=
>My point to you on twitter and in my last post is that it was the=0A>langu=
age you used to report that is raising the most questions.=0A>=0A>If your p=
ost title had been, "Zend_Filter_StripTags: It's not an XSS=0A>filter, stup=
id!" the connotation would have been quite different.=0A>Instead, you use t=
he phrase "Security Nightmare" in the title, which, as=0A>a project lead, i=
mmediately raises my guard and has me wondering if a=0A>security vulnerabil=
ity is being reported.=0A=0AThe misuse of the class is a "security nightmar=
e". This is a statement of fact not fancy. In the context of the blog post,=
 the title was factual, accurate, and appropriate.=0A=0A>For the first half=
 of your post I totally agree with. It's from the=0A>point "Bring Forth the=
 Firing Squad" forward that I start to have=0A>issues.=0A>=0A>Your first ex=
ample with a self-closed <img> tag should have simply been=0A>reported via =
the issue tracker. It has nothing to do with your main=0A>point, which was =
that StripTags does not protect against XSS. Same goes=0A>for the second ex=
ample (closing tags only example).=0A=0AThe malformed tag goes to the point=
 that the class generates malformed HTML. =0A=0A>Your third example made se=
nse... up to the sentence, "Given the=0A>obviousness of this, it should be =
apparent that Zend_Filter_StripTags=0A>offers an unknown level of XSS prote=
ction - i.e. it's untrustworthy."=0A=0AIn the role of an XSS filter, the cl=
ass is untrustworthy. Again, a statement of fact.=0A=0A>At this point, your=
 language deviates, and it becomes less clear if you=0A>are claiming that u=
sers should be leary of using StripTags as it does=0A>not protect from XSS,=
 or if you are claiming that it _introduces_ an=0A>XSS.=0A=0AThree quotes:=
=0A=0A* It does it really well too. Got you there, didn't I? Yes, it does e=
xactly what it says on the tin. It strips tags and attributes not on the us=
er-defined whitelist. It's not buggy or anything.=0A=0A* There is one impor=
tant point to note - technically there is nothing wrong with the filter. It=
 does indeed strip tags and attributes which do not appear on the user defi=
ned whitelist. The issue is the possibility that a user may take using Zend=
_Filter_StripTags too far.=0A=0A* Just to reiterate (third time), StripTags=
 does exactly what it advertises - I am simply pointing out the insanity of=
 using it as a magic defence against third-party sourced HTML input. Please=
...don't.=0A=0APerhaps next time I'll drop all clarifications since they ob=
viously have little value.=0A=0A>Additionally, the way you advertised the p=
ost on twitter makes this=0A>unclear:=0A>=0A>* "Some debate over the StripT=
ags security issues..."=0A>  Makes it sound like there are security issues =
with the component (not=0A>  that if mis-used, you can introduce security i=
ssues)=0A>=0A>* "The #ZF StripTags issue proving a sad lesson. Too many peo=
ple don't=0A>  actually understand XSS..."=0A>  Makes it sound like StripTa=
gs has an XSS vulnerability=0A>=0A>* "Have just confirmed a second XSS vuln=
erability in=0A>  Zend_Filter_StripTags"=0A>  Explicitly calls it out as ha=
ving multiple XSS vulnerabilities.=0A>=0A>If you really don't feel that the=
 component is vulnerable, then why use=0A>that language and get everyone ra=
nting and raving about it?=0A=0AThe last was made yesterday morning long af=
ter the blog post was published. Since the security vulnerabilities were a)=
 obvious, b) already public, and c) discussed publicly for close to two day=
s I determined the risk of additional public warnings to be non-existent. T=
he previous two were comments on the ongoing public debate over StripTags. =
Sadly, Twitter limits the available context.=0A=0A>Do I think the blog post=
 was misguided? No -- I just think it could have=0A>been better executed to=
 make your main point clearer: don't use=0A>StripTags and think that you've=
 protected yourself from XSS. And when=0A>tweeting about it, it would have =
made more sense to be explicit as well:=0A>"More examples showing why Strip=
Tags is not an XSS filter..."=0A=0AGladly, I am not required to have my blo=
g peer reviewed nor my tweets censored.=0A=0A>Also, my critiques are not me=
ant to silence you in any way. I simply=0A>want to make it clear that you h=
ave to be careful when reporting=0A>security vulnerabilities. Proper securi=
ty etiquette would have you=0A>discuss and collaborate with the vendor to f=
ix the issue _prior_ to=0A>reporting publically. In this case, since it was=
n't an actual security=0A>issue, my point is to be careful how you post sec=
urity-related=0A>information, to ensure that people don't jump to conclusio=
ns.=0A=0AIf I may critique your own public response, you state there wasn't=
 an actual security issue. There is.=0A=0A>> Yeah, like that will happen...=
:P. I rant - live with it.=0A>>=0A>> Paddy=0A=0A P=C3=A1draic Brady=0A=0Aht=
tp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Euro=
pe Foundation Irish Representative=0A=0A=0A=0A=0A=0A_______________________=
_________=0AFrom: Matthew Weier O'Phinney <[email-masked]>=0ATo: zf-contr=
[email-masked]=0ASent: Mon, December 7, 2009 5:27:43 PM=0ASubject: =
Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In Zend_Filter=
_StripTags=0A=0A-- P=C3=A1draic Brady <[email-masked]> wrote=0A(on=
 Monday, 07 December 2009, 08:34 AM -0800):=0A> >I'm missing the most impor=
tant thing: write a unit test with known attack=0A> vectors. If I'd want an=
 improvement as important as security I'd write a unit=0A> test to prove th=
at it works (or fails).=0A> > Putting the burden on someone else by hiding =
testable examples in a blog post=0A> > or email leaves a bad aftertaste.=0A=
> =0A> I apologise for exposing the stupidity of relying on Zend_Filter_Str=
ipTags to=0A> prevent XSS, or even, like, strip tags. Truly. Sorry.=0A> =0A=
> Now read the blog and see where I three frigging times make it absolutely=
 clear=0A> that at the time I wrote this I did NOT consider this a security=
 issue for the=0A> Zend Framework. I am ENTITLED to change my mind after ov=
er a day of discussing=0A> it which is exactly what I did. In the future, h=
owever, I will keep my mouth=0A> shut. When I see something wrong, I will r=
emain silent.=0A=0AMy point to you on twitter and in my last post is that i=
t was the=0Alanguage you used to report that is raising the most questions.=
=0A=0AIf your post title had been, "Zend_Filter_StripTags: It's not an XSS=
=0Afilter, stupid!" the connotation would have been quite different.=0AInst=
ead, you use the phrase "Security Nightmare" in the title, which, as=0Aa pr=
oject lead, immediately raises my guard and has me wondering if a=0Asecurit=
y vulnerability is being reported.=0A=0AFor the first half of your post I t=
otally agree with. It's from the=0Apoint "Bring Forth the Firing Squad" for=
ward that I start to have=0Aissues. =0A=0AYour first example with a self-cl=
osed <img> tag should have simply been=0Areported via the issue tracker. It=
 has nothing to do with your main=0Apoint, which was that StripTags does no=
t protect against XSS. Same goes=0Afor the second example (closing tags onl=
y example).=0A=0AYour third example made sense... up to the sentence, "Give=
n the=0Aobviousness of this, it should be apparent that Zend_Filter_StripTa=
gs=0Aoffers an unknown level of XSS protection - i.e. it's untrustworthy."=
=0A=0AAt this point, your language deviates, and it becomes less clear if y=
ou=0Aare claiming that users should be leary of using StripTags as it does=
=0Anot protect from XSS, or if you are claiming that it _introduces_ an=0AX=
SS. =0A=0AAdditionally, the way you advertised the post on twitter makes th=
is=0Aunclear:=0A=0A* "Some debate over the StripTags security issues..."=0A=
   Makes it sound like there are security issues with the component (not=0A=
   that if mis-used, you can introduce security issues)=0A=0A* "The #ZF Str=
ipTags issue proving a sad lesson. Too many people don't=0A   actually unde=
rstand XSS..."=0A   Makes it sound like StripTags has an XSS vulnerability=
=0A=0A* "Have just confirmed a second XSS vulnerability in=0A   Zend_Filter=
_StripTags"=0A   Explicitly calls it out as having multiple XSS vulnerabili=
ties.=0A=0AIf you really don't feel that the component is vulnerable, then =
why use=0Athat language and get everyone ranting and raving about it? =0A=
=0ADo I think the blog post was misguided? No -- I just think it could have=
=0Abeen better executed to make your main point clearer: don't use=0AStripT=
ags and think that you've protected yourself from XSS. And when=0Atweeting =
about it, it would have made more sense to be explicit as well:=0A"More exa=
mples showing why StripTags is not an XSS filter..."=0A=0AAlso, my critique=
s are not meant to silence you in any way. I simply=0Awant to make it clear=
 that you have to be careful when reporting=0Asecurity vulnerabilities. Pro=
per security etiquette would have you=0Adiscuss and collaborate with the ve=
ndor to fix the issue _prior_ to=0Areporting publically. In this case, sinc=
e it wasn't an actual security=0Aissue, my point is to be careful how you p=
ost security-related=0Ainformation, to ensure that people don't jump to con=
clusions.=0A=0A> Yeah, like that will happen...:P. I rant - live with it.=
=0A> =0A> Paddy=0A> =0A> =0A>  =0A> P draic Brady=0A> =0A> http://blog.astr=
umfutura.com=0A> http://www.survivethedeepend.com=0A> OpenID Europe Foundat=
ion Irish Representative=0A> =0A> =0A> =E2=94=81=E2=94=81=E2=94=81=E2=94=81=
=0A> From: Nico Edtinger <[email-masked]>=0A> To: P draic B=
rady <[email-masked]>=0A> Sent: Mon, December 7, 2009 4:10:04 PM=
=0A> Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities =
In=0A> Zend_Filter_StripTags=0A> =0A> Am 07.12.2009 um 15:26 schrieb P drai=
c Brady:=0A> =0A>     I would also suggest the following:=0A> =0A>     a) R=
ework the filter's current four lines of documentation (http://=0A>    fram=
ework.zend.com/manual/en/zend.filter.set.html#zend.filter.set.striptags=0A>=
     ) to cover the component in greater detail clarifying its use cases,=
=0A>     potential for misuse, and clarifying it is not XSS  or malformed H=
TML safe.=0A>     b) Immediately deprecate in 1.9 branch (and remove in 2.0=
 - preferably 1.10=0A>     given its significance) its ability to flexibly =
allow some HTML/comments=0A>     thus preserving its only truly worthwhile =
feature - stripping ALL HTML.=0A>     c) Do this ASAP.=0A> =0A> =0A> I'm mi=
ssing the most important thing: write a unit test with known attack=0A> vec=
tors. If I'd want an improvement as important as security I'd write a unit=
=0A> test to prove that it works (or fails). Putting the burden on someone =
else by=0A> hiding testable examples in a blog post or email leaves a bad a=
ftertaste.=0A> =0A> nico=0A=0A-- =0AMatthew Weier O'Phinney=0AProject Lead =
           | [email-masked]=0AZend Framework          | http://framework.=
zend.com/=0A
--0-523238198-1260279154=:67884
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Matthew,<br><br>&gt; &gt;I'm missing the most important thing:=
 write a unit test with known attack<br>&gt;&gt; vectors. If I'd want an im=
provement as important as security I'd write a unit<br>&gt;&gt; test to pro=
ve that it works (or fails).<br>&gt;&gt; &gt; Putting the burden on someone=
 else by hiding testable examples in a blog post<br>&gt;&gt; &gt; or email =
leaves a bad aftertaste.<br>&gt;&gt;<br>&gt;&gt; I apologise for exposing t=
he stupidity of relying on Zend_Filter_StripTags to<br>&gt;&gt; prevent XSS=
, or even, like, strip tags. Truly. Sorry.<br>&gt;&gt;<br>&gt;&gt; Now read=
 the blog and see where I three frigging times make it absolutely clear<br>=
&gt;&gt; that at the time I wrote this I did NOT consider this a security i=
ssue for the<br>&gt;&gt; Zend Framework. I am ENTITLED to change my mind
 after over a day of discussing<br>&gt;&gt; it which is exactly what I did.=
 In the future, however, I will keep my mouth<br>&gt;&gt; shut. When I see =
something wrong, I will remain silent.<br>&gt;<br>&gt;My point to you on tw=
itter and in my last post is that it was the<br>&gt;language you used to re=
port that is raising the most questions.<br>&gt;<br>&gt;If your post title =
had been, "Zend_Filter_StripTags: It's not an XSS<br>&gt;filter, stupid!" t=
he connotation would have been quite different.<br>&gt;Instead, you use the=
 phrase "Security Nightmare" in the title, which, as<br>&gt;a project lead,=
 immediately raises my guard and has me wondering if a<br>&gt;security vuln=
erability is being reported.<br><br>The misuse of the class is a "security =
nightmare". This is a statement of fact not fancy. In the context of the bl=
og post, the title was factual, accurate, and appropriate.<br><br>&gt;For t=
he first half of your post I totally agree with. It's from
 the<br>&gt;point "Bring Forth the Firing Squad" forward that I start to ha=
ve<br>&gt;issues.<br>&gt;<br>&gt;Your first example with a self-closed &lt;=
img&gt; tag should have simply been<br>&gt;reported via the issue tracker. =
It has nothing to do with your main<br>&gt;point, which was that StripTags =
does not protect against XSS. Same goes<br>&gt;for the second example (clos=
ing tags only example).<br><br>The malformed tag goes to the point that the=
 class generates malformed HTML. <br><br>&gt;Your third example made sense.=
.. up to the sentence, "Given the<br>&gt;obviousness of this, it should be =
apparent that Zend_Filter_StripTags<br>&gt;offers an unknown level of XSS p=
rotection - i.e. it's untrustworthy."<br><br>In the role of an XSS filter, =
the class is untrustworthy. Again, a statement of fact.<br><br>&gt;At this =
point, your language deviates, and it becomes less clear if you<br>&gt;are =
claiming that users should be leary of using StripTags as it
 does<br>&gt;not protect from XSS, or if you are claiming that it _introduc=
es_ an<br>&gt;XSS.<br><br>Three quotes:<br><br>* It does it really well too=
. Got you there, didn't I? Yes, it does exactly what it says on the tin. It=
 strips tags and attributes not on the user-defined whitelist. It's not bug=
gy or anything.<br><br>* There is one important point to note - technically=
 there is nothing wrong with the filter. It does indeed strip tags and attr=
ibutes which do not appear on the user defined whitelist. The issue is the =
possibility that a user may take using Zend_Filter_StripTags too far.<br><b=
r>* Just to reiterate (third time), StripTags does exactly what it advertis=
es - I am simply pointing out the insanity of using it as a magic defence a=
gainst third-party sourced HTML input. Please...don't.<br><br>Perhaps next =
time I'll drop all clarifications since they obviously have little value.<b=
r><br>&gt;Additionally, the way you advertised the post on twitter
 makes this<br>&gt;unclear:<br>&gt;<br>&gt;* "Some debate over the StripTag=
s security issues..."<br>&gt;&nbsp; Makes it sound like there are security =
issues with the component (not<br>&gt;&nbsp; that if mis-used, you can intr=
oduce security issues)<br>&gt;<br>&gt;* "The #ZF StripTags issue proving a =
sad lesson. Too many people don't<br>&gt;&nbsp; actually understand XSS..."=
<br>&gt;&nbsp; Makes it sound like StripTags has an XSS vulnerability<br>&g=
t;<br>&gt;* "Have just confirmed a second XSS vulnerability in<br>&gt;&nbsp=
; Zend_Filter_StripTags"<br>&gt;&nbsp; Explicitly calls it out as having mu=
ltiple XSS vulnerabilities.<br>&gt;<br>&gt;If you really don't feel that th=
e component is vulnerable, then why use<br>&gt;that language and get everyo=
ne ranting and raving about it?<br><br>The last was made yesterday morning =
long after the blog post was published. Since the security vulnerabilities =
were a) obvious, b) already public, and c) discussed publicly for
 close to two days I determined the risk of additional public warnings to b=
e non-existent. The previous two were comments on the ongoing public debate=
 over StripTags. Sadly, Twitter limits the available context.<br><br>&gt;Do=
 I think the blog post was misguided? No -- I just think it could have<br>&=
gt;been better executed to make your main point clearer: don't use<br>&gt;S=
tripTags and think that you've protected yourself from XSS. And when<br>&gt=
;tweeting about it, it would have made more sense to be explicit as well:<b=
r>&gt;"More examples showing why StripTags is not an XSS filter..."<br><br>=
Gladly, I am not required to have my blog peer reviewed nor my tweets censo=
red.<br><br>&gt;Also, my critiques are not meant to silence you in any way.=
 I simply<br>&gt;want to make it clear that you have to be careful when rep=
orting<br>&gt;security vulnerabilities. Proper security etiquette would hav=
e you<br>&gt;discuss and collaborate with the vendor to fix the
 issue _prior_ to<br>&gt;reporting publically. In this case, since it wasn'=
t an actual security<br>&gt;issue, my point is to be careful how you post s=
ecurity-related<br>&gt;information, to ensure that people don't jump to con=
clusions.<br><br>If I may critique your own public response, you state ther=
e wasn't an actual security issue. There is.<br><br>&gt;&gt; Yeah, like tha=
t will happen...:P. I rant - live with it.<br>&gt;&gt;<br>&gt;&gt; Paddy<br=
><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"fon=
t-family: times new roman,new york,times,serif;" size=3D"3"><span style=3D"=
font-weight: bold;">P=C3=A1draic Brady<br><br></span></font><span style=3D"=
font-style: italic;"><font style=3D"font-family: times new roman,new york,t=
imes,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"http:=
//blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a rel=3D"nofo=
llow" target=3D"_blank"
 href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com=
</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideuro=
pe.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span>=
</span><div><br></div><div style=3D"font-family: times new roman,new york,t=
imes,serif; font-size: 12pt;"><br><div style=3D"font-family: tahoma,new yor=
k,times,serif; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"><hr size=
=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Matthew Weier=
 O'Phinney &lt;[email-masked]&gt;<br><b><span style=3D"font-weight: bold;=
">To:</span></b> [email-masked]<br><b><span style=3D"font-w=
eight: bold;">Sent:</span></b> Mon, December 7, 2009 5:27:43 PM<br><b><span=
 style=3D"font-weight: bold;">Subject:</span></b> Re: [zf-contributors] XSS=
 And Malformed HTML Vulnerabilities In Zend_Filter_StripTags<br></font><br>=
=0A-- P=C3=A1draic Brady &lt;<a ymailto=3D"mailto:[email-masked]" =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wro=
te<br>(on Monday, 07 December 2009, 08:34 AM -0800):<br>&gt; &gt;I'm missin=
g the most important thing: write a unit test with known attack<br>&gt; vec=
tors. If I'd want an improvement as important as security I'd write a unit<=
br>&gt; test to prove that it works (or fails).<br>&gt; &gt; Putting the bu=
rden on someone else by hiding testable examples in a blog post<br>&gt; &gt=
; or email leaves a bad aftertaste.<br>&gt; <br>&gt; I apologise for exposi=
ng the stupidity of relying on Zend_Filter_StripTags to<br>&gt; prevent XSS=
, or even, like, strip tags. Truly. Sorry.<br>&gt; <br>&gt; Now read the bl=
og and see where I three frigging times make it absolutely clear<br>&gt; th=
at at the time I wrote this I did NOT consider this a security issue for th=
e<br>&gt; Zend Framework. I am ENTITLED to change my mind after over a day =
of
 discussing<br>&gt; it which is exactly what I did. In the future, however,=
 I will keep my mouth<br>&gt; shut. When I see something wrong, I will rema=
in silent.<br><br>My point to you on twitter and in my last post is that it=
 was the<br>language you used to report that is raising the most questions.=
<br><br>If your post title had been, "Zend_Filter_StripTags: It's not an XS=
S<br>filter, stupid!" the connotation would have been quite different.<br>I=
nstead, you use the phrase "Security Nightmare" in the title, which, as<br>=
a project lead, immediately raises my guard and has me wondering if a<br>se=
curity vulnerability is being reported.<br><br>For the first half of your p=
ost I totally agree with. It's from the<br>point "Bring Forth the Firing Sq=
uad" forward that I start to have<br>issues. <br><br>Your first example wit=
h a self-closed &lt;img&gt; tag should have simply been<br>reported via the=
 issue tracker. It has nothing to do with your main<br>point, which
 was that StripTags does not protect against XSS. Same goes<br>for the seco=
nd example (closing tags only example).<br><br>Your third example made sens=
e... up to the sentence, "Given the<br>obviousness of this, it should be ap=
parent that Zend_Filter_StripTags<br>offers an unknown level of XSS protect=
ion - i.e. it's untrustworthy."<br><br>At this point, your language deviate=
s, and it becomes less clear if you<br>are claiming that users should be le=
ary of using StripTags as it does<br>not protect from XSS, or if you are cl=
aiming that it _introduces_ an<br>XSS. <br><br>Additionally, the way you ad=
vertised the post on twitter makes this<br>unclear:<br><br> * "Some debate =
over the StripTags security issues..."<br>&nbsp;  Makes it sound like there=
 are security issues with the component (not<br>&nbsp;  that if mis-used, y=
ou can introduce security issues)<br><br> * "The #ZF StripTags issue provin=
g a sad lesson. Too many people don't<br>&nbsp;  actually understand
 XSS..."<br>&nbsp;  Makes it sound like StripTags has an XSS vulnerability<=
br><br> * "Have just confirmed a second XSS vulnerability in<br>&nbsp;  Zen=
d_Filter_StripTags"<br>&nbsp;  Explicitly calls it out as having multiple X=
SS vulnerabilities.<br><br>If you really don't feel that the component is v=
ulnerable, then why use<br>that language and get everyone ranting and ravin=
g about it? <br><br>Do I think the blog post was misguided? No -- I just th=
ink it could have<br>been better executed to make your main point clearer: =
don't use<br>StripTags and think that you've protected yourself from XSS. A=
nd when<br>tweeting about it, it would have made more sense to be explicit =
as well:<br>"More examples showing why StripTags is not an XSS filter..."<b=
r><br>Also, my critiques are not meant to silence you in any way. I simply<=
br>want to make it clear that you have to be careful when reporting<br>secu=
rity vulnerabilities. Proper security etiquette would have
 you<br>discuss and collaborate with the vendor to fix the issue _prior_ to=
<br>reporting publically. In this case, since it wasn't an actual security<=
br>issue, my point is to be careful how you post security-related<br>inform=
ation, to ensure that people don't jump to conclusions.<br><br>&gt; Yeah, l=
ike that will happen...:P. I rant - live with it.<br>&gt; <br>&gt; Paddy<br=
>&gt; <br>&gt; <br>&gt;&nbsp; <br>&gt; P draic Brady<br>&gt; <br><span>&gt;=
 <a target=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blog.ast=
rumfutura.com</a></span><br><span>&gt; <a target=3D"_blank" href=3D"http://=
www.survivethedeepend.com">http://www.survivethedeepend.com</a></span><br>&=
gt; OpenID Europe Foundation Irish Representative<br>&gt; <br>&gt; <br>&gt;
 =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=
=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81<br>&gt; From: Nico Edtinger &lt;<a =
ymailto=3D"mailto:[email-masked]" href=3D"mailto:zf-contrib=
[email-masked]">[email-masked]</a>&gt;<br>&gt; To: P =
draic Brady &lt;<a ymailto=3D"mailto:[email-masked]" href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt;<br>&gt; Sent: Mo=
n, December 7, 2009 4:10:04 PM<br>&gt; Subject: Re: [zf-contributors] XSS A=
nd Malformed HTML Vulnerabilities In<br>&gt; Zend_Filter_StripTags<br>&gt; =
<br>&gt; Am 07.12.2009 um 15:26 schrieb P draic Brady:<br>&gt; <br>&gt;&nbs=
p; &nbsp;  I would also suggest the following:<br>&gt; <br>&gt;&nbsp; &nbsp=
;  a) Rework the filter's current four lines of documentation (http://<br>&=
gt;&nbsp; &nbsp;  <a
 target=3D"_blank" href=3D"http://framework.zend.com/manual/en/zend.filter.=
set.html#zend.filter.set.striptags">framework.zend.com/manual/en/zend.filte=
r.set.html#zend.filter.set.striptags</a><br>&gt;&nbsp; &nbsp;  ) to cover t=
he component in greater detail clarifying its use cases,<br>&gt;&nbsp; &nbs=
p;  potential for misuse, and clarifying it is not XSS&nbsp; or malformed H=
TML safe.<br>&gt;&nbsp; &nbsp;  b) Immediately deprecate in 1.9 branch (and=
 remove in 2.0 - preferably 1.10<br>&gt;&nbsp; &nbsp;  given its significan=
ce) its ability to flexibly allow some HTML/comments<br>&gt;&nbsp; &nbsp;  =
thus preserving its only truly worthwhile feature - stripping ALL HTML.<br>=
&gt;&nbsp; &nbsp;  c) Do this ASAP.<br>&gt; <br>&gt; <br>&gt; I'm missing t=
he most important thing: write a unit test with known attack<br>&gt; vector=
s. If I'd want an improvement as important as security I'd write a unit<br>=
&gt; test to prove that it works (or fails). Putting the burden on
 someone else by<br>&gt; hiding testable examples in a blog post or email l=
eaves a bad aftertaste.<br>&gt; <br>&gt; nico<br><br>-- <br>Matthew Weier O=
'Phinney<br>Project Lead&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a ymai=
lto=3D"mailto:[email-masked]" href=3D"mailto:[email-masked]">matthew@ze=
nd.com</a><br><span>Zend Framework&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a t=
arget=3D"_blank" href=3D"http://framework.zend.com/">http://framework.zend.=
com/</a></span><br></div></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compress=
ed/chunked Mon Dec  7 03:29:14 PST 2009 -->=0A</div></body></html>
--0-523238198-1260279154=:67884--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Date: Mon, 23 Mar 2009 16:53:12 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [zf-contributors] Zend_Service_Amazon_Ec2

--_004_6B4A8009371807499638509271DEA796CC59049A72IMSCMAIL1imsc_
Content-Type: multipart/alternative;
	boundary="_000_6B4A8009371807499638509271DEA796CC59049A72IMSCMAIL1imsc_"

--_000_6B4A8009371807499638509271DEA796CC59049A72IMSCMAIL1imsc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Everyone,

I am proud to announce that the Amazon Ec2 service is ready for Recommendat=
ion (http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_Amazon_Ec2+=
-+Jon+Whitcraft).  I have all the coding done and 91% coverage on the unit =
test.

The code is located here for now: http://github.com/sidhighwind/zend_servic=
e_amazon_ec2/tree/master

It includes Zend_Crypt as it depends on it currently.

Please let me know if you have any questions or comments.

<http://zend.com/zce.php?c=3DZEND002524=
&r=3D219549271>

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]<mailto:[email-masked]>
P: (317) 492-8623 - F: (317) 492-6419

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

--_000_6B4A8009371807499638509271DEA796CC59049A72IMSCMAIL1imsc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Lucida Sans";
	panose-1:2 11 6 2 3 5 4 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal">Everyone,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I am proud to announce that the Amazon Ec2 service i=
s ready for Recommendation (<a href=3D"http://framework.zend.com/wiki/displ=
ay/ZFPROP/Zend_Service_Amazon_Ec2&#43;-&#43;Jon&#43;Whitcraft">http://frame=
work.zend.com/wiki/display/ZFPROP/Zend_Service_Amazon_Ec2&#43;-&#43;Jon&#43=
;Whitcraft</a>).&nbsp;
 I have all the coding done and 91% coverage on the unit test.&nbsp; <o:p><=
/o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The code is located here for now: <a href=3D"http://=
github.com/sidhighwind/zend_service_amazon_ec2/tree/master">
http://github.com/sidhighwind/zend_service_amazon_ec2/tree/master</a><o:p><=
/o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">It includes Zend_Crypt as it depends on it currently=
.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Please let me know if you have any questions or comm=
ents.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<td width=3D"80" valign=3D"top" style=3D"width:60.0pt;padding:0in 0in 0in 0=
in">
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><a href=
=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><span style=
=3D"color:windowtext;text-decoration:none"><img border=3D"0" width=3D"73" h=
eight=3D"68" id=3D"Picture_x0020_1" src=3D"cid:[email-masked]=
80" alt=3D"php5_zce_logo_new"></span></a><span style=3D"font-size:12.0pt"><=
o:p></o:p></span></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Lu=
cida Sans&quot;,&quot;sans-serif&quot;">Jon Whitcraft<br>
Indianapolis Motor Speedway<br>
</span><span style=3D"font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><a href=3D"mailto:[email-masked]"><span style=3D=
"font-size:10.0pt;
  font-family:&quot;Lucida Sans&quot;,&quot;sans-serif&quot;">jwhitcraft@br=
ickyard.com</span></a><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span s=
tyle=3D"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-ser=
if&quot;">P: (317) 492-8623 - F: (317) 492-6419</span><span style=3D"font-s=
ize:9.0pt;font-family:
  &quot;Arial&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<br>
<font face=3D"Arial" color=3D"Gray" size=3D"1">********************<br>
********************<br>
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify
 the sender by reply E-mail and erase this E-mail from your system. Your as=
sistance is appreciated. E-mail transmission may not be secure or error-fre=
e. The company is not responsible for any loss/damage arising from any viru=
s transmitted.<br>
********************<br>
********************<br>
</font>
</body>
</html>

--_000_6B4A8009371807499638509271DEA796CC59049A72IMSCMAIL1imsc_--

--_004_6B4A8009371807499638509271DEA796CC59049A72IMSCMAIL1imsc_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=2553;
	creation-date="Mon, 23 Mar 2009 16:53:13 GMT";
	modification-date="Mon, 23 Mar 2009 16:53:13 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_004_6B4A8009371807499638509271DEA796CC59049A72IMSCMAIL1imsc_--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Felix-Johannes Jendrusch <[email-masked]>
Date: Thu, 10 Dec 2009 19:26:03 +0100
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend Framework modularity and application
	structure

Am 08.12.2009 um 01:37:45 schrieb David Caunt:

> Zend Application is a great start, but there are more components =
needed, whether configurator is the right name or not :) Auto-discovery =
and communication between modules is necessary and valuable, and a =
difficult task for Juozas to think about.

Some time before Zend_Application was moved into Standard Library I was =
facing similar problems and developed something that wasn't as =
feature-rich as Zend_Application now is but solved the problem of module =
dependencies. Modules had to implement an interface:

interface XYZ_Controller_Module_Interface
{
   /**
    * @return string Identifier
    */
   public function getIdentifier();

   /**
    * @return array Identifiers
    */
   public function getDependencies();

   /**
    * Called when the module has been loaded successfully
    *
    * @return void
    * @see    XYZ_Controller_Module::load()
    */
   public function loaded();
}

XYZ_Controller_Module::loadDirectory(string $directory, string =
$classnamePrefix =3D '', string $classnameSuffix =3D '') did the =
following:

1. Scan the given directory for XYZ_Controller_Module_Interface =
implementing classes matching the name scheme and create an instance of =
them.
2. Register for every module which modules it depends on and which =
modules depend on it.
3. Enqueue modules without dependencies.
4. As long as the queue isn't empty loop through it.
4.1 Dequeue a module.
4.2 Put the dequeued module into a loading queue.
4.3 Remove the dequeued module from dependencies of modules depending on =
it.
5. Check if the queue is empty. If not, there are circular dependencies =
-> throw exception.
6. As long as the loading queue isn't empty loop through it.
6.1 Dequeue a module.
6.2 Load the dequeued module.
6.3 Call the dequeued modules loaded() method.

e.g. There was a User module initializing a database driven ACL and all =
other modules requiring the ACL were depending on the User module.

(This is actually building a dependency graph and an evaluation order, =
see http://en.wikipedia.org/wiki/Dependency_graph; see also Topological =
sorting, http://en.wikipedia.org/wiki/Topological_sorting)

Best regards
Felix=

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Thu, 4 Feb 2010 16:08:09 -0800
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [zf-contributors] FW: [fw-general] Topics for Zend Framework
	conference (Russia, St. Petersburg). Lets discuss them!

Hi!

First Russian ZF Conference is officially announced! :)
http://devzone.zend.com/article/11781-1st-Russian-Zend-Framework-Confere
nce-Announced

You are welcome to discuss conference topics and give your
recommendations to speakers.

Topics list and theses are available here as well as in the DevZone
announce.

With best regards,
   Alexander Veremyev.

-----Original Message-----
From: Georgy Turevich [mailto:[email-masked]]=20
Sent: Thursday, February 04, 2010 2:52 AM
To: [email-masked]
Subject: [fw-general] Topics for Zend Framework conference (Russia, St.
Petersburg). Lets discuss them!

Hello,

ZF conference (ZFConf 2010) will take place in Saint Petersburg
(Russia) at the end of March.
I am one of this event's organizers so I would like to discuss the
topics of the expected topics with you.

Our speakers are deeply interested in your feedback. On its basis they
can modify the content of their reviews.

For russian developers which are not aware of the event yet:
- http://www.zfconf.ru
- additional discussions on topics are available at the forum:
http://zendframework.ru/forum/index.php?topic=3D2281.0

Here is the list of the expected topics (see the detailed theses for
each of them below):
- Proposal Lifecycle
- Zend_Search_Lucene in the Details
- Performance of Zend Framework Applications
- Zend Framework and MVC, <Fat> Model
- Fotostrana.ru: Prototyping Project with Zend Framework
- Using Message Queues in Day-to-Day Projects (Zend_Queue)
- Zend Framework and Doctrine
- ZF and Multilingual
- History of e-Shtab.ru
- What News Zend Framework 2.0 Brings to Us?
- jQuery and Dojo Toolkit JavaScript-frameworks Integration with Zend
Framework

=3D=3D=3D Proposal Lifecycle =3D=3D=3D
Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)

This presentation is intended to describe Zend Framework proposal
lifecycle in details to give clear understanding of the steps required
to get proposal included into ZF.

It'll touch on proposal lifecycle actors, proposal lifecycle
steps/proposal states, ZF repository areas created to support proposal
process and other things.
In addition to this some recommendations helping to promote your
proposal quickly will be given.

=3D=3D=3D Zend_Search_Lucene in the Details =3D=3D=3D
Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)

Presentation gives a complete description of a Zend_Search_Lucene
full-text search component usage.

It's oriented to new Zend_Search_Lucene users as well as to experienced
users.

The following aspects will be described within presentation:

    * history of component creation;
    * component purpose;
    * index format details (including factors affecting performance);
    * indexing and indexing performance;
    * searching using queries and query construction API;
    * search results pagination.

Presentation also describes techniques of improving searching
performance for different modes of component usage.

=3D=3D=3D Performance of Zend Framework Applications =3D=3D=3D
Alexander Mahomet (ZendFramework.ru Community, Founder)

The main goal of this report is to show how certain techniques can
improve performance of applications that use Zend Framework. I will
create demo application and will apply these techniques to it. Plan of
report:

Problem definition:

    * Overview of demo application;
    * Overview of testing environment;
    * Overview of instruments for testing;
    * Overview of parameters we should test, measurements before
testing.

Overview of techniques (after each item - new measurements):

    * Methods which are not directly connect to Zend Framework
(accelerators, setup of web server);
    * Deleting of require* from Zend Framework;
    * Joining of Zend Framework classes to one big file;
    * Autoloading and Zend_Loader;
    * Caching of objects (Zend_Config, Zend_Locale, Zend_Acl,
Zend_Navigation), caching of pages and blocks, caching results of
database queries, etc;
    * Memcache;
    * Recommendations from Zend Framework team;
    * How Zend_Server can help building high-load applications.

Comparison Zend Framework performance with other popular PHP frameworks.

=3D=3D=3D Zend Framework and MVC, <Fat> Model =3D=3D=3D
Alexander Steshenko (Norada Corporation, PHP programmer)

1. MVC pattern in details
    * Controller, View
    * Model is the application logic. Model isolation from other parts
of MVC triad
2. MVC implementation in Zend Framework
    * Zend_Controller_Action
    * Zend_Controller_Front
    * Zend_Controller_Dispatcher_Standard
    * Zend_Controller_Action_Helper_ViewRenderer
    * Zend_View
3. Thin / Fat Model
    * What is thin Model, why it does not fit MVC pattern, code samples
    * <Fat> model is every fragment of the application and the whole
application itself
    * Domain model
    * Most often used data access patterns and approaches for modeling
application objects
    * Code samples
    * Data access design patterns flexibility problems
    * Benefits of Data Mapper - data access decomposition, easy
refactoring of every part of the application
    * Service layer, code samples
4. General tips and advices
    * Automated testing
    * ORM tool
    * Good OOP, software design patterns

=3D=3D=3D Fotostrana.ru: Prototyping Project with Zend Framework =
=3D=3D=3D
Leonid Zhavoronkov (Fotostrana.ru, Teamlead)

The history about Zend Framework usage in highload-project (12M hits,
200K hosts):
    * Project's history and key features
    * Choice of ZF as a platform for a startup: benefits and drawbacks
    * Project's platform evolution
    * The current architecture of the project and plans for the future

=3D=3D=3D Using Message Queues in Day-to-Day Projects (Zend_Queue) =
=3D=3D=3D
Denis Baklikov (Obnovlenie, Web Developer)

1. What is message queues?
    * MQ history. JMS
    * Advantages of using message queues
    * Example usage of message queues. Bad examples
    * Messaging patterns
2. Zend_Queue overview
    * Interfaces overview
    * Adapters overview
    * Using different adapters. Best practices
          o array
          o db
          o mq server
    * Zend_Queue development. Next steps
3. MQ servers overview
    * List of MQ serves (main idea: show people large number of
servers they can use)
    * Features of messaging servers (ActiveMQ, MemcacheQ, ...)
4. Projects using message queues
    * Classic example - delayed emails sending
    * Real time statistics processing
    * Social networks. Image uploading example

=3D=3D=3D Zend Framework and Doctrine =3D=3D=3D
Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)

1. Connection of Doctrine to ZF project
    * I will show the examples of code
    * I will tell which options are responsible for what
2. Script for work with Doctrine_Cli
    * I will show an example of work with Doctrine Cli
    * I will tell how to create your task for Doctrine Cli
3. Generation models and mappers with yaml schemes. Inheritance.
Migrations
    * I will show the example of some simple circuits with binding and
inheritance
    * I will show our inputs for the models'autogeneration in modular
application that correspond to standard coding of Zend Framework
4. Adapters for Zend_Paginator and Zend_Auth
    * I will tell how to work and to show code
5. Caching of query results
    * I will tell and show how to connect it and how to work with it

=3D=3D=3D ZF and Multilingual =3D=3D=3D
Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)

1. Adding language in the URL using a custome router (author -
Konstantin Yurevich), a standard router and hostname router. Pluses
and minuses of each approach
    * I will show an examples of routers and examples of simple
applications
    * I will speak about pluses and minuses this routers in terms of SEO
2. Plugin or action helper to initialize translator
    * I will show code examples
3. Why gettext? Nuances and hacks in the implementation of
multilanguage through gettext
    * I will show how convenient to add gettext through poedit and
explain why I think other ways of localization inconvenient
    * I will tell you that we do to translate validators messages
4. Caching
    * I will show code examples

=3D=3D=3D History of e-Shtab.ru =3D=3D=3D
Anatoliy Larin (e-Legion, Web Developer)

Architecture:
    * Zend_Application, Zend_Config, Zend_Controller, Zend_Router
    * MySQL, Zend_Db_Select, Zend_Db_Table, Zend_Db_Row
      Table and Row have partly performed the Model role.
    * Smarty
      We gave up using PHTML because of its extreme flexibility,
posibility to change the data right in the template.
    * Zend_Feed, Zend_Pagination, Zend_Openid
Problems:
    * Smarty autoescaping
      The programmers' forgetfulness became a problem, we missed out
too many XSS holes.
      The problem was solved via patching the Smarty by adding
variables autoescaping functionality.
    * Console jobs
      Zend Framework does not provide instruments for creating console
tasks (crontab, management tasks).
    * A lot of problems related to character encodings
    * Unintuitive URL-Router (upside-down)
    * Error in long email subject in Russian
      We had to spend a few days, to solve the issue.
      http://framework.zend.com/issues/browse/ZF-1688
(07.07.07-18.01.09)
    * Notice, warning instead of Exceptions
      At first we paid no attention to them, which led to bad
consequences a few times.
      As a result, we haven't elaborated correct coding style, which
we got in other programming languages, where the bad-quality code is
denied by compiler / interpreter.
    * Reusability
      Few parts of code we were able to use again without a pain.
      A lot of things were created by copy'n'paste of existing code.

=3D=3D=3D What News Zend Framework 2.0 Brings to Us? =3D=3D=3D
Nadezhda Blinova (Wizartech, Web Programmer), Georgy Turevich
(Wizartech, Lead Web Programmer)

The following changes will be examined in the review:
    * Architectural \ Design Changes
    * MVC Implementation
    * Plugin Architectures
    * Other components (Zend_Acl, Zend_Controller,
Zend_Controller_Router, Zend_Form, Zend_Session, Zend_Soap, Zend_View,
Zend_Mail)
In the course of the review preparation the latest details will be
obtained from ZF developers.

=3D=3D=3D jQuery and Dojo Toolkit JavaScript-frameworks Integration with
Zend Framework =3D=3D=3D
Georgy Turevich (Wizartech, Lead Web Programmer)

During the presentation we will take a detailed look at different
aspects of the integration and examine some examples:
1.  ZF + jQuery and ZF + Dojo Toolkit features overview
2. jQuery
    * Setup jQuery Core and jQuery UI enviroments
    * Automation work with jQuery UI-components
    * Working with "autocompletion"
    * Zend_Form customization with jQuery UI
    * Looking to the future!
3.    Dojo Toolkit
    * Setup Dojo-enviroment
    * Automation with dijit's
    * Working with "autocompletion"
    * Zend_Form customization with Dijit
    * Generation of data in specialized format (dojo.data)
    * Automation Deployment Dojo Toolkit
    * Looking to the future!
4. Several practical demontstrations

Best Regards,
Georgy Turevich

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 20:04:35 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

--0016e64986d20a59b50480859236
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 26, 2010 at 2:59 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

>  * To package individual components, we need some way to determine
>   dependencies. Currently, require_once statements can help with that,
>   but stripping them makes this harder. My solution is to add @uses
>   annotations at the class docblock level. This assists the API docs,
>   but also should make it possible to use automated scanners to
>   determine dependencies.<http://framework.zend.com/zf-matthew-pgp-key.asc>
>

Correct me if I'm wrong, but can't use statements be used for this purpose?
To refer to a class in an external namespace an use Zend\Xxx statement is
necessary, and forbid fully qualified class names such as \Zend\Yyy should
be enough and simpler to enforce than @uses annotations.

Regards,
-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e64986d20a59b50480859236
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Feb 26, 2010 at 2:59 PM, Matthew Weier O=
&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">matt=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;=
 padding-left: 1ex;">

=A0* To package individual components, we need some way to determine<br>
 =A0 dependencies. Currently, require_once statements can help with that,<b=
r>
 =A0 but stripping them makes this harder. My solution is to add @uses<br>
 =A0 annotations at the class docblock level. This assists the API docs,<br=
 =A0 but also should make it possible to use automated scanners to<br>
 =A0 determine dependencies.<font color=3D"#888888"><a href=3D"http://frame=
work.zend.com/zf-matthew-pgp-key.asc" target=3D"_blank"></a><br>
</font></blockquote></div><br>Correct me if I&#39;m wrong, but can&#39;t us=
e statements be used for this purpose? To refer to a class in an external n=
amespace an use Zend\Xxx statement is necessary, and forbid fully qualified=
 class names such as \Zend\Yyy should be enough and simpler to enforce than=
 @uses annotations.<br>
<br>Regards,<br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Enginee=
r<br><a href=3D"http://giorgiosironi.blogspot.com">http://giorgiosironi.blo=
gspot.com</a><br><a href=3D"http://twitter.com/giorgiosironi">http://twitte=
r.com/giorgiosironi</a><br>

--0016e64986d20a59b50480859236--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 26 Jul 2009 22:00:43 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: =?iso-8859-1?Q?P=E1draic?= Brady <[email-masked]>,
	[email-masked]
Mail-Followup-To: =?iso-8859-1?Q?P=E1draic?= Brady <[email-masked]>, 
	[email-masked]
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services
	to ZendX Proposal

-- P=E1draic Brady <[email-masked]> wrote
(on Sunday, 26 July 2009, 11:13 AM -0700):
> > Paddy, to be honest, this feels like a really daft criticism. Dmitry =
did
> > do the original Zend_OpenId component, but we have blocked on YOU to =
do
> > the 2.0 support. When Dmitry started the OpenId component, I had Andi
> > put him in touch with you so that the two of you could collaborate. A=
t
> > that time, you indicated that you would assist as you could, but that
> > you would spend your efforts on OAuth and Yadis support, and then hel=
p
> > with shaping our 2.0 support. These components have remained in
> > basically proposal stage since spring 2008.
> >
> > So, bad example; if you want to see further support for the 2.0 Draft=
 11
> > specs, then please help us by completing what you started -- or indic=
ate
> > you won't do it, so that somebody else can potentially step in and
> > complete this effort.
>=20
> Mathew, to clarify, I have zero involvement in Zend_OpenId and I've nev=
er
> committed to any such involvement. I've never committed so much as a li=
ne of
> code for it. My work on Zend_Service_Yadis and Zend_Crypt were a byprod=
uct of
> my own intentions in February 2007 to bring an OpenId proposal to the t=
able.
> Once that was overtaken in June 2007 by Dmitry's proposal (it's no secr=
et how I
> reacted to that), we had some informal discussions on collaborating but=
 it
> remained an insurmountable problem that my own library was already in p=
lace
> after months of work - I simply did not have the time or the motivation=
 to work
> on what amounted to a second OpenId library from scratch when I already=
 had a
> perfectly operational one underway that I had already intended making a=
 ZF
> contribution. As I said at the time (and wrote about on the blog in Sep=
tember
> 07), the then ZF proposal process was a thoroughly discouraging one tha=
t made
> no effort to engage with proposers in a constructive manner.
>=20
> Though I certainly would have expressed a willingness to assist with Op=
enID (by
> email if I remember?) it would not have been an immediate project and I=
 would
> not have committed to it on the spot without submitting a formal propos=
al for
> discussion. This is neither the time or place to discuss what my involv=
ement or
> the direction of Zend_OpenId could be, but the component needs more tha=
n a few
> patches and it's more a task for ZF 2.0 I think.

First, I want to apologize for my critique. It was unwarranted, and very
likely unjustified. I lashed out as I was frustrated that this thread
started on the eve of a new release. This is the sort of thing that
should have been raised weeks ago, as we could have altered the release
schedule at that time. Brought up this late in the release cycle, it
raises the specter of, "why are they releasing now when even the
contributors feel the framework is shoddy?" The fact of the matter is:
this is a very large project, and there is a *ton* to maintain. A lot of
legacy code was not reviewed well prior to inclusion, and it's left us
with a lot of headaches; we're also still establishing quality
guidelines for promotion to trunk, and this means that code going into
trunk still varies in quality.=20

Are these reasons to delay release? Possibly. But raised this late in
the release cycle, it's too late. What it can mean, however, is that we
work harder towards maintaining what we do have currently for future
releases.

I also want to point out at this time that the internal team has
contributed very, very little to ZF 1.9.0's *features*. This is very
much a community release -- look at all the major features, and you'll
see that the ones with most impact and most development are, to a one,
community driven. My team has been working almost entirely on
maintenance for this release -- Zend_Db and Zend_Pdf, in particular,
were given a ton of attention in the past months, and we have also been
taking a very close look at the test suite and cleaning up code where we
see unit tests failing. Over all, I feel this is the most stable release
to date -- even with the number of issues that exist in the tracker.

Second, Paddy, my apologies if I have remembered the situation
incorrectly, or, in fact, did not have all the information -- which is
also entirely likely as at that time I was not involved full-time with
the project. My main recollection was that, due to Dmitry's proposal
being fast-tracked, but incomplete with regards to 2.0 support, you had
indicated some interest in assisting with the latter after the initial
release. I never meant to indicate that you are a current maintainer
for Zend_OpenId -- only that in my mind, and I would argue those of a
number of others, that you were going to be the "party of interest" with
regards to 2.0 support. I would be absolutely thrilled if you would
still be willing to contribute it -- even if it means another
"Zend_Feed_Reader" situation where we have another parallel library that
offers more and better support.

> As for Zend_Crypt and Zend_Service_Yadis, these date back to 2007. I do=
n't know
> how long they have been in the Incubator - but aside from a few minor i=
ssues in
> Yadis they've been sitting there waiting for whatever the next step is.=
=20

For the record of those reading, once a developer feels their
contribution is complete and ready for inclusion in trunk -- and this
means (a) tests covering the proposal expectations, (b) good test
coverage, and (c) complete documentation for the component -- ping
somebody on the Zend team to do a review for inclusion. We will verify
these points, and either ask for further work to be done or work with
you to move them into trunk.

So, Paddy, does this mean you're ready for Zend_Crypt and
Zend_Service_Yadis to move into trunk? :)

> I don't have any immediate need for them - they were intended for use
> in Zend_OpenId whenever Dmitry needed them. Yadis has been up on PEAR
> as a release for almost as long.=20

Let's discuss this after 1.9 is out the door. I'd like to see some
resolution on OpenId support, and it would be good to get you, Dmitry,
and myself on a call or IRC chat together to determine the way forward.

> OAuth dates from mid-2008 - completely my fault it's not quite
> finished but I have told a few people since last December that they
> should not hesitate to work on it in my absence.  I just couldn't get
> to it at the time. In any case, it's on my card right after ZFR
> finishes up with the final testing.

If you have, nobody has approached anybody on the team about taking over
the proposal. Again, let's discuss this after 1.9.

> Anyway, this is way way off topic.

Agreed -- and I apologize again for bringing it up on a public forum. I
am, and remain, frustrated that the topic of bug and component
maintenance was raised basically on the even of a new release, and took
it out on you. I shouldn't have.

> My point in using that example is that it's another component that is n=
ot
> actively maintained. I am definitely not its maintainer - and I don't e=
ven use
> it. Just backing up Benjamin's observation. I know it's an unrealistic =
pain in
> the butt that Zend are expected to maintain these, but at some point ei=
ther
> maintenance needs to be enforced=20

And I think the key point here is that it needs to be a "put up, or live
with having others maintain your code" policy. I actually have people
regularly asking if they can work on a component -- and usually put them
in touch with the existing maintainer. I think at a certain point,
however, if it's clear the developer is no longer actively maintaining
the code, we mark it as unmaintained somewhere, and, as somebody else
noted, put up a "help wanted" sign for that component. The question is
where this will live, and what the policy will be regarding when a
component is considered "unmaintained".

That said... I know I'm not actively maintaining much of the code I've
written. I hope to, soon, but with the change in roles, I've had much
less time for this activity. So, if you know I authored a component, and
are interested in helping maintain it... please contact me. :)

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 14 Nov 2009 08:24:07 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Thomas Weidner <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] I18N Webinar

--0-528754010-1258215847=:75723
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Just a few suggestions based on common problems:=0A=0A1. UTF8 conversion (s=
till lots of people without a clue - judging by how my name is still not pr=
esented accurately on many sites).=0A2. Integer and Float normalisation acr=
oss locales - particularly when commas/periods are both accepted through fo=
rms.=0A3. Basics of designing a multi-lingual site (language detection, rou=
ting solutions, IP region location).=0A=0APaddy=0A=0A=0A P=E1draic Brady=0A=
=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID=
 Europe Foundation Irish Representative=0A=0A=0A=0A=0A=0A__________________=
______________=0AFrom: Thomas Weidner <[email-masked]>=0ATo: fw-gene=
[email-masked]=0ACc: [email-masked]; [email-masked]=
.com=0ASent: Sat, November 14, 2009 12:53:46 PM=0ASubject: [zf-contributors=
] I18N Webinar=0A=0AHy ZF interested community,=0A=0AI am preparing an webi=
nar about I18N.=0AThis one will be a speak about Translation and all what's=
 related to this task.=0A=0ASo here comes your part:=0AWhich things do you =
want to know ?=0AWhich informations do you miss from manual or other source=
s ?=0AWhat do you want to hear in this webinar ?=0A=0ADon't be shy and just=
 reply :-)=0A=0AGreetings=0AThomas Weidner, I18N Team Leader, Zend Framewor=
k=0Ahttp://www.thomasweidner.com =0A
--0-528754010-1258215847=:75723
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Just a few suggestions based on common problems:<br><br>1. UTF=
8 conversion (still lots of people without a clue - judging by how my name =
is still not presented accurately on many sites).<br>2. Integer and Float n=
ormalisation across locales - particularly when commas/periods are both acc=
epted through forms.<br>3. Basics of designing a multi-lingual site (langua=
ge detection, routing solutions, IP region location).<br><br>Paddy<br><br><=
div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-=
family: times new roman,new york,times,serif;" size=3D"3"><span style=3D"fo=
nt-weight: bold;">P=E1draic Brady<br><br></span></font><span style=3D"font-=
style: italic;"><font style=3D"font-family: times new roman,new york,times,=
serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: tahoma,new york,times,serif; font-size: 8pt;"><font =
face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font-weight: bo=
ld;">From:</span></b> Thomas Weidner &lt;[email-masked]&gt;<br><b><s=
pan style=3D"font-weight: bold;">To:</span></b> [email-masked]<b=
r><b><span style=3D"font-weight: bold;">Cc:</span></b> [email-masked]=
om; [email-masked]<br><b><span style=3D"font-weight: bold;"=
>Sent:</span></b> Sat, November 14, 2009 12:53:46 PM<br><b><span style=3D"f=
ont-weight:
 bold;">Subject:</span></b> [zf-contributors] I18N Webinar<br></font><br>=
=0AHy ZF interested community,<br><br>I am preparing an webinar about I18N.=
<br>This one will be a speak about Translation and all what's related to th=
is task.<br><br>So here comes your part:<br>Which things do you want to kno=
w ?<br>Which informations do you miss from manual or other sources ?<br>Wha=
t do you want to hear in this webinar ?<br><br>Don't be shy and just reply =
:-)<br><br>Greetings<br>Thomas Weidner, I18N Team Leader, Zend Framework<br=
><span><a target=3D"_blank" href=3D"http://www.thomasweidner.com">http://ww=
w.thomasweidner.com</a> </span><br></div></div>=0A<!-- cg4.c902.mail.ac4.ya=
hoo.com compressed/chunked Sat Nov 14 05:18:58 PST 2009 -->=0A</div></body>=
</html>
--0-528754010-1258215847=:75723--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 20:28:35 +0200
From: till <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming 
	Conventions

Hey Matthew,

a general question -- will 2.0 raise the dependency PHP 5.3?

Till

On Fri, Apr 10, 2009 at 8:24 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> Greetings, all --
>
> Below is a proposal I am making to modify the Zend Framework Coding
> Standards conventions for the naming of Interfaces and Abstract classes.
>
> This decision is basically already made, but I'd appreciate any feedback
> that you may have on the matter.
>
> Thanks!
>
> The problem
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> PHP 5.3 introduces namespaces to the PHP language. While this won't have =
an
> impact much on userland code, it will have an impact on library and frame=
work
> code, as it provides a useful paradigm for organizing components as well =
as
> simplifying syntax. Instead of having to say things like:
>
> =A0 =A0$analyzer =3D new Zend_Search_Lucene_Analysis_Analyzer_Common_Text=
Num();
>
> we can instead do something like this:
>
> =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
>
> =A0 =A0$analyzer =3D new Common_TextNum();
>
> or even:
>
> =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
>
> =A0 =A0class Common_TextNum extends Common
> =A0 =A0{
> =A0 =A0}
>
> The problem that arises for Zend Framework has to do with how we name abs=
tract
> classes and interfaces. Currently, the final segment of such classes are
> expected to end with _Abstract and _Interface, respectively. This will no=
t work
> when we migrate to utilize namespaces, for two reasons.
>
> First, and most obviously, 'abstract' and 'interface' are reserved PHP ke=
ywords.
> As such, in situations such as the following:
>
> =A0 =A0namespace Zend\Controller\Request;
>
> =A0 =A0class Abstract
> =A0 =A0{
> =A0 =A0}
>
> =A0 =A0// or:
>
> =A0 =A0namespace Zend\Controller\Dispatcher;
>
> =A0 =A0interface Interface
> =A0 =A0{
> =A0 =A0}
>
> we'll run into issues.
>
> Second, and less obvious, is that perhaps the easiest solution breaks one=
 of the
> key principles of namespaces (which are designed to help encapsulate
> components). This one's harder to explain, so let's look at examples. Con=
sider a
> component such as Zend_Controller_Request. The simplest solution would be=
 to
> name the abstract class or interface Zend\Controller\Request, and then ha=
ve the
> various concrete implementations under that namespace:
>
> =A0 =A0namespace Zend\Controller;
>
> =A0 =A0interface Request
> =A0 =A0{
> =A0 =A0}
>
> =A0 =A0// and concrete ones:
>
> =A0 =A0namespace Zend\Controller\Request;
>
> =A0 =A0class Http
> =A0 =A0{
> =A0 =A0}
>
> What's the problem here? The interface is not in the same namespace as th=
e
> concrete implementations.
>
> Potential solutions and recommendation
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> So, how should Zend Framework "solve" these issues? A number of proposals=
 and
> recommendations have been floated around, both within ZF circles and in t=
he
> greater PHP community.
>
> Considerations include:
>
> =A0* Avoiding the use of PHP reserved keywords (already noted).
> =A0* Avoiding Hungarian Notation (i.e., having the name or a portion of t=
he name
> =A0 describe its type -- which, to a degree, the current naming conventio=
ns
> =A0 already violate). (See http://en.wikipedia.org/wiki/Hungarian_Notatio=
n, the
> =A0 sections "Disadvantages of Systems Hungarian" and "Notable Opinions" =
for some
> =A0 of the arguments against using Hungarian Notation.)
>
> Approaches that have been considered include:
>
> =A0* Using 'I' to prefix interfaces. This derives from standards in other
> =A0 programming languages (.Net and python, in particular). This is just =
another
> =A0 form of Hungarian Notation, however.
>
> =A0* Using "Interface" or "Abstract" as a class name suffix: RequestInter=
face,
> =A0 RequestAbstract. Again, however this is Hungarian Notation.
>
> =A0* Using the term "Base" for abstract classes: BaseRequest, RequestBase=
, Base.
> =A0 This is just substituting the word Base for Abstract, however, and is=
 really
> =A0 not much different than the above.
>
> =A0* Use generic, descriptive names indicative of functionality or behavi=
or. As
> =A0 examples from the SPL, "Countable", "Iterator", "ArrayObject".
>
> My recommendation is to use the latter, as it solves all considerations. =
It will
> take more thought when naming, but will ensure that components can live i=
n a
> self-contained namespace, do not use reserved keywords, and avoid Hungari=
an
> Notation.
>
> Plan for implementation
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> I recommend that the Coding Standards documentation be updated to reflect=
 this
> approach.
>
> All new components going into 1.8 and onwards should adopt these standard=
s. In
> releases 1.9 and forward, we will begin migrating existing interfaces/abs=
tract
> classe. First, new classes/interfaces will be created that follow these
> conventions and which extend the originals; later, any type-hinting based=
 on the
> original class/interface names will be updated to point to the new names;=
 and
> finally, in 2.0, we will remove the old interfaces/abstract classes entir=
ely.
>
> --
> Matthew Weier O'Phinney
> Software Architect =A0 =A0 =A0| [email-masked]
> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Vincent de Lau" <[email-masked]>
To: "'Ralph Schindler'" <[email-masked]>,
	<[email-masked]>
Date: Tue, 19 May 2009 19:07:07 +0200
Subject: RE: [zf-contributors] Zend_Session

> >    * __destruct() should then write the source array
> 
> __destruct() was also my first guess on the first writing of the
> component, but this proves to be VERY difficult.  In PHP, there is no
> "logical" destruction order.  Destruction order is determined by the
> number of outstanding references there are left to an object.
> Typically, destruction is triggered either when the last reference is
> destroyed, OR automagically at PHP SHUTDOWN time.
> 
> The other problem is that since __destruct happens at PHP shutdown
> time,
> you cannot throw any exception or you will get an E_FATAL, no stack
> pointer error.

Can register_shutdown_function()[1] be savely used to do this kind of stuff?
In other words, does a function registered with register_shutdown_function()
run before shutdown cleanup? Reading this[2] comment, I suppose it does.

Vincent de Lau
 [email-masked]

[1] http://php.net/register_shutdown_function
[2] http://php.net/register_shutdown_function#79493

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Mon, 6 Apr 2009 10:55:24 -0700
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] 1.8 PR feature list and *acknowledgements*

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B6E0.DCB5EBAE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all, it's that time again. I need everyone to reply with any and all
features that they have contributed to this release. Please feel free to
reply to the list, as I think it's useful for every contributor to know
what's going in to this release and provide feedback before it is
tagged. My apologies for sending this mail relatively late; I will send
the feature request mail for the 1.8 production release about a week
before we cut it.

=20

NOTE: For this release, we'd like to try something new in the feature
list- actually acknowledging the significant contributions that y' all
have made. J The format would be like this:

=20

* Zend_Application, contributed by Matthew Weier O'Phinney and Ben
Scholzen

=20

As a rule of thumb, this should include everyone who has contributed at
least 20% or more of code *and* documentation. We reserve the right to
put whatever we want in the feature list. ;) Also, it is *your*
responsibility to get the features to me before the release, along with
the appropriate acknowledgment list. If you do not send this in time to
include in the feature notes- typically a few days before production
releases- then all complaints can be directed to /dev/null. Only names
of individuals will be included; no company or project names allowed.
Finally, if you do not want your name on the list for whatever reason,
it is your prerogative. Just include a note that you would like to
remain anonymous.=20

=20

Keep in mind that this is another way for us to thank you for your
efforts. Regardless of whose name or what features are included in the
feature list, we recognize and appreciate all of your contributions. If
you'd like to get your name on the list for the next release, the best
way is to lead a component that interests you to completion.

Nuff said. Now send me your features! J

=20

,Wil

------_=_NextPart_001_01C9B6E0.DCB5EBAE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Hi all, it&#8217;s that time again. I need everyone =
to reply
with any and all features that they have contributed to this release. =
Please
feel free to reply to the list, as I think it&#8217;s useful for every
contributor to know what&#8217;s going in to this release and provide =
feedback before
it is tagged. My apologies for sending this mail relatively late; I will =
send
the feature request mail for the 1.8 production release about a week =
before we
cut it.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>NOTE: For this release, we&#8217;d like to try =
something new
in the feature list- actually acknowledging the significant =
contributions that
y&#8217; all have made. <span style=3D'font-family:Wingdings'>J</span> =
The format
would be like this:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>* Zend_Application, contributed by Matthew Weier =
O'Phinney
and Ben Scholzen<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>As a rule of thumb, this should include everyone =
who has
contributed at least 20% or more of code *<b>and</b>* documentation. We =
reserve
the right to put whatever we want in the feature list. ;) Also, it is =
*<b>your</b>*
responsibility to get the features to me before the release, along with =
the
appropriate acknowledgment list. If you do not send this in time to =
include in
the feature notes- typically a few days before production releases- then =
all complaints
can be directed to /dev/null. Only names of individuals will be =
included; no
company or project names allowed. Finally, if you do not want your name =
on the
list for whatever reason, it is your prerogative. Just include a note =
that you
would like to remain anonymous. <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Keep in mind that this is another way for us to =
thank you
for your efforts. Regardless of whose name or what features are included =
in the
feature list, we recognize and appreciate all of your contributions. If =
you&#8217;d
like to get your name on the list for the next release, the best way is =
to lead
a component that interests you to completion.<o:p></o:p></p>

<p class=3DMsoNormal><br>
Nuff said. Now send me your features! <span =
style=3D'font-family:Wingdings'>J</span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>,Wil<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9B6E0.DCB5EBAE--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 8 Oct 2009 11:25:46 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Marc Bennewitz <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] mailing list for contributors doesn't work on
	framework.zend.com

--0-1128482063-1255026346=:50518
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

The contributors list isn't archived (at least publicly) or even listed pub=
licly. Maybe the link should be removed?=0A=0A P=E1draic Brady=0A=0Ahttp://=
blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Fo=
undation Irish Representative=0A=0A=0A=0A=0A=0A____________________________=
____=0AFrom: Marc Bennewitz <[email-masked]>=0ATo: zf-contributors=
@lists.zend.com=0ASent: Thu, October 8, 2009 6:10:17 PM=0ASubject: [zf-cont=
ributors] mailing list for contributors doesn't work on framework.zend.com=
=0A=0AHi,=0A=0AThe mailing list for contributors doesn't work:=0Ahttp://fra=
mework.zend.com/archives/contributors=0A=0AERR:  An error occurred with thi=
s request: Action "contributors" does=0Anot exist and was not trapped in __=
call().=0A=0AThe link is shown here:=0Ahttp://framework.zend.com/wiki/displ=
ay/ZFDEV/Contributing+to+Zend+Framework#ContributingtoZendFramework-mailing=
lists=0A=0AAll other mailing lists are working=0A
--0-1128482063-1255026346=:50518
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">The contributors list isn't archived (at least publicly) or ev=
en listed publicly. Maybe the link should be removed?<br><div>&nbsp;</div><=
span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: times new=
 roman,new york,times,serif;" size=3D"3"><span style=3D"font-weight: bold;"=
>P=E1draic Brady<br><br></span></font><span style=3D"font-style: italic;"><=
font style=3D"font-family: times new roman,new york,times,serif;" size=3D"3=
"><a rel=3D"nofollow" target=3D"_blank" href=3D"http://blog.astrumfutura.co=
m">http://blog.astrumfutura.com</a><br><a rel=3D"nofollow" target=3D"_blank=
" href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.co=
m</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideur=
ope.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span=
></span><div><br></div><div
 style=3D"font-family: times new roman,new york,times,serif; font-size: 12p=
t;"><br><div style=3D"font-family: tahoma,new york,times,serif; font-size: =
8pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"fon=
t-weight: bold;">From:</span></b> Marc Bennewitz &lt;[email-masked]=
e&gt;<br><b><span style=3D"font-weight: bold;">To:</span></b> zf-contributo=
[email-masked]<br><b><span style=3D"font-weight: bold;">Sent:</span></b>=
 Thu, October 8, 2009 6:10:17 PM<br><b><span style=3D"font-weight: bold;">S=
ubject:</span></b> [zf-contributors] mailing list for contributors doesn't =
work on framework.zend.com<br></font><br>=0AHi,<br><br>The mailing list for=
 contributors doesn't work:<br><span><a target=3D"_blank" href=3D"http://fr=
amework.zend.com/archives/contributors">http://framework.zend.com/archives/=
contributors</a></span><br><br>ERR:&nbsp; An error occurred with this reque=
st: Action "contributors" does<br>not exist and was not trapped in __call()=
.<br><br>The link is shown here:<br><span><a target=3D"_blank" href=3D"http=
://framework.zend.com/wiki/display/ZFDEV/Contributing+to+Zend+Framework#Con=
tributingtoZendFramework-mailinglists">http://framework.zend.com/wiki/displ=
ay/ZFDEV/Contributing+to+Zend+Framework#ContributingtoZendFramework-mailing=
lists</a></span><br><br>All other mailing lists are working<br></div></div>=
</div></body></html>
--0-1128482063-1255026346=:50518--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 21 Jul 2009 16:34:04 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Test suite audit

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Sunday, 19 July 2009, 09:48 AM -0400):
> I've been auditing the test suite for the last few days, and just did a
> huge commit that fixes a number of problems encountered when running the
> full test suite (r16852).

... And I just finished with r16933.

At this point, on a default install of PHP with the default test
configuration, all tests should pass out-of-the-box.

I had to make a couple changes to the test suite, however.

First, I moved Zend_OpenId, Zend_Session, and Zend_Soap tests into a
"buffered" suite. These tests rely on PHP functionality that requires no
headers be sent prior to execution -- which is problematic when run
under PHPUnit (which likes to send lots of status output). If you want
to test these components as well as the rest of the suite, execute the
following from your tests/ directory:

    php AllTests.php

    OR

    php Zend/AllTests.php

Either one will execute the functionality.

Second, if your component relies on the MVC's request and/or response
objects, use the TestCase versions of them. They make a lot of errors go
away.

Finally, Ralph, Alex and I will be working on PHP 5.3 compatibility in
the next few days -- which means you'll see additional commits and fixes
to the test suite and isolated components. If you would like to help
out, feel free to let us know! However, if you do, please be sure that
any changes you make that enable tests to pass under PHP 5.3 are also
vetted against PHP 5.2 to ensure we retain backwards compatibility.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 1 Apr 2010 18:56:59 +0100
From: Juozas <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

--001485f03c8adfaaf8048330960a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Now +1 from me, exactly as I would like to have it.

Just to mention - __invoke is very nice for array_map, array_filter and all
those other functions accepting callables. So now you don't need to use
array_umap, but can just pass $filter object. Same with validator: you can
use array_filter to get all array entries which are valid/invalid... A lot
of nice use cases.

But, as we (almost) agreed here - __invoke is better off in the
implementation side, rather than in the interface. Just makes interface
actually mean something.

--
Juozas Kaziuk=C4=97nas ([email-masked])
My website - JuoKaz (http://www.juokaz.com)

On Thu, Apr 1, 2010 at 6:19 PM, Matthew Weier O'Phinney <[email-masked]>w=
rote:

> Ralph and I were just talking about this, and had a realization.
>
> is_callable() returns true for objects that implement __invoke().
>
> What this means is: even for filter chains and the like, we simply test
> to see if what was passed is callable. If not, we throw an exception or
> use another strategy. (In Phly_PubSub, if I get a non-callable first
> argument, I check for a second argument, which would be the method to
> call on the first argument.)
>
> As such, he and I are leaning towards no definition of __invoke() in the
> interface, but defining it in the abstract classes and/or concrete
> classes that implement the interface. This solves the issue of ensuring
> clear interfaces, while also solving the issue of using __invoke() as a
> general-purpose, consistent callback paradigm within the framework.
>
> Thoughts?
>
> -- Matthew Weier O'Phinney <[email-masked]> wrote
> (on Thursday, 01 April 2010, 11:43 AM -0400):
> > -- Dolf Schimmel <[email-masked]> wrote
> > (on Thursday, 01 April 2010, 04:48 PM +0200):
> > > > Now, since the Symfony Live conference, I've also been thinking abo=
ut
> > > > something Fabien said about Symfony 2: "less magic." To clarify, th=
e
> > > > idea is to design components so that they are explicit about what
> they
> > > > can do. As an example, instead of using __get() and __set(), using
> > > > explicit getters and setters; instead of using __call(), explicitly
> > > > defining methods; instead of having __call() proxy to helpers, havi=
ng
> a
> > > > broker from which you pull them as needed.
> > >
> > > Apparently the rumors on twitter were in place; the conference did
> > > have a bad influence on you :D
> >
> > Umm... there are good ideas everywhere, and bad ones as well. Neither Z=
F
> > nor SF have a monopoloy on either.
> >
> > > More seriously, I think this can in no way be compared with SF's
> > > "magic" (does the fact that our Zend_Magic only is imaginative mean Z=
F
> > > does at this moment not contain any magic?).
> >
> > I wasn't trying to explicitly link the two. In fact, the examples I gav=
e
> > were examples of applying Fabien's ideas to ZF.
> >
> > > Firstly, if you have a class called foo\Filter which contains an
> > > __invoke() method,
> > > that method should obviously filter. As long as it does that and only
> > > that, there's no magic imho involved.
> >
> > I can see this POV. For somebody who doesn't know what the interface's
> > purpose is, however, it's less clear. Let me point that out with your
> > next examples:
> >
> > > Same goes for foo\Validator (its
> > > __invoke() method is supposed to validate), and foo\Bootstrap (guess
> > > what: __invoke() should bootstrap here).
> >
> > Validator defines two method types: validation, and error message
> > retrieval. In the original interface, this is pretty clear: isValid()
> > and getMessages(). If we change to __invoke() and getMessages(), the
> > latter method is clear, but the former is not -- what exactly is
> > happening here?
> >
> > Looking at the bootstrap, this is also a bit more unclear: right now, w=
e
> > have a bootstrap() method and a run() method: which one does __invoke()
> > define? Resources might be a bit more clear: the init() method might
> > make sense to instead map to __invoke() -- but the intent is less clear=
.
> > init() at least implies that we're initializing something; what does
> > __invoke() do?
> >
> > > If we can get it done consistently I'm pretty sure everybody will be
> > > used to it within the first 5 seconds they look at a random piece of
> > > code.
> >
> > I *do* want to see consistency. I just don't want to sacrifice end-user
> > comprehension of the code. Our current usage of __call(), __get(), and
> > __set() throughout the framework *does* make the code less easy to
> > understand. I've had plenty of people indicate that they have had
> > trouble understanding view helpers because they can't find the methods
> > in the view object; I don't want the same thing happening with usage of
> > __invoke().
> >
> > > Secondly Symfony's magic is on an entirely different scale of
> > > magnitude than the naming of one type of method.  Compare
> > > $random->method() generating an entire application for you with
> > > $object() which exactly does what the name of the object implies.
> >
> > Please see my notes above. I wasn't talking about this type of magic.
> >
> > > Situations in which you have two methods doing exactly the same are
> > > often/usually a result of willing to change, but also struggling with
> > > inability to do so due to backwards compatibility constraints.
> > > However, now that we're busy on something where potentially all BC ma=
y
> > > be broken, I really don't think having two methods doing exactly the
> > > same would be beneficial to anybody. In fact, it would increase the
> > > amount of options to do something with (give or take) N! which is an
> > > awful lot, without any added value.
> >
> > This is the primary argument I can see against having both an explicit
> > method name defined and __invoke(), and it hits home with other
> > complaints about the current state of ZF: understanding how ZF is
> > difficult when there's more than one way to do things.
> >
> > I want to be clear that the primary reason for using __invoke() in the
> > first place is for dynamic calls using call_user_func() and
> > call_user_func_array(). While using __invoke() with these is faster tha=
n
> > a traditional callback, it's still way slower than calling the method
> > directly -- around 3 times slower. __invoke() simply provides a slight
> > optimization in a pattern that we're likely to use many, many times
> > throughout a given request.
> >
> > For single usage, though, would you rather do this:
> >
> >     $value =3D $plugin($data);
> >
> >     or:
> >
> >     $value =3D $plugin->filter($data);
> >
> > I realize it's a bit contrived -- you might name the object to better
> > describe its purpose. However, the latter more clearly explains what
> > you're doing to the data: you're filtering it. Let's look at a
> > validator:
> >
> >     $test =3D $plugin($value);
> >
> >     or:
> >
> >     $test =3D $plugin->isValid($value);
> >
> > I actually think this one benefits a ton -- even with a well-named
> > variable:
> >
> >     $test =3D $validator($value);
> >
> > What is "$validator"? and what is it doing here? When we call the
> > method, we know we're checking for validity; when we call it via
> > __invoke(), we could be filtering it, validating it, pushing in a
> > value... who knows?
> >
> > In my earlier post, I probably should have made it more clear: I see
> > __invoke() as a way to more easily and efficiently define and execute
> > *callbacks*, and hence my rationale that it makes sense to define both
> > an explicit method as well as __invoke() for those class types that wil=
l
> > be used with filter chains and/or brokers.
> >
> >
> > > On Thu, Apr 1, 2010 at 3:07 PM, Matthew Weier O'Phinney
> > > <[email-masked]> wrote:
> > > > I've been following this thread as well as discussions on IRC with
> > > > interest, as, honestly, I can completely buy into all arguments,
> which
> > > > are, to sum things up:
> > > >
> > > >  * Use only __invoke()
> > > >  * Use a method name specific to the interface
> > > >  * Use a standardized method name, such as "run" or "execute"
> > > >  * Use a combination of __invoke() and either a meaningful or
> > > >   standardized method name.
> > > >
> > > > I got to thinking about why I suggested "__invoke()" in the first
> place,
> > > > and went back to the plugin architecture page:
> > > >
> > > >  *
> http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures
> > > >
> > > > The original rationale was for using pubsub/filter chain systems. I=
n
> > > > such systems, you attach callbacks:
> > > >
> > > >    $chain->attach($callback);
> > > >
> > > > If your objects implement __invoke(), $callback can simply be your
> > > > object -- you're done. Otherwise, you also have to provide the
> method:
> > > >
> > > >    $chain->attach($object, $method);
> > > >
> > > > Interestingly, in this document, I also recommended that for existi=
ng
> > > > interfaces, __invoke() be added as an _additional_ method, and that
> it
> > > > should proxy to the appropriate interface method. In this case, we'=
d
> > > > simply be taking advantage of a language feature in places it makes
> > > > sense.
> > > >
> > > > Now, since the Symfony Live conference, I've also been thinking abo=
ut
> > > > something Fabien said about Symfony 2: "less magic." To clarify, th=
e
> > > > idea is to design components so that they are explicit about what
> they
> > > > can do. As an example, instead of using __get() and __set(), using
> > > > explicit getters and setters; instead of using __call(), explicitly
> > > > defining methods; instead of having __call() proxy to helpers, havi=
ng
> a
> > > > broker from which you pull them as needed.
> > > >
> > > > This has several implications:
> > > >
> > > >  * Less need for explicit documentation. If you have behaviors
> relying
> > > >   on the magic methods, developers *must* read the the documentatio=
n
> in
> > > >   order to know how a class/component works. If everything is
> explicit,
> > > >   the class is self-documenting, and you can get the information yo=
u
> > > >   need from API docs, your IDE, etc.
> > > >
> > > >  * Performance. Magic methods are reportedly less performant than
> using
> > > >   straight method calls (more on this later).
> > > >
> > > > These are important factors, and the test-driven developer in me
> > > > particularly likes less magic; it's much easier to test when you ha=
ve
> > > > explicit behaviors.
> > > >
> > > > That said, I decided to run some tests. These were the scenarios:
> > > >
> > > >  * No Proxying:
> > > >   * Defined "filter" method returns value
> > > >   * Defined "__call" method returns value
> > > >   * Defined "__invoke" method returns value
> > > >  * Proxying:
> > > >   * Defined "filter" method returns value
> > > >   * Defined "__call" method proxies to "filter"
> > > >   * Defined "__invoke" method proxies to "filter"
> > > >  * Inverse proxying
> > > >   * Defined "filter" method calls invoke (as "$this();")
> > > >   * Defined "__invoke" method returns value
> > > >  * call_user_func_array()
> > > >   * Using array($obj, 'filter') callback
> > > >   * Using __invoke() with no proxying
> > > >   * Using __invoke() with proxying
> > > >
> > > > The results were quite interesting. Across the board, using __call(=
)
> is
> > > > awful -- even if you simply return a value, it's on average 6x slow=
er
> > > > than a straight method call; proxying to another method, however,
> > > > doesn't take significantly longer (so long as you're not using
> > > > call_user_func_array() internally, that is).
> > > >
> > > > __invoke(), however, turns out to be quite different. When not
> proxying,
> > > > it's actually *faster* than a method call (about 25% on average).
> > > > Proxing __invoke() to a method call or doing the inverse are roughl=
y
> the
> > > > same speed -- about 2.5x slower than a straight method call (which,
> as
> > > > you'll note, is still over twice as fast as using __call()).
> > > >
> > > > What was *really* interesting, however, was using
> > > > call_user_func_array(), which is commonly used in filter chains
> and/or
> > > > brokers.  __invoke(), with or without proxying, *always* was around
> 30%
> > > > *faster* than using an explicit array($obj, $method) callback.
> > > >
> > > > So, what does this tell me?
> > > >
> > > >  * AVOID using __call(), particularly for often-used method calls.
> For
> > > >   helper systems, it will always be better to use a helper broker a=
nd
> > > >   command pattern.
> > > >
> > > >  * For classes meant to be used primarily with filter chains or
> brokers,
> > > >   DO use __invoke(), even if it simply proxies to another interface
> > > >   method.
> > > >
> > > > So, based on the design goals and the performance benchmarking, I'm
> > > > going to recommend that Filter and Validator (we renamed Validate t=
o
> > > > Validator) define an __invoke() method in addition to a more explic=
it
> > > > interface method, and that helpers also follow this pattern.
> > > >
> > > > -- Matthew Weier O'Phinney <[email-masked]> wrote
> > > > (on Wednesday, 31 March 2010, 10:21 AM -0400):
> > > >> Greetings, all --
> > > >>
> > > >> Per the roadmap, one change we're planning on making is making
> plugin
> > > >> usage consistent across components: plugins will implement
> __invoke(),
> > > >> which makes them inherently callable.
> > > >>
> > > >> In our refactoring branch, I've done this now with Zend_Filter.
> However,
> > > >> it required a ton of refactoring on the unit tests (had to either
> call
> > > >> __invoke() directly, or $filter($value)), and it got me to thinkin=
g:
> > > >>
> > > >> Would it make sense to keep the original interfaces (filter,
> isValid,
> > > >> render, etc.), but also implement __invoke() -- having it proxy to
> the
> > > >> appropriate interface method?
> > > >>
> > > >> As an example:
> > > >>
> > > >>     interface Filter
> > > >>     {
> > > >>         public function filter($value);
> > > >>         public function __invoke($value);
> > > >>     }
> > > >>
> > > >>     class Digits implements Filter
> > > >>     {
> > > >>         public function filter($value)
> > > >>         {
> > > >>             // ... logic...
> > > >>         }
> > > >>
> > > >>         public function __invoke($value)
> > > >>         {
> > > >>             return $this->filter($value);
> > > >>         }
> > > >>     }
> > > >>
> > > >> The benefits:
> > > >>
> > > >>  * Fewer changes necessary to existing unit tests
> > > >>  * interface method names may be more descriptive of intent
> > > >>
> > > >> Problems:
> > > >>
> > > >>  * Using __invoke() introduces overhead -- 2 method calls instead =
of
> one
> > > >>  * Redundancy (two methods doing the same thing)
> > > >>  * A few extra tests to write (to ensure __invoke works as expecte=
)
> > > >>
> > > >> After discussion with Ralph and Alex, I'm leaning towards having
> > > >> __invoke() as an _additional_ method, instead of replacing existin=
g
> > > >> methods.
> > > >>
> > > >> Any thoughts or comments?
> > > >>
> > > >> --
> > > >> Matthew Weier O'Phinney
> > > >> Project Lead            | [email-masked]
> > > >> Zend Framework          | http://framework.zend.com/
> > > >> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> > > >>
> > > >
> > > > --
> > > > Matthew Weier O'Phinney
> > > > Project Lead            | [email-masked]
> > > > Zend Framework          | http://framework.zend.com/
> > > > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> > > >
> > >
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead            | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--001485f03c8adfaaf8048330960a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Now +1 from me, exactly as I would like to have it.<br><div><br></div><div>=
Just to mention - __invoke is very nice for array_map, array_filter and all=
 those other functions accepting callables. So now you don&#39;t need to us=
e array_umap, but can just pass $filter object. Same with validator: you ca=
n use array_filter to get all array entries which are valid/invalid... A lo=
t of nice use cases.</div>
<div><br></div><div>But, as we (almost) agreed here - __invoke is better of=
f in the implementation side, rather than in the interface. Just makes inte=
rface actually mean something.</div><div><br clear=3D"all">--<br>Juozas Kaz=
iuk=C4=97nas (<a href=3D"mailto:[email-masked]">[email-masked]</a>)<b=
r>
My website - JuoKaz (<a href=3D"http://www.juokaz.com">http://www.juokaz.co=
m</a>)<br>
<br><br><div class=3D"gmail_quote">On Thu, Apr 1, 2010 at 6:19 PM, Matthew =
Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
m">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
Ralph and I were just talking about this, and had a realization.<br>
<br>
is_callable() returns true for objects that implement __invoke().<br>
<br>
What this means is: even for filter chains and the like, we simply test<br>
to see if what was passed is callable. If not, we throw an exception or<br>
use another strategy. (In Phly_PubSub, if I get a non-callable first<br>
argument, I check for a second argument, which would be the method to<br>
call on the first argument.)<br>
<br>
As such, he and I are leaning towards no definition of __invoke() in the<br=
interface, but defining it in the abstract classes and/or concrete<br>
classes that implement the interface. This solves the issue of ensuring<br>
clear interfaces, while also solving the issue of using __invoke() as a<br>
general-purpose, consistent callback paradigm within the framework.<br>
<br>
Thoughts?<br>
<div class=3D"im"><br>
-- Matthew Weier O&#39;Phinney &lt;<a href=3D"mailto:[email-masked]">matt=
[email-masked]</a>&gt; wrote<br>
</div>(on Thursday, 01 April 2010, 11:43 AM -0400):<br>
<div><div></div><div class=3D"h5">&gt; -- Dolf Schimmel &lt;<a href=3D"mail=
to:[email-masked]">[email-masked]</a>&gt; wrote<br>
&gt; (on Thursday, 01 April 2010, 04:48 PM +0200):<br>
&gt; &gt; &gt; Now, since the Symfony Live conference, I&#39;ve also been t=
hinking about<br>
&gt; &gt; &gt; something Fabien said about Symfony 2: &quot;less magic.&quo=
t; To clarify, the<br>
&gt; &gt; &gt; idea is to design components so that they are explicit about=
 what they<br>
&gt; &gt; &gt; can do. As an example, instead of using __get() and __set(),=
 using<br>
&gt; &gt; &gt; explicit getters and setters; instead of using __call(), exp=
licitly<br>
&gt; &gt; &gt; defining methods; instead of having __call() proxy to helper=
s, having a<br>
&gt; &gt; &gt; broker from which you pull them as needed.<br>
&gt; &gt;<br>
&gt; &gt; Apparently the rumors on twitter were in place; the conference di=
d<br>
&gt; &gt; have a bad influence on you :D<br>
&gt;<br>
&gt; Umm... there are good ideas everywhere, and bad ones as well. Neither =
ZF<br>
&gt; nor SF have a monopoloy on either.<br>
&gt;<br>
&gt; &gt; More seriously, I think this can in no way be compared with SF&#3=
9;s<br>
&gt; &gt; &quot;magic&quot; (does the fact that our Zend_Magic only is imag=
inative mean ZF<br>
&gt; &gt; does at this moment not contain any magic?).<br>
&gt;<br>
&gt; I wasn&#39;t trying to explicitly link the two. In fact, the examples =
I gave<br>
&gt; were examples of applying Fabien&#39;s ideas to ZF.<br>
&gt;<br>
&gt; &gt; Firstly, if you have a class called foo\Filter which contains an<=
br>
&gt; &gt; __invoke() method,<br>
&gt; &gt; that method should obviously filter. As long as it does that and =
only<br>
&gt; &gt; that, there&#39;s no magic imho involved.<br>
&gt;<br>
&gt; I can see this POV. For somebody who doesn&#39;t know what the interfa=
ce&#39;s<br>
&gt; purpose is, however, it&#39;s less clear. Let me point that out with y=
our<br>
&gt; next examples:<br>
&gt;<br>
&gt; &gt; Same goes for foo\Validator (its<br>
&gt; &gt; __invoke() method is supposed to validate), and foo\Bootstrap (gu=
ess<br>
&gt; &gt; what: __invoke() should bootstrap here).<br>
&gt;<br>
&gt; Validator defines two method types: validation, and error message<br>
&gt; retrieval. In the original interface, this is pretty clear: isValid()<=
br>
&gt; and getMessages(). If we change to __invoke() and getMessages(), the<b=
r>
&gt; latter method is clear, but the former is not -- what exactly is<br>
&gt; happening here?<br>
&gt;<br>
&gt; Looking at the bootstrap, this is also a bit more unclear: right now, =
we<br>
&gt; have a bootstrap() method and a run() method: which one does __invoke(=
)<br>
&gt; define? Resources might be a bit more clear: the init() method might<b=
r>
&gt; make sense to instead map to __invoke() -- but the intent is less clea=
r.<br>
&gt; init() at least implies that we&#39;re initializing something; what do=
es<br>
&gt; __invoke() do?<br>
&gt;<br>
&gt; &gt; If we can get it done consistently I&#39;m pretty sure everybody =
will be<br>
&gt; &gt; used to it within the first 5 seconds they look at a random piece=
 of<br>
&gt; &gt; code.<br>
&gt;<br>
&gt; I *do* want to see consistency. I just don&#39;t want to sacrifice end=
-user<br>
&gt; comprehension of the code. Our current usage of __call(), __get(), and=
<br>
&gt; __set() throughout the framework *does* make the code less easy to<br>
&gt; understand. I&#39;ve had plenty of people indicate that they have had<=
br>
&gt; trouble understanding view helpers because they can&#39;t find the met=
hods<br>
&gt; in the view object; I don&#39;t want the same thing happening with usa=
ge of<br>
&gt; __invoke().<br>
&gt;<br>
&gt; &gt; Secondly Symfony&#39;s magic is on an entirely different scale of=
<br>
&gt; &gt; magnitude than the naming of one type of method. =C2=A0Compare<br=
&gt; &gt; $random-&gt;method() generating an entire application for you wit=
h<br>
&gt; &gt; $object() which exactly does what the name of the object implies.=
<br>
&gt;<br>
&gt; Please see my notes above. I wasn&#39;t talking about this type of mag=
ic.<br>
&gt;<br>
&gt; &gt; Situations in which you have two methods doing exactly the same a=
re<br>
&gt; &gt; often/usually a result of willing to change, but also struggling =
with<br>
&gt; &gt; inability to do so due to backwards compatibility constraints.<br=
&gt; &gt; However, now that we&#39;re busy on something where potentially a=
ll BC may<br>
&gt; &gt; be broken, I really don&#39;t think having two methods doing exac=
tly the<br>
&gt; &gt; same would be beneficial to anybody. In fact, it would increase t=
he<br>
&gt; &gt; amount of options to do something with (give or take) N! which is=
 an<br>
&gt; &gt; awful lot, without any added value.<br>
&gt;<br>
&gt; This is the primary argument I can see against having both an explicit=
<br>
&gt; method name defined and __invoke(), and it hits home with other<br>
&gt; complaints about the current state of ZF: understanding how ZF is<br>
&gt; difficult when there&#39;s more than one way to do things.<br>
&gt;<br>
&gt; I want to be clear that the primary reason for using __invoke() in the=
<br>
&gt; first place is for dynamic calls using call_user_func() and<br>
&gt; call_user_func_array(). While using __invoke() with these is faster th=
an<br>
&gt; a traditional callback, it&#39;s still way slower than calling the met=
hod<br>
&gt; directly -- around 3 times slower. __invoke() simply provides a slight=
<br>
&gt; optimization in a pattern that we&#39;re likely to use many, many time=
s<br>
&gt; throughout a given request.<br>
&gt;<br>
&gt; For single usage, though, would you rather do this:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 $value =3D $plugin($data);<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 or:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 $value =3D $plugin-&gt;filter($data);<br>
&gt;<br>
&gt; I realize it&#39;s a bit contrived -- you might name the object to bet=
ter<br>
&gt; describe its purpose. However, the latter more clearly explains what<b=
r>
&gt; you&#39;re doing to the data: you&#39;re filtering it. Let&#39;s look =
at a<br>
&gt; validator:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 $test =3D $plugin($value);<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 or:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 $test =3D $plugin-&gt;isValid($value);<br>
&gt;<br>
&gt; I actually think this one benefits a ton -- even with a well-named<br>
&gt; variable:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 $test =3D $validator($value);<br>
&gt;<br>
&gt; What is &quot;$validator&quot;? and what is it doing here? When we cal=
l the<br>
&gt; method, we know we&#39;re checking for validity; when we call it via<b=
r>
&gt; __invoke(), we could be filtering it, validating it, pushing in a<br>
&gt; value... who knows?<br>
&gt;<br>
&gt; In my earlier post, I probably should have made it more clear: I see<b=
r>
&gt; __invoke() as a way to more easily and efficiently define and execute<=
br>
&gt; *callbacks*, and hence my rationale that it makes sense to define both=
<br>
&gt; an explicit method as well as __invoke() for those class types that wi=
ll<br>
&gt; be used with filter chains and/or brokers.<br>
&gt;<br>
&gt;<br>
&gt; &gt; On Thu, Apr 1, 2010 at 3:07 PM, Matthew Weier O&#39;Phinney<br>
&gt; &gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br>
&gt; &gt; &gt; I&#39;ve been following this thread as well as discussions o=
n IRC with<br>
&gt; &gt; &gt; interest, as, honestly, I can completely buy into all argume=
nts, which<br>
&gt; &gt; &gt; are, to sum things up:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0* Use only __invoke()<br>
&gt; &gt; &gt; =C2=A0* Use a method name specific to the interface<br>
&gt; &gt; &gt; =C2=A0* Use a standardized method name, such as &quot;run&qu=
ot; or &quot;execute&quot;<br>
&gt; &gt; &gt; =C2=A0* Use a combination of __invoke() and either a meaning=
ful or<br>
&gt; &gt; &gt; =C2=A0 standardized method name.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I got to thinking about why I suggested &quot;__invoke()&quo=
t; in the first place,<br>
&gt; &gt; &gt; and went back to the plugin architecture page:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0* <a href=3D"http://framework.zend.com/wiki/display/ZF=
DEV2/Plugin+Architectures" target=3D"_blank">http://framework.zend.com/wiki=
/display/ZFDEV2/Plugin+Architectures</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The original rationale was for using pubsub/filter chain sys=
tems. In<br>
&gt; &gt; &gt; such systems, you attach callbacks:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0 =C2=A0$chain-&gt;attach($callback);<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If your objects implement __invoke(), $callback can simply b=
e your<br>
&gt; &gt; &gt; object -- you&#39;re done. Otherwise, you also have to provi=
de the method:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0 =C2=A0$chain-&gt;attach($object, $method);<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Interestingly, in this document, I also recommended that for=
 existing<br>
&gt; &gt; &gt; interfaces, __invoke() be added as an _additional_ method, a=
nd that it<br>
&gt; &gt; &gt; should proxy to the appropriate interface method. In this ca=
se, we&#39;d<br>
&gt; &gt; &gt; simply be taking advantage of a language feature in places i=
t makes<br>
&gt; &gt; &gt; sense.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Now, since the Symfony Live conference, I&#39;ve also been t=
hinking about<br>
&gt; &gt; &gt; something Fabien said about Symfony 2: &quot;less magic.&quo=
t; To clarify, the<br>
&gt; &gt; &gt; idea is to design components so that they are explicit about=
 what they<br>
&gt; &gt; &gt; can do. As an example, instead of using __get() and __set(),=
 using<br>
&gt; &gt; &gt; explicit getters and setters; instead of using __call(), exp=
licitly<br>
&gt; &gt; &gt; defining methods; instead of having __call() proxy to helper=
s, having a<br>
&gt; &gt; &gt; broker from which you pull them as needed.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This has several implications:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0* Less need for explicit documentation. If you have be=
haviors relying<br>
&gt; &gt; &gt; =C2=A0 on the magic methods, developers *must* read the the =
documentation in<br>
&gt; &gt; &gt; =C2=A0 order to know how a class/component works. If everyth=
ing is explicit,<br>
&gt; &gt; &gt; =C2=A0 the class is self-documenting, and you can get the in=
formation you<br>
&gt; &gt; &gt; =C2=A0 need from API docs, your IDE, etc.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0* Performance. Magic methods are reportedly less perfo=
rmant than using<br>
&gt; &gt; &gt; =C2=A0 straight method calls (more on this later).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; These are important factors, and the test-driven developer i=
n me<br>
&gt; &gt; &gt; particularly likes less magic; it&#39;s much easier to test =
when you have<br>
&gt; &gt; &gt; explicit behaviors.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; That said, I decided to run some tests. These were the scena=
rios:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0* No Proxying:<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;filter&quot; method returns value<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;__call&quot; method returns value<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;__invoke&quot; method returns value<b=
r>
&gt; &gt; &gt; =C2=A0* Proxying:<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;filter&quot; method returns value<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;__call&quot; method proxies to &quot;=
filter&quot;<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;__invoke&quot; method proxies to &quo=
t;filter&quot;<br>
&gt; &gt; &gt; =C2=A0* Inverse proxying<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;filter&quot; method calls invoke (as =
&quot;$this();&quot;)<br>
&gt; &gt; &gt; =C2=A0 * Defined &quot;__invoke&quot; method returns value<b=
r>
&gt; &gt; &gt; =C2=A0* call_user_func_array()<br>
&gt; &gt; &gt; =C2=A0 * Using array($obj, &#39;filter&#39;) callback<br>
&gt; &gt; &gt; =C2=A0 * Using __invoke() with no proxying<br>
&gt; &gt; &gt; =C2=A0 * Using __invoke() with proxying<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The results were quite interesting. Across the board, using =
__call() is<br>
&gt; &gt; &gt; awful -- even if you simply return a value, it&#39;s on aver=
age 6x slower<br>
&gt; &gt; &gt; than a straight method call; proxying to another method, how=
ever,<br>
&gt; &gt; &gt; doesn&#39;t take significantly longer (so long as you&#39;re=
 not using<br>
&gt; &gt; &gt; call_user_func_array() internally, that is).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; __invoke(), however, turns out to be quite different. When n=
ot proxying,<br>
&gt; &gt; &gt; it&#39;s actually *faster* than a method call (about 25% on =
average).<br>
&gt; &gt; &gt; Proxing __invoke() to a method call or doing the inverse are=
 roughly the<br>
&gt; &gt; &gt; same speed -- about 2.5x slower than a straight method call =
(which, as<br>
&gt; &gt; &gt; you&#39;ll note, is still over twice as fast as using __call=
()).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; What was *really* interesting, however, was using<br>
&gt; &gt; &gt; call_user_func_array(), which is commonly used in filter cha=
ins and/or<br>
&gt; &gt; &gt; brokers. =C2=A0__invoke(), with or without proxying, *always=
* was around 30%<br>
&gt; &gt; &gt; *faster* than using an explicit array($obj, $method) callbac=
k.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So, what does this tell me?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0* AVOID using __call(), particularly for often-used me=
thod calls. For<br>
&gt; &gt; &gt; =C2=A0 helper systems, it will always be better to use a hel=
per broker and<br>
&gt; &gt; &gt; =C2=A0 command pattern.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =C2=A0* For classes meant to be used primarily with filter c=
hains or brokers,<br>
&gt; &gt; &gt; =C2=A0 DO use __invoke(), even if it simply proxies to anoth=
er interface<br>
&gt; &gt; &gt; =C2=A0 method.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So, based on the design goals and the performance benchmarki=
ng, I&#39;m<br>
&gt; &gt; &gt; going to recommend that Filter and Validator (we renamed Val=
idate to<br>
&gt; &gt; &gt; Validator) define an __invoke() method in addition to a more=
 explicit<br>
&gt; &gt; &gt; interface method, and that helpers also follow this pattern.=
<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -- Matthew Weier O&#39;Phinney &lt;<a href=3D"mailto:matthew=
@zend.com">[email-masked]</a>&gt; wrote<br>
&gt; &gt; &gt; (on Wednesday, 31 March 2010, 10:21 AM -0400):<br>
&gt; &gt; &gt;&gt; Greetings, all --<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Per the roadmap, one change we&#39;re planning on making=
 is making plugin<br>
&gt; &gt; &gt;&gt; usage consistent across components: plugins will impleme=
nt __invoke(),<br>
&gt; &gt; &gt;&gt; which makes them inherently callable.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; In our refactoring branch, I&#39;ve done this now with Z=
end_Filter. However,<br>
&gt; &gt; &gt;&gt; it required a ton of refactoring on the unit tests (had =
to either call<br>
&gt; &gt; &gt;&gt; __invoke() directly, or $filter($value)), and it got me =
to thinking:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Would it make sense to keep the original interfaces (fil=
ter, isValid,<br>
&gt; &gt; &gt;&gt; render, etc.), but also implement __invoke() -- having i=
t proxy to the<br>
&gt; &gt; &gt;&gt; appropriate interface method?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; As an example:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 interface Filter<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 {<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function filter($valu=
e);<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function __invoke($va=
lue);<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 }<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 class Digits implements Filter<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 {<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function filter($valu=
e)<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... logic..=
.<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function __invoke($va=
lue)<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return $this-&=
gt;filter($value);<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
&gt; &gt; &gt;&gt; =C2=A0 =C2=A0 }<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; The benefits:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =C2=A0* Fewer changes necessary to existing unit tests<b=
r>
&gt; &gt; &gt;&gt; =C2=A0* interface method names may be more descriptive o=
f intent<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Problems:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =C2=A0* Using __invoke() introduces overhead -- 2 method=
 calls instead of one<br>
&gt; &gt; &gt;&gt; =C2=A0* Redundancy (two methods doing the same thing)<br=
&gt; &gt; &gt;&gt; =C2=A0* A few extra tests to write (to ensure __invoke w=
orks as expecte)<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; After discussion with Ralph and Alex, I&#39;m leaning to=
wards having<br>
&gt; &gt; &gt;&gt; __invoke() as an _additional_ method, instead of replaci=
ng existing<br>
&gt; &gt; &gt;&gt; methods.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Any thoughts or comments?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; --<br>
&gt; &gt; &gt;&gt; Matthew Weier O&#39;Phinney<br>
&gt; &gt; &gt;&gt; Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; &gt; &gt;&gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a hr=
ef=3D"http://framework.zend.com/" target=3D"_blank">http://framework.zend.c=
om/</a><br>
&gt; &gt; &gt;&gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew=
-pgp-key.asc" target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-ke=
y.asc</a><br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; --<br>
&gt; &gt; &gt; Matthew Weier O&#39;Phinney<br>
&gt; &gt; &gt; Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a h=
ref=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; &gt; &gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=
=3D"http://framework.zend.com/" target=3D"_blank">http://framework.zend.com=
/</a><br>
&gt; &gt; &gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp=
-key.asc" target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.as=
c</a><br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Matthew Weier O&#39;Phinney<br>
&gt; Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"mai=
lto:[email-masked]">[email-masked]</a><br>
&gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://f=
ramework.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" =
target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
&gt;<br>
<br>
</div></div>--<br>
<div><div></div><div class=3D"h5">Matthew Weier O&#39;Phinney<br>
Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:m=
[email-masked]">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</div></div></blockquote></div><br></div>

--001485f03c8adfaaf8048330960a--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 07 Feb 2010 01:52:46 +0100
From: Maghiel Dijksman <[email-masked]>
To: Dolf Schimmel <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] New Proposal: Change of
	ZendX_JQuery_View_Helper_AjaxLink
	(ZendX_JQuery_View_Helper_AjaxRequest etc)

Hello Dolf,

The wiki says: "Those considering submitting a proposal are strongly 
encouraged to present and discuss their idea on the mailing list before 
creating the proposal document so that it may be initially vetted by- 
and improved upon with the help of- the most active members of our 
community."
That's why I've send this mail around.

It's definately just a minor change(but useful imho, and I want to start 
of a bit small to get to know my way around here.)
but I wasn't sure if this had to go in proposals or not. Just eager to 
contribute something. I will contact Benjamin first!

Thanks for your answer!

Regards,
Maghiel

On 7-2-2010 1:22, Dolf Schimmel wrote:
> Hey Maghiel,
>
> Proposals should be put in the wiki, and should then be announced on
> the mailing lists (oh, and please do so in #zftalk.dev on freenode,
> irc) as all described here:
> http://framework.zend.com/wiki/display/ZFPROP/Proposal+Process
>
> As to what the actual proposal is concerned, imho (note: that's just
> an opinion) this is just a (slight) change in existing
> behavior/functionality. Therefore I think you better contact the
> maintainer of ZendX_Jquery (Benjamin Eberlei, aka Beberlei) for this
> rather than actually putting an entire proposal out - which is usually
> done for entire components.
>
> Regards,
>
> Dolf
> -- Freeaqingme
>
> On Sun, Feb 7, 2010 at 12:49 AM, Maghiel Dijksman<[email-masked]>  wrote:
>    
>> This is my first idea for a proposal that i submit to the mailing list, so
>> pardon me if i take the wrong steps
>> (and please correct me ;))
>>
>> I think it's a bit, ehm, weird that theres Zend_View_Helper_Url, which
>> returns a url as string,
>> and ZendX_JQuery_View_Helper_AjaxLink, which can only return a complete HTML
>> hyperlink (although
>> the naming DOES cleary state what you get).
>>
>> But what if a user wants to only have the JQuery function declaration
>> returned as string, by example
>> for usage in a onclick attribute of an element?
>> ZendX_JQuery_View_Helper_AjaxLink has the inline option,
>> but this makes the helper return a hyperlink with the function declared in
>> the onclick attribute of that hyperlink.
>> So the only option the user has in my use case is to either create his/her
>> own view helper, or declare the function
>> him/herself in the view.
>>
>> So I thought the following might be useful:
>> Drop: ZendX_JQuery_View_Helper_AjaxLink
>> Add:
>> ZendX_JQuery_View_Helper_AjaxRequest_Abstract
>> ZendX_JQuery_View_Helper_AjaxRequest (probably needs a better name :p)
>> ZendX_JQuery_View_Helper_AjaxRequest_Link
>>
>> Something like:
>> abstract class ZendX_JQuery_View_Helper_AjaxRequest_Abstract
>>     extends Zend_View_Helper_HtmlElement
>> {
>>     protected $_jQuery;
>>     protected $_jQHandler;
>>
>>     /**
>>      * Set JQuery view helper and JQuery Handler
>>      */
>>     public function __construct()
>>     {
>>         $this->_jQuery = $this->view->jQuery();
>>         $this->_jQuery->enable();
>>
>>         $this->_jQHandler = true ===
>> ZendX_JQuery_View_Helper_JQuery::getNoConflictMode() ? '$j' : '$';
>>     }
>>
>>     /**
>>      * Get js string for the given effect (example: $this->_jQHandler .
>> '(this).fadeOut();')
>>      *
>>      * @return string
>>      */
>>     protected function getEffect()
>>     {
>>     }
>>
>> }
>>
>> class ZendX_JQuery_View_Helper_AjaxRequest extends
>> ZendX_JQuery_View_Helper_AjaxRequest_Abstract
>> {
>>
>>     /**
>>      * Create inline JQuery function that enables ajax-based requests and
>> handling of the response.
>>      * @see ZendX_JQuery_View_Helper_AjaxLink
>>      *
>>      * @param string url
>>      * @param array $options (optional)
>>      * @param array $params (optional)
>>      * @return string
>>      */
>>     public function ajaxRequest($url, array $options = null, array $params =
>> null)
>>     {
>>     }
>>
>>     /**
>>      * Determine which request method (GET or POST) should be used.
>>      *
>>      * Normally the request method is determined implicitly by the rule,
>>      * if addiotional params are sent, POST, if not GET. You can overwrite
>>      * this behaviiour by implicitly setting $options['method'] = "POST|GET";
>>      *
>>      * @param  Array   $options
>>      * @param  Boolean $hasParams
>>      * @return String
>>      */
>>     protected function _determineRequestHandler($options, $hasParams)
>>     {
>>     }
>>
>> }
>>
>> class ZendX_JQuery_View_Helper_AjaxRequest_Link extends
>> ZendX_JQuery_View_Helper_AjaxRequest
>> {
>>
>>     private static $currentLinkCallbackId = 1;
>>
>>     public function ajaxLink($label, $url, $options=null, $params=null)
>>     {
>>         $js = parent::ajaxRequest($url, $options, $params);
>>
>>         // Etc
>>
>>         return $js;
>>     }
>>
>>     private function _getAttributes(array $attrib = array())
>>     {
>>     }
>>
>> }
>>
>>
>>
>> What do you guys think?
>> If i'm coming up with a stupid proposal please flame me (although useful
>> critics are more welcome ;))
>>
>> Regards,
>> Maghiel
>>
>>      
>
>    

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 14:30:40 -0700
From: Chris Boyce <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

>> =A03. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> I like (3) better, with small note that it doesn't have to be specific fo=
rm
> - i.e. just Element is better that trying to stick an unnatural prefix at
> the end of it (of course, if there's a natural one, like Countable, we're
> lucky :)

I like this approach. To me, it seems intuitive and not quite as
awkward as an Abstract suffix. For example, Countable seems much more
transparent than CountAbstract. Also, Element seems sufficiently vague
(or "abstract") that in a particular application I might not expect it
to be a concrete class. However, it might be enlightening to have a
sample of a broad selection of class names in the various conventions
to see shortcomings that may not be obvious with more convenient
examples.

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 5 Feb 2010 15:10:55 +0100
From: Maarten Balliauw <[email-masked]>
To: Juan Felipe Alvarez Saldarriaga <[email-masked]>
Cc: develop <[email-masked]>,
	Nigel Chapman <[email-masked]>, 
	Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

--0016e659fa9a21af2e047edb05b7
Content-Type: text/plain; charset=ISO-8859-1

Also check http://phplinq.codeplex.com for that matter. It's an abstraction
over arrays and optionally also over Zend_Db_Table, Windows Azure Table
Storage, ...

Maarten

On Fri, Feb 5, 2010 at 3:00 PM, Juan Felipe Alvarez Saldarriaga <
[email-masked]> wrote:

> Hey, nice proposal, a little bit like LINQ right? my concern is about
> performance too.
>
> Saludos.
>
> On Fri, Feb 5, 2010 at 3:56 AM, Carlos Medina
> <[email-masked]> wrote:
> > Nigel Chapman schrieb:
> >>
> >> Hi All,  (? -- not sure how active this list is.)
> >>
> >> Just a note to announce a new proposal:
> >>
> >> Zend_Array is a fluent wrapper for PHP's array functions.
> >>
> >> It lets you deal with arrays rather as you would in Ruby or JQuery,
> >> with chained operators and closures.
> >>
> >> Over the next few weeks, I'll be workign on the doc standards and test
> >> suite, and thinking if it needs more (or less!) core methods.
> >>
> >> Comments? Improvements?
> >>
> >> * http://chapman.id.au/zend-array/
> >>
> >> *
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman
> >>
> >> I sometimes appear on #zftalk as kale77in.
> >>
> >> Thanks,
> >>
> >> Nigel.
> >>
> >>
> >>
> >
> > Hi Nigel,
> > i think this is a very usefull proposal. The question is: performance?
> have
> > you tests about this.
> >
> > Regards
> >
> > Carlos
> >
>

--0016e659fa9a21af2e047edb05b7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Also check <a href=3D"http://phplinq.codeplex.com/">http://phplinq.cod=
eplex.com</a> for that matter. It&#39;s an abstraction over arrays and opti=
onally also over Zend_Db_Table, Windows Azure Table Storage, ...</div>
<div>=A0</div>
<div>Maarten<br><br></div>
<div class=3D"gmail_quote">On Fri, Feb 5, 2010 at 3:00 PM, Juan Felipe Alva=
rez Saldarriaga <span dir=3D"ltr">&lt;<a href=3D"mailto:jfalvarez@vesifront=
.org">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">Hey, nice proposal, a little bit=
 like LINQ right? my concern is about<br>performance too.<br><br>Saludos.<b=
r>
<br>On Fri, Feb 5, 2010 at 3:56 AM, Carlos Medina<br>&lt;<a href=3D"mailto:=
[email-masked]">[email-masked]</a>&gt; wrote:<br>&g=
t; Nigel Chapman schrieb:<br>&gt;&gt;<br>&gt;&gt; Hi All, =A0(? -- not sure=
 how active this list is.)<br>
&gt;&gt;<br>&gt;&gt; Just a note to announce a new proposal:<br>&gt;&gt;<br=
>&gt;&gt; Zend_Array is a fluent wrapper for PHP&#39;s array functions.<br>=
&gt;&gt;<br>&gt;&gt; It lets you deal with arrays rather as you would in Ru=
by or JQuery,<br>
&gt;&gt; with chained operators and closures.<br>&gt;&gt;<br>&gt;&gt; Over =
the next few weeks, I&#39;ll be workign on the doc standards and test<br>&g=
t;&gt; suite, and thinking if it needs more (or less!) core methods.<br>
&gt;&gt;<br>&gt;&gt; Comments? Improvements?<br>&gt;&gt;<br>&gt;&gt; * <a h=
ref=3D"http://chapman.id.au/zend-array/" target=3D"_blank">http://chapman.i=
d.au/zend-array/</a><br>&gt;&gt;<br>&gt;&gt; * <a href=3D"http://framework.=
zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman" target=3D"_blank">=
http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman</a=
><br>
&gt;&gt;<br>&gt;&gt; I sometimes appear on #zftalk as kale77in.<br>&gt;&gt;=
<br>&gt;&gt; Thanks,<br>&gt;&gt;<br>&gt;&gt; Nigel.<br>&gt;&gt;<br>&gt;&gt;=
<br>&gt;&gt;<br>&gt;<br>&gt; Hi Nigel,<br>&gt; i think this is a very usefu=
ll proposal. The question is: performance? have<br>
&gt; you tests about this.<br>&gt;<br>&gt; Regards<br>&gt;<br>&gt; Carlos<b=
r>&gt;<br></blockquote></div><br>

--0016e659fa9a21af2e047edb05b7--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 10:16:01 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Discussion about Quality/Review Process -
	Community RM proposal

-- Carlton Gibson <[email-masked]> wrote
(on Wednesday, 23 September 2009, 02:29 PM +0100):
> P draic makes many fine points. I just want to pause on one: 
> On 23 Sep 2009, at 13:52, P draic Brady wrote:
> 
> 
>     Documentation is the least of the worries. Mostly it's accurate, but it
>     does need a fuller review at some point, or a deliberate restart for Zend
>     Framework 2.0. It's main problem is that it's written by developers (that
>     will not change ;)) but also that it seems impervious to any form of
>     iterative improvement. Once written, documentation rarely changes and any
>     of its flaws become permanent problems that will very rarely ever reach the
>     issue tracker.
> 
> 
> [snip]
> 
> 
>     Of course all of my meandering has one simple problem - how to
>     motivate the community to actively take part and contribute their
>     time and skill.  Without that, it would all be doomed to failure
>     anyway.
> 
> 
> I know I've mentioned it before but having a wiki for the
> documentation would (I think) make _many_ more people contribute. 
> 
> The response previously was that we can't have a Wiki because of the
> need to use Docbook. Having pondered this response I can't see that it
> follows. Wikis are about collaborative editing, Docbook is a
> markup/storage format; surely the wiki could write to Docbook? (Does
> the software for this not already exist? I'm sure we could knock it up
> in Rails in no time :-) 

DocBook is the holy grail of documentation formats. It allows for easy
transformation of markup from XML to HTML, PDF, LaTeX, and much, much
more (I've even seen DocBook -> OO.o). Currently, we actually use
targets for HTML, PDF, and CHM (which is really just HTML zipped up
specially).

Additionally, having the documentation in docbook allows us to do things
such as easily version the documentation, do fallbacks from translations
to English, programmatically verify programlistings, etc.

Finally, having the docbook versioned ensures that only those who have
signed a CLA have rights to edit the documentation -- which is an
important part of the contribution process.

Is it possible to do wiki -> docbook conversions? Yes. But then we lose
many of the benefits already mentioned, add an extra step to the
process, and lose any sort of review process for ensuring good structure
and translations, AND we open up the very real possiblity of people
adding erroneous information without having peer review.

Yes, some of these issues exist in the existing documentation. However,
Thomas and Mikael have already spearheaded an effort to tighten up the
documentation process in terms of ensuring good document structure and
translation review. These facets very much hinge on using DocBook. On
top of this, since taking over as project lead, I've been reviewing
documentation prior to inclusion in trunk, in an attempt to ensure
better quality. Additionally, one part of the documentation effort is to
provide the ability to add comments within the manual. Once this
functionality is added, we can periodically review comments to see where
changes need to be made in the manual.

BTW, Rails *used* to use a wiki for documentation, but has since moved
to docbook. New documentation or community-contributed docs are in a
wiki, but migrated to docbook once they mature. The reasons for doing so
are very similar to those I've outlined above.

We will not be using the wiki for the official documentation, period.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 20 Oct 2009 21:51:36 +0400
From: Victor Farazdagi <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] oDesk API

Hi!
I want to create ZF proposal for recently released oDesk APIs 
(http://developers.odesk.com/).
Wanted to check out if that proposal would be interesting to anyone 
else? Is there actual need for such a proposal?

Thanks,
Victor

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Sat, 21 Mar 2009 23:05:43 -0700
From: "Wil Sinclair" <[email-masked]>
To: "Rob Allen" <[email-masked]>,
	<[email-masked]>
Subject: RE: [zf-contributors] Recording items for 1.8's readme?

Hey Rob, I usually compile the list right before the release. I usually
just ask everyone if there is anything worth mentioning in the release
notes and go from there. Would love to put a line item in there for this
feature, if I understood it. ;) Can you please put together a 1-2
sentence description of exactly what the new feature is?

Thanks.
,Wil

-----Original Message-----
From: Rob Allen [mailto:[email-masked]]=20
Sent: Saturday, March 21, 2009 3:04 PM
To: [email-masked]
Subject: [zf-contributors] Recording items for 1.8's readme?

Hi,

How is the list of features that goes into the README done?

Zend_Config_Xml now supports loading an XML string directly (e.g. from =20
a database) which may just be useful enough to enough people to =20
warrant a mention. But I don't know where to record this / who to tell.

What's the process that I no doubt should already be aware of ?!

Regards,

Rob...

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 06 Apr 2009 21:34:26 +0200
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*

Translation-aware Routes, contributed by Ben Scholzen
...................................
:  ___   _   ___ ___ ___ _ ___    :
: |   \ /_\ / __| _ \ _ (_)   \   :
: | |) / _ \\__ \  _/   / | |) |  :
: |___/_/:\_\___/_| |_|_\_|___/   :
:........:........................:
: Web    : http://www.dasprids.de :
: E-mail : [email-masked]       :
: Jabber : [email-masked]     :
: ICQ    : 105677955              :
:........:........................:

Wil Sinclair schrieb:
> I believe Zend_Navigation is in if the minor changes that we have
> recommended are made. Matthew can tell you more. It is a really sweet
> component, BTW. J
>=20
> =20
>=20
> ,Wil
>=20
> =20
>=20
> *From:* Robin Skoglund [mailto:[email-masked]]
> *Sent:* Monday, April 06, 2009 11:02 AM
> *To:* Wil Sinclair
> *Cc:* [email-masked]
> *Subject:* Re: [zf-contributors] 1.8 PR feature list and *acknowledgeme=
nts*
>=20
> =20
>=20
> On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <[email-masked]
> <mailto:[email-masked]>> wrote:
>=20
> NOTE: For this release, we=E2=80=99d like to try something new in the f=
eature
> list- actually acknowledging the significant contributions that y=E2=80=
=99 all
> have made. J The format would be like this:
>=20
> =20
>=20
> * Zend_Application, contributed by Matthew Weier O'Phinney and Ben Scho=
lzen
>=20
> =20
>=20
> ,Wil
>=20
> Hi, I haven't gotten any answer on whether Zend_Navigation will be
> included in the PR, but here goes:
>=20
> * Zend_Navigation, contributed by Robin Skoglund
>=20
>         robinsk
>=20

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 12:09:28 +0100
From: Julien Pauli <[email-masked]>
To: Giorgio Sironi <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

Yeah, PHPUnit is as complex as ZF is. Sebastian Bergmann makes a so
great job on this product , that PHPUnit migrations have to be well
thought.

I like the roadmap and getting ready to give hand for ZF2 ^^

J.Pauli

On Thu, Feb 25, 2010 at 11:46 AM, Giorgio Sironi
<[email-masked]> wrote:
> On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley <[email-masked]>
> wrote:
>>
>> In my opinion if Doctrine integration is to be left until ZF 2.0, then the
>> integrated version of Doctrine should be the 2.0 version. Since both 2.0
>> versions will require PHP 5.3.
>
> I agree. Doctrine 2 will fill the lack of model infrastructure in Zend
> Framework.
> Anyway, the set of changes listed by Matthew is already a big step towards
> simpler development (exploiting phpunit new features for example.)
>
> Regards,
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Fri, 22 Jan 2010 12:57:05 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: [zf-contributors] Doctrine 1 Integration Ideas

Hello everyone,

there hasn't been much news on this front lately, me was kinda busy with
work and such.

Yesterday I reviewed all the stuff i found on ZF and Doctrine 1
integration and came to
the conclusion that while single modular generation is supported by
Doctrine 1.2's new
PEAR style model generation you still have to hack lots around.

Therefore my idea is, two-fold:

I. Single ZF Module (Default)

Support Single-Default-Module Scenario more easily by providing a
config-option
that automatically sets all the model-generation options correctly. This
would
 be something along the lines of:

$import->setOptions(array(
    'pearStyle' =3D> true,
    'baseClassesDirectory' =3D> null,
    'baseClassPrefix' =3D> 'Base_',
    'classPrefix' =3D> 'Model_',
    'classPrefixFiles' =3D> true
));

This allows for models of the Style "Model_User", "Model_Foo",
"Model_Bar".

HOWEVER: Can someone explain to me how that relates to the class name tha=
t
you can
specifiy in the YAML config file?

No upgrade mechanism from single module to multiple module will be
provided.

II. Doctrine + Multiple ZF MOdules:

Circumvent Doctrine_Core::loadModels() completely by introducing a new
auto-loading
mechanism and slightly modifying the Doctrine_Import_Schema class.

This style would do no magic, it would require you to use class names of
the kind:

<ModuleName>_Model_<ModelName>

Doctrine would auto-load all the classes of the kind in all
<moduleName>/models through
a Module Resource Loader.

For the CLI tasks in Zend Tool there would be a dection of all models by
the mechanism.

1. Get Front Controller module/controller directory
2. Iteratore over them and find all models directories.
3. Recursively scan all models directories for
<ModuleName>_Model_<ModelName> classes.

For the YAML to Model Generation task the mechanism would be.

1. Detect Module name by checking the first result of explode("_",
$className)
2. If the first is "Model", grab default module from Front-Controller,
otherwise Check that second result is "Model"
3. Write record, base-record and optionally table classes into the module=
s
model directory.

This requires a Doctrine + Zend Modular Application to follow strict clas=
s
naming standards,
but makes the implementation very robust in terms of both frameworks and
avoids any
additional magic (Looking at the Doctrine 1 code, there is already too
much magic!)

Any ideas?

My plan is to get this into 1.11, I'll colaborate with Matthew Lurz also
to get the
Doctrine application resource ready for this then.

Also my plan is that this integration will require Doctrine 1.2

greetings,
Benjamin

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 00:21:47 -0700
From: Stanislav Malyshev <[email-masked]>
Organization: Zend Technologies
To: Ralph Schindler <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

Hi!

> <?php
>
> namespace Foo;
>
> class Bar
> {
> // this method accepts an instance of itself
> public static function baz(Bar $bar) {}
> }

I'm for this one. That's why we started all the thing with namespaces!

> <?php
> // this class has a use statement
>
> namespace Foo;
> use Qux\Garply as garp;
>
> class Bar
> {
> // this method accepts an instance of Qux\Garply\Bar
> public static function baz(garp\Bar $bar) {}
> }

And this one too, though you could "use" whole Qux\Garply\Bar as QGBar 
as well :)

> One thing to notice is that if method signatures contain a fully
> qualified name (those starting with a \) for type hints, you don't need
> to know anything about what namespaces or aliases are in play;
> everything you need to know is right in front of you. However, on the

I have faith that Framework developers actually can remember inside 
which class and namespace they are :)

> Should library/framework specific code be more expressive using fully
> qualified names in method signatures and consequently in docblocks? Or
> is using unqualified names just as easy to understand and/or more readable?

Docblocks present interesting challenge, if they are used for typing 
purposes. I guess there some solution might be needed, but maybe smart 
tools can solve it...
-- 
Stanislav Malyshev, Zend Software Architect
[email-masked]   http://www.zend.com/
(408)253-8829   MSN: [email-masked]

nFrom nobody Wed Apr  7 08:46:10 2010
From: "Vincent de Lau" <[email-masked]>
To: "'Matthew Weier O'Phinney'" <[email-masked]>,
	<[email-masked]>
Subject: RE: [zf-contributors] ZF 2.0 development begins!
Date: Thu, 25 Feb 2010 00:57:57 +0100

> -----Original Message-----
> From: Matthew Weier O'Phinney [mailto:[email-masked]]
> Sent: Thursday, February 25, 2010 12:06 AM
> 
> Those of you paying attention to the SVN commits will have noticed that
> I just created a new branch, development-2.0. This is a new branch
> intended for development of ZF 2.0.

<snip>
 
> For the initial development, I'm trying to (a) gauge what works, and 
> (b)
> get a good sense for the amount of work ahead, so I can estimate a
> release date. This latter will help determine if we should release a
> 1.11 release with new features between now and 2.0, or go straight to
> 2.0. 

Hooray! Good to hear that the first steps are taken. I was wondering about
the current state of things.

You are also mentioning 1.11, so I'll take to opportunity to ask: What are
the plans for Doctrine integration?

I can imagine a 1.11 being published with Doctrine 1.2 integration, but I
would also understand if this has to wait for ZF 2.0, maybe even with
Doctrine 2.

The reason I'm asking is because I'm planning some refactoring of existing
code based on ZF 1.7 and 1.9. I'm also planning to start using Doctrine.
I've got a couple of options (on order of preference):
- wait for a ZF 1 version with Doctrine integration
- use 1.10 for now and wait with Doctrine until ZF 2.0 is released
- use 1.10 and do a custom Doctrine integration

I can understand that you don't have the definitive answer ready yet (see
point b), but I'll take any indication.

Thanks,

Vincent de Lau

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Date: Mon, 6 Apr 2009 12:56:40 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [zf-contributors] 1.8 Preview Release

--_004_6B4A8009371807499638509271DEA796CC5925687BIMSCMAIL1imsc_
Content-Type: multipart/alternative;
	boundary="_000_6B4A8009371807499638509271DEA796CC5925687BIMSCMAIL1imsc_"

--_000_6B4A8009371807499638509271DEA796CC5925687BIMSCMAIL1imsc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Guys,

I am still working hard to get the docs done for the EC2 class.  I'm aiming=
 to later this week to be completed.  Will not being in the preview release=
 make it not eligible for the general release?

<http://zend.com/zce.php?c=3DZEND002524=
&r=3D219549271>

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]<mailto:[email-masked]>
P: (317) 492-8623 - F: (317) 492-6419

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

--_000_6B4A8009371807499638509271DEA796CC5925687BIMSCMAIL1imsc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Lucida Sans";
	panose-1:2 11 6 2 3 5 4 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal">Guys,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I am still working hard to get the docs done for the=
 EC2 class.&nbsp; I&#8217;m aiming to later this week to be completed.&nbsp=
; Will not being in the preview release make it not eligible for the genera=
l release?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<td width=3D"80" valign=3D"top" style=3D"width:60.0pt;padding:0in 0in 0in 0=
in">
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><a href=
=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><span style=
=3D"color:windowtext;text-decoration:none"><img border=3D"0" width=3D"73" h=
eight=3D"68" id=3D"Picture_x0020_1" src=3D"cid:[email-masked]=
60" alt=3D"php5_zce_logo_new"></span></a><span style=3D"font-size:12.0pt"><=
o:p></o:p></span></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Lu=
cida Sans&quot;,&quot;sans-serif&quot;">Jon Whitcraft<br>
Indianapolis Motor Speedway<br>
</span><span style=3D"font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><a href=3D"mailto:[email-masked]"><span style=3D=
"font-size:10.0pt;
  font-family:&quot;Lucida Sans&quot;,&quot;sans-serif&quot;;color:blue">jw=
[email-masked]</span></a><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span s=
tyle=3D"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-ser=
if&quot;">P: (317) 492-8623 - F: (317) 492-6419</span><span style=3D"font-s=
ize:9.0pt;font-family:
  &quot;Arial&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><br clear=3D"all">
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<br>
<font face=3D"Arial" color=3D"Gray" size=3D"1">********************<br>
********************<br>
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify
 the sender by reply E-mail and erase this E-mail from your system. Your as=
sistance is appreciated. E-mail transmission may not be secure or error-fre=
e. The company is not responsible for any loss/damage arising from any viru=
s transmitted.<br>
********************<br>
********************<br>
</font>
</body>
</html>

--_000_6B4A8009371807499638509271DEA796CC5925687BIMSCMAIL1imsc_--

--_004_6B4A8009371807499638509271DEA796CC5925687BIMSCMAIL1imsc_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=2553;
	creation-date="Mon, 06 Apr 2009 12:56:41 GMT";
	modification-date="Mon, 06 Apr 2009 12:56:41 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_004_6B4A8009371807499638509271DEA796CC5925687BIMSCMAIL1imsc_--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Fri, 22 Jan 2010 14:36:00 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors] Doctrine 1 Integration Ideas

Hey Paddy,

ah default module seems to be a problem, or not?. When should the default
prefix
be added, when not? How does the resource autoloader work in this context=
?

Questions:

1. How does the resource loader look like if default module is "default"?
2. How does the resource loader look like if default module is "blog"?

greetings,
Benjamin

On Fri, 22 Jan 2010 04:40:12 -0800 (PST), P=C3=A1draic Brady
<[email-masked]> wrote:
> Replies inline.
>=20
>>Hello everyone,
>>
>>there hasn't been much news on this front lately, me was kinda busy wit=
h
>>work and such.
>>
>>Yesterday I reviewed all the stuff i found on ZF and Doctrine 1
>>integration and came to
>>the conclusion that while single modular generation is supported by
>>Doctrine 1.2's new
>>PEAR style model generation you still have to hack lots around.
>>
>>Therefore my idea is, two-fold:
>>
>>I. Single ZF Module (Default)
>>
>>Support Single-Default-Module Scenario more easily by providing a
>>config-option
>>that automatically sets all the model-generation options correctly. Thi=
s
>>would
>>be something along the lines of:
>>
>>$import->setOptions(array(
>>    'pearStyle' =3D> true,
>>    'baseClassesDirectory' =3D> null,
>>    'baseClassPrefix' =3D> 'Base_',
>>    'classPrefix' =3D> 'Model_',
>>    'classPrefixFiles' =3D> true
>>));
>>
>>This allows for models of the Style "Model_User", "Model_Foo",
>>"Model_Bar".
>>
>>HOWEVER: Can someone explain to me how that relates to the class name
that
>>you can
>>specifiy in the YAML config file?
>=20
> As in a schema config? Schema would just use Model_User/Model_Foo in
this
> case. Not sure if that's what you meant though. The main settings above
of
> interest are classPrefix and classPrefixFiles. classPrefix would simply
> prepend the Module name for module autoloading, though I think
> classPrefixFiles would be false to omit the Module name from the actual
> files, so we just have, for example, /application/models/User.php and
> /application/models/Foo.php.
>=20
> Main thing I'd be interested in is of this option would support the mor=
e
> complex scenario of having a named default module, e.g.
> /application/modules/default (giving Default_Model_User at
> /application/modules/default/models/User.php). I use a named default al=
l
> the time, though of course the ZF CLI tool isn't exactly cooperative
with
> that ;).
>=20
>>No upgrade mechanism from single module to multiple module will be
>>provided.
>>
>>II. Doctrine + Multiple ZF MOdules:
>>
>>Circumvent Doctrine_Core::loadModels() completely by introducing a new
>>auto-loading
>>mechanism and slightly modifying the Doctrine_Import_Schema class.
>=20
> I'd circumvent it anyway, isn't there anyway to leverage off our alread=
y
> built in resource autoloading? That's already set up to handle all
module
> contingencies for models, forms, etc. assigned to directories with thos=
e
> names.
>=20
>>This style would do no magic, it would require you to use class names o=
f
>>the kind:
>>
>><ModuleName>_Model_<ModelName>
>>
>>Doctrine would auto-load all the classes of the kind in all
>><moduleName>/models through
>>a Module Resource Loader.
>=20
> Spoke too soon - yeah, that's the way it probably should work by
default.
> It's a current convention and if someone want's to start changing it
> around, they can do their thing with the local include_path by
themselves.
>=20
>>For the CLI tasks in Zend Tool there would be a dection of all models b=
y
>>the mechanism.
>>
>>1. Get Front Controller module/controller directory
>>2. Iteratore over them and find all models directories.
>>3. Recursively scan all models directories for
>><ModuleName>_Model_<ModelName> classes.
>>
>>For the YAML to Model Generation task the mechanism would be.
>>
>>1. Detect Module name by checking the first result of explode("_",
>>$className)
>>2. If the first is "Model", grab default module from Front-Controller,
>>otherwise Check that second result is "Model"
>>3. Write record, base-record and optionally table classes into the
modules
>>model directory.
>=20
> Bear in mind that any module name can be the default. Not sure if that
> makes any different if picked up as a distinct modules anyway.
>=20
>>This requires a Doctrine + Zend Modular Application to follow strict
class
>>naming standards,
>>but makes the implementation very robust in terms of both frameworks an=
d
>>avoids any
>>additional magic (Looking at the Doctrine 1 code, there is already too
>>much magic!)
>>
>>Any ideas?
>>
>>My plan is to get this into 1.11, I'll colaborate with Matthew Lurz als=
o
>>to get the
>>Doctrine application resource ready for this then.
>>
>>Also my plan is that this integration will require Doctrine 1.2
>=20
> Doctrine 1.2 is fine. Little point supporting an older version whose us=
e
> in new applications should be declining.
>=20
> greetings,
> Benjamin

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 6 Apr 2009 13:10:35 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] 1.8 Preview Release

-- Whitcraft, Jon <[email-masked]> wrote
(on Monday, 06 April 2009, 12:56 PM -0400):
> I am still working hard to get the docs done for the EC2 class.  I=E2=80=
=99m aiming to
> later this week to be completed.  Will not being in the preview release=
 make it
> not eligible for the general release?

No worries -- there are several pieces of functionality that won't be in
the preview release. Your time frame for completion should be just fine
for inclusion in the final release.

--=20
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 16:52:22 +0200
From: till <[email-masked]>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Cc: Benjamin Eberlei <[email-masked]>, 
	Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Discussion about Quality/Review Process - 
	Community RM proposal

On Wed, Sep 23, 2009 at 2:52 PM, P=E1draic Brady <[email-masked]> =
wrote:
> Hi Benjamin,
>
> To be honest, I'm not sure a Release Manager would solve the perceived
> problem. I'm not saying it's a bad idea, it probably is a good idea for a
> slightly different set of reasons. My main reservation is that applying a
> specific responsibility (prevent backwards compatibility breaks) to the r=
ole
> of Release Manager would be next to impossible to effectively implement
> without some drastic changes in how QA is applied to the source code. In
> fact, I'd go so far as to say discussing a Release Manager role is missin=
g
> the obvious target.

I must admit that I liked the idea of a RM (or well, 2 people, sharing
the position) last night.

Thinking about it today, I'm inclined to agree with Padraic. A RM
position would be a neat thing but I agree that it might be solving
something else -- e.g. spotting obvious issues so they don't make it
into a stable release. I'm not saying it's not needed, but a RM would
not solve other issues.

I do I think that Zend Framework needs a QA team that applies the
standards across the board and works with the leads/developers on the
various components. The duties would include anything from mentoring
people through the proposal process, making sure that code is
maintained (e.g. escalating obvious issues, maybe demoting components
to ZendX, etc.), double-checking if unit tests make sense (beyond code
coverage :-)), general code review or that the coding style is
applied.

The obvious issues are:

 a) Find people who know what it entails.

 b) Find people who have time.

 c) Authority. :-)

> Consider how QA works in Zend Framework. We have unit tests, documentatio=
n,
> the issue tracker, and with a little luck a responsible committer and/or
> Lead Developer per component. I think the issue tracker works just fine -=
 it
> desperately needs more community involvement and that's why I'm overjoyed=
 to
> take part in the Bug Hunts (and encourage, shame, blackmail others into
> taking part too ;)). The other three however have issues of their own.

I'm not sure on this, but (apologies for side-tracking this) is it
still that every bug reporter needs to sign a CLA?
I think if that is, there is community involvement. A CLA is def. a
turn off for drive-by bug-reporters/patches.

> (...) In an environment like this, any
> Release Manager is constantly being undermined and will be forced to
> personally peer review the entire component end to end, make a judgement
> call, and open themselves up to arguments from anyone effected.

+1

Till

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 28 Feb 2010 16:15:11 -0500
From: Juan Felipe Alvarez Saldarriaga <[email-masked]>
To: Zend Contributors List <[email-masked]>
Subject: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

And why not use cygwin's git? works wonderful for me on Windows 7 :D

On Fri, Feb 26, 2010 at 4:26 AM, Graham Anderson
<[email-masked]> wrote:
> On Friday 26 February 2010 09:27:12 Jurri=EBn Stutterheim wrote:
>>Unfortunately, (tooling) support for Git on Windows is severely lacking.
>
> This might have been a valid arguement a couple of years ago but not anym=
ore.
>
> Msysgit and tortoiseGit offer solid git support for the Windows desktop a=
nd
> Shawn Pearce has done an excellent job with the JGit library which serves=
 as
> the basis for quite mature Netbeans and Eclipse plugins.
>
> --
> =93What can be asserted without proof can be dismissed without proof.=94
> - Christopher Hitchens
>

nFrom nobody Wed Apr  7 08:46:10 2010
Date: Mon, 7 Dec 2009 14:23:59 -0800 (PST)
From: =?utf-8?B?UMOhZHJhaWMgQnJhZHk=?= <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>

--0-1836312247-1260224639=:66702
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I have one response. Two actually. The first, the public Twitter exchange, =
I can respond to by ranting in an equally public place on my blog. It invol=
ves a lot of f-words. The second, is that dissecting my blog and tweets wil=
l not reveal some dire dark motivation on my part no matter how it's presen=
ted. Nor does it, or anything else, have any bearing whatsoever on the issu=
e I reported. If there is a problem that the issue arose from a debate occu=
ring between Saturday night (when I published the article) until this morni=
ng when I sent the email then...politely...tough. Not my bad. I will not be=
 explaining this any further.=0A=0AAs regards the issue, I am sorely tempte=
d to simply withdraw from this mailing list and bombard you all from afar. =
Unfortunately, catapults are in short supply so I guess I'll respond with a=
 suitable email tomorrow to make my case clearer if possible.=0A=0A P=C3=A1=
draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepen=
d.com=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=0A=0A=0A____=
____________________________=0AFrom: Matthew Weier O'Phinney <matthew@zend.=
com>=0ATo: [email-masked]=0ASent: Mon, December 7, 2009 5:2=
7:43 PM=0ASubject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabili=
ties In Zend_Filter_StripTags=0A=0A-- P=C3=A1draic Brady <padraic.brady@yah=
oo.com> wrote=0A(on Monday, 07 December 2009, 08:34 AM -0800):=0A> >I'm mis=
sing the most important thing: write a unit test with known attack=0A> vect=
ors. If I'd want an improvement as important as security I'd write a unit=
=0A> test to prove that it works (or fails).=0A> > Putting the burden on so=
meone else by hiding testable examples in a blog post=0A> > or email leaves=
 a bad aftertaste.=0A> =0A> I apologise for exposing the stupidity of relyi=
ng on Zend_Filter_StripTags to=0A> prevent XSS, or even, like, strip tags. =
Truly. Sorry.=0A> =0A> Now read the blog and see where I three frigging tim=
es make it absolutely clear=0A> that at the time I wrote this I did NOT con=
sider this a security issue for the=0A> Zend Framework. I am ENTITLED to ch=
ange my mind after over a day of discussing=0A> it which is exactly what I =
did. In the future, however, I will keep my mouth=0A> shut. When I see some=
thing wrong, I will remain silent.=0A=0AMy point to you on twitter and in m=
y last post is that it was the=0Alanguage you used to report that is raisin=
g the most questions.=0A=0AIf your post title had been, "Zend_Filter_StripT=
ags: It's not an XSS=0Afilter, stupid!" the connotation would have been qui=
te different.=0AInstead, you use the phrase "Security Nightmare" in the tit=
le, which, as=0Aa project lead, immediately raises my guard and has me wond=
ering if a=0Asecurity vulnerability is being reported.=0A=0AFor the first h=
alf of your post I totally agree with. It's from the=0Apoint "Bring Forth t=
he Firing Squad" forward that I start to have=0Aissues. =0A=0AYour first ex=
ample with a self-closed <img> tag should have simply been=0Areported via t=
he issue tracker. It has nothing to do with your main=0Apoint, which was th=
at StripTags does not protect against XSS. Same goes=0Afor the second examp=
le (closing tags only example).=0A=0AYour third example made sense... up to=
 the sentence, "Given the=0Aobviousness of this, it should be apparent that=
 Zend_Filter_StripTags=0Aoffers an unknown level of XSS protection - i.e. i=
t's untrustworthy."=0A=0AAt this point, your language deviates, and it beco=
mes less clear if you=0Aare claiming that users should be leary of using St=
ripTags as it does=0Anot protect from XSS, or if you are claiming that it _=
introduces_ an=0AXSS. =0A=0AAdditionally, the way you advertised the post o=
n twitter makes this=0Aunclear:=0A=0A* "Some debate over the StripTags secu=
rity issues..."=0A   Makes it sound like there are security issues with the=
 component (not=0A   that if mis-used, you can introduce security issues)=
=0A=0A* "The #ZF StripTags issue proving a sad lesson. Too many people don'=
t=0A   actually understand XSS..."=0A   Makes it sound like StripTags has a=
n XSS vulnerability=0A=0A* "Have just confirmed a second XSS vulnerability =
in=0A   Zend_Filter_StripTags"=0A   Explicitly calls it out as having multi=
ple XSS vulnerabilities.=0A=0AIf you really don't feel that the component i=
s vulnerable, then why use=0Athat language and get everyone ranting and rav=
ing about it? =0A=0ADo I think the blog post was misguided? No -- I just th=
ink it could have=0Abeen better executed to make your main point clearer: d=
on't use=0AStripTags and think that you've protected yourself from XSS. And=
 when=0Atweeting about it, it would have made more sense to be explicit as =
well:=0A"More examples showing why StripTags is not an XSS filter..."=0A=0A=
Also, my critiques are not meant to silence you in any way. I simply=0Awant=
 to make it clear that you have to be careful when reporting=0Asecurity vul=
nerabilities. Proper security etiquette would have you=0Adiscuss and collab=
orate with the vendor to fix the issue _prior_ to=0Areporting publically. I=
n this case, since it wasn't an actual security=0Aissue, my point is to be =
careful how you post security-related=0Ainformation, to ensure that people =
don't jump to conclusions.=0A=0A> Yeah, like that will happen...:P. I rant =
- live with it.=0A> =0A> Paddy=0A> =0A> =0A>  =0A> P draic Brady=0A> =0A> h=
ttp://blog.astrumfutura.com=0A> http://www.survivethedeepend.com=0A> OpenID=
 Europe Foundation Irish Representative=0A> =0A> =0A> =E2=94=81=E2=94=81=E2=
=94=81=E2=94=81=0A> From: Nico Edtinger <[email-masked]>=0A=
> To: P draic Brady <[email-masked]>=0A> Sent: Mon, December 7, 20=
09 4:10:04 PM=0A> Subject: Re: [zf-contributors] XSS And Malformed HTML Vul=
nerabilities In=0A> Zend_Filter_StripTags=0A> =0A> Am 07.12.2009 um 15:26 s=
chrieb P draic Brady:=0A> =0A>     I would also suggest the following:=0A> =
=0A>     a) Rework the filter's current four lines of documentation (http:/=
/=0A>    framework.zend.com/manual/en/zend.filter.set.html#zend.filter.set.=
striptags=0A>     ) to cover the component in greater detail clarifying its=
 use cases,=0A>     potential for misuse, and clarifying it is not XSS  or =
malformed HTML safe.=0A>     b) Immediately deprecate in 1.9 branch (and re=
move in 2.0 - preferably 1.10=0A>     given its significance) its ability t=
o flexibly allow some HTML/comments=0A>     thus preserving its only truly =
worthwhile feature - stripping ALL HTML.=0A>     c) Do this ASAP.=0A> =0A> =
=0A> I'm missing the most important thing: write a unit test with known att=
ack=0A> vectors. If I'd want an improvement as important as security I'd wr=
ite a unit=0A> test to prove that it works (or fails). Putting the burden o=
n someone else by=0A> hiding testable examples in a blog post or email leav=
es a bad aftertaste.=0A> =0A> nico=0A=0A-- =0AMatthew Weier O'Phinney=0APro=
ject Lead            | [email-masked]=0AZend Framework          | http://=
framework.zend.com/=0A
--0-1836312247-1260224639=:66702
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">I have one response. Two actually. The first, the public Twitt=
er exchange, I can respond to by ranting in an equally public place on my b=
log. It involves a lot of f-words. The second, is that dissecting my blog a=
nd tweets will not reveal some dire dark motivation on my part no matter ho=
w it's presented. Nor does it, or anything else, have any bearing whatsoeve=
r on the issue I reported. If there is a problem that the issue arose from =
a debate occuring between Saturday night (when I published the article) unt=
il this morning when I sent the email then...politely...tough. Not my bad. =
I will not be explaining this any further.<br><br>As regards the issue, I a=
m sorely tempted to simply withdraw from this mailing list and bombard you =
all from afar. Unfortunately, catapults are in short supply so I guess
 I'll respond with a suitable email tomorrow to make my case clearer if pos=
sible.<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font sty=
le=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><span =
style=3D"font-weight: bold;">P=C3=A1draic Brady<br><br></span></font><span =
style=3D"font-style: italic;"><font style=3D"font-family: times new roman,n=
ew york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=
=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a re=
l=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com">=
http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_blan=
k" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Repr=
esentative</a><br></font></span></span><div><br></div><div style=3D"font-fa=
mily: times new roman,new york,times,serif; font-size: 12pt;"><br><div styl=
e=3D"font-family: tahoma,new york,times,serif; font-size: 8pt;"><font face=
=3D"Tahoma" size=3D"2"><hr
 size=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Matthew =
Weier O'Phinney &lt;[email-masked]&gt;<br><b><span style=3D"font-weight: =
bold;">To:</span></b> [email-masked]<br><b><span style=3D"f=
ont-weight: bold;">Sent:</span></b> Mon, December 7, 2009 5:27:43 PM<br><b>=
<span style=3D"font-weight: bold;">Subject:</span></b> Re: [zf-contributors=
] XSS And Malformed HTML Vulnerabilities In Zend_Filter_StripTags<br></font=
><br>=0A-- P=C3=A1draic Brady &lt;<a ymailto=3D"mailto:padraic.brady@yahoo.=
com" href=3D"mailto:[email-masked]">[email-masked]</a>&gt=
; wrote<br>(on Monday, 07 December 2009, 08:34 AM -0800):<br>&gt; &gt;I'm m=
issing the most important thing: write a unit test with known attack<br>&gt=
; vectors. If I'd want an improvement as important as security I'd write a =
unit<br>&gt; test to prove that it works (or fails).<br>&gt; &gt; Putting t=
he burden on someone else by hiding testable examples in a blog post<br>&gt=
; &gt; or email leaves a bad aftertaste.<br>&gt; <br>&gt; I apologise for e=
xposing the stupidity of relying on Zend_Filter_StripTags to<br>&gt; preven=
t XSS, or even, like, strip tags. Truly. Sorry.<br>&gt; <br>&gt; Now read t=
he blog and see where I three frigging times make it absolutely clear<br>&g=
t; that at the time I wrote this I did NOT consider this a security issue f=
or the<br>&gt; Zend Framework. I am ENTITLED to change my mind after over a=
 day of
 discussing<br>&gt; it which is exactly what I did. In the future, however,=
 I will keep my mouth<br>&gt; shut. When I see something wrong, I will rema=
in silent.<br><br>My point to you on twitter and in my last post is that it=
 was the<br>language you used to report that is raising the most questions.=
<br><br>If your post title had been, "Zend_Filter_StripTags: It's not an XS=
S<br>filter, stupid!" the connotation would have been quite different.<br>I=
nstead, you use the phrase "Security Nightmare" in the title, which, as<br>=
a project lead, immediately raises my guard and has me wondering if a<br>se=
curity vulnerability is being reported.<br><br>For the first half of your p=
ost I totally agree with. It's from the<br>point "Bring Forth the Firing Sq=
uad" forward that I start to have<br>issues. <br><br>Your first example wit=
h a self-closed &lt;img&gt; tag should have simply been<br>reported via the=
 issue tracker. It has nothing to do with your main<br>point, which
 was that StripTags does not protect against XSS. Same goes<br>for the seco=
nd example (closing tags only example).<br><br>Your third example made sens=
e... up to the sentence, "Given the<br>obviousness of this, it should be ap=
parent that Zend_Filter_StripTags<br>offers an unknown level of XSS protect=
ion - i.e. it's untrustworthy."<br><br>At this point, your language deviate=
s, and it becomes less clear if you<br>are claiming that users should be le=
ary of using StripTags as it does<br>not protect from XSS, or if you are cl=
aiming that it _introduces_ an<br>XSS. <br><br>Additionally, the way you ad=
vertised the post on twitter makes this<br>unclear:<br><br> * "Some debate =
over the StripTags security issues..."<br>&nbsp;  Makes it sound like there=
 are security issues with the component (not<br>&nbsp;  that if mis-used, y=
ou can introduce security issues)<br><br> * "The #ZF StripTags issue provin=
g a sad lesson. Too many people don't<br>&nbsp;  actually understand
 XSS..."<br>&nbsp;  Makes it sound like StripTags has an XSS vulnerability<=
br><br> * "Have just confirmed a second XSS vulnerability in<br>&nbsp;  Zen=
d_Filter_StripTags"<br>&nbsp;  Explicitly calls it out as having multiple X=
SS vulnerabilities.<br><br>If you really don't feel that the component is v=
ulnerable, then why use<br>that language and get everyone ranting and ravin=
g about it? <br><br>Do I think the blog post was misguided? No -- I just th=
ink it could have<br>been better executed to make your main point clearer: =
don't use<br>StripTags and think that you've protected yourself from XSS. A=
nd when<br>tweeting about it, it would have made more sense to be explicit =
as well:<br>"More examples showing why StripTags is not an XSS filter..."<b=
r><br>Also, my critiques are not meant to silence you in any way. I simply<=
br>want to make it clear that you have to be careful when reporting<br>secu=
rity vulnerabilities. Proper security etiquette would have
 you<br>discuss and collaborate with the vendor to fix the issue _prior_ to=
<br>reporting publically. In this case, since it wasn't an actual security<=
br>issue, my point is to be careful how you post security-related<br>inform=
ation, to ensure that people don't jump to conclusions.<br><br>&gt; Yeah, l=
ike that will happen...:P. I rant - live with it.<br>&gt; <br>&gt; Paddy<br=
>&gt; <br>&gt; <br>&gt;&nbsp; <br>&gt; P draic Brady<br>&gt; <br><span>&gt;=
 <a target=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blog.ast=
rumfutura.com</a></span><br><span>&gt; <a target=3D"_blank" href=3D"http://=
www.survivethedeepend.com">http://www.survivethedeepend.com</a></span><br>&=
gt; OpenID Europe Foundation Irish Representative<br>&gt; <br>&gt; <br>&gt;
 =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=
=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81<br>&gt; From: Nico Edtinger &lt;<a =
ymailto=3D"mailto:[email-masked]" href=3D"mailto:zf-contrib=
[email-masked]">[email-masked]</a>&gt;<br>&gt; To: P =
draic Brady &lt;<a ymailto=3D"mailto:[email-masked]" href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt;<br>&gt; Sent: Mo=
n, December 7, 2009 4:10:04 PM<br>&gt; Subject: Re: [zf-contributors] XSS A=
nd Malformed HTML Vulnerabilities In<br>&gt; Zend_Filter_StripTags<br>&gt; =
<br>&gt; Am 07.12.2009 um 15:26 schrieb P draic Brady:<br>&gt; <br>&gt;&nbs=
p; &nbsp;  I would also suggest the following:<br>&gt; <br>&gt;&nbsp; &nbsp=
;  a) Rework the filter's current four lines of documentation (http://<br>&=
gt;&nbsp; &nbsp;  <a
 target=3D"_blank" href=3D"http://framework.zend.com/manual/en/zend.filter.=
set.html#zend.filter.set.striptags">framework.zend.com/manual/en/zend.filte=
r.set.html#zend.filter.set.striptags</a><br>&gt;&nbsp; &nbsp;  ) to cover t=
he component in greater detail clarifying its use cases,<br>&gt;&nbsp; &nbs=
p;  potential for misuse, and clarifying it is not XSS&nbsp; or malformed H=
TML safe.<br>&gt;&nbsp; &nbsp;  b) Immediately deprecate in 1.9 branch (and=
 remove in 2.0 - preferably 1.10<br>&gt;&nbsp; &nbsp;  given its significan=
ce) its ability to flexibly allow some HTML/comments<br>&gt;&nbsp; &nbsp;  =
thus preserving its only truly worthwhile feature - stripping ALL HTML.<br>=
&gt;&nbsp; &nbsp;  c) Do this ASAP.<br>&gt; <br>&gt; <br>&gt; I'm missing t=
he most important thing: write a unit test with known attack<br>&gt; vector=
s. If I'd want an improvement as important as security I'd write a unit<br>=
&gt; test to prove that it works (or fails). Putting the burden on
 someone else by<br>&gt; hiding testable examples in a blog post or email l=
eaves a bad aftertaste.<br>&gt; <br>&gt; nico<br><br>-- <br>Matthew Weier O=
'Phinney<br>Project Lead&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a ymai=
lto=3D"mailto:[email-masked]" href=3D"mailto:[email-masked]">matthew@ze=
nd.com</a><br><span>Zend Framework&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a t=
arget=3D"_blank" href=3D"http://framework.zend.com/">http://framework.zend.=
com/</a></span><br></div></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compress=
ed/chunked Mon Dec  7 03:29:14 PST 2009 -->=0A</div></body></html>
--0-1836312247-1260224639=:66702--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 23 Apr 2009 18:50:51 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code freeze lifted -- and new one scheduled

Greetings, all!

For all of those who have contributed so far to the 1.8 release, many
thanks and congratulations to each of you!

Code freeze is lifted (and has been since the beta release). Please, as
you patch issues, make sure you also patch to the 1.8 release branch. If
you need help with this or are unsure how to do it, grab somebody on the
#zftalk.dev IRC channel on Freenode.net.

We'd like you to address only critical issues until the release; please
use your best judgment in this regard.

Code freeze for the final release starts Monday at 14:00 UTC, and I will
send another email to the list at that time to remind everyone.

If you discover a critical issue after that, or have one reported,
please send an email to this list describing the issue and the severity
so we can determine if a fix needs to be in the final release or can
wait until 1.8.1.

Again, thanks for all the effort to date!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Carlton Gibson <[email-masked]>
Date: Mon, 21 Dec 2009 12:23:08 +0000
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Status of ZF-6654 - Can/Should I take this on? 

Sorry, cancel that. The issue was resolved in trunk on Thursday.

(Still can't read the issue tracker... :-)

On 21 Dec 2009, at 12:17, Carlton Gibson wrote:

> See: http://framework.zend.com/issues/browse/ZF-6654
>=20
> Hi all,=20
>=20
> I've got a problem with chained routes not matching wildcards.
>=20
> This kind of thing doesn't work:=20
>=20
> $userRoute =3D new
> =
Zend_Controller_Router_Route_Hostname(':nickname..'.$configuration->genera=
l->domain,
>                    array('controller'=3D>'profile', =
'action'=3D>'view'));
>=20
> $userActionsRoute =3D=20
> new
>  Zend_Controller_Router_Route(':action/*',
> 					array('action'=3D>'view'));
> $router->addRoute('uActionsRoute', =
$userRoute->chain($userActionsRoute));
>=20
> ZF-6654 was opened for 1.8.1 but doesn't look as if it's received any =
attention.=20
>=20
> There's a proposed fix but no test case.=20
>=20
> I don't want to step on anyone's toes (the case is assigned to Ben =
Schlozen) but if it's not being worked on, should I clear it up?=20
>=20
> Regards,
> Carlton

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 13:11:15 -0700
From: Tommy Smith <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Bug Hunt Days this week

--000feaeec65376be17047896ba00
Content-Type: text/plain; charset=ISO-8859-1

Matthew, I haven't sent in my CLA yet - have it here ready to scan in. I
read it takes a few days to get done. Can I still do the Bug Hunt stuff?

Thanks,
Tommy Smith
smithprousa.com

On Tue, Nov 17, 2009 at 12:34 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> Just a reminder to everyone -- November's Bug Hunt Days are this week on
> Thursday and Friday. Please help out as you can -- log into #zftalk.dev
> on Freenode, or triage issues via this mailing list. Let's close *200*
> bugs this month! :)
>
> Thanks in advance for all the help -- and for all the assistance each of
> you provides each day!
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--000feaeec65376be17047896ba00
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Matthew, I haven&#39;t sent in my CLA yet - have it here ready to scan=
 in. I read it takes a few days to get done. Can I still do the Bug Hunt st=
uff?</div>
<div>=A0</div>
<div>Thanks,</div>
<div>Tommy Smith</div>
<div><a href=3D"http://smithprousa.com">smithprousa.com</a><br><br></div>
<div class=3D"gmail_quote">On Tue, Nov 17, 2009 at 12:34 PM, Matthew Weier =
O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">mat=
[email-masked]</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">Just a reminder to everyone -- N=
ovember&#39;s Bug Hunt Days are this week on<br>Thursday and Friday. Please=
 help out as you can -- log into #zftalk.dev<br>
on Freenode, or triage issues via this mailing list. Let&#39;s close *200*<=
br>bugs this month! :)<br><br>Thanks in advance for all the help -- and for=
 all the assistance each of<br>you provides each day!<br><font color=3D"#88=
8888"><br>
--<br>Matthew Weier O&#39;Phinney<br>Project Lead =A0 =A0 =A0 =A0 =A0 =A0| =
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>Zend Framework =
=A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" target=3D"_blan=
k">http://framework.zend.com/</a><br>
</font></blockquote></div><br>

--000feaeec65376be17047896ba00--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 22 Sep 2009 09:22:24 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code freeze lifted

Code freeze is lifted; please feel free to merge bugfixes and updates to
the 1.9 release branch.

Thanks, everyone!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 13:50:35 -0400
From: "A.J. Brown" <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

--00151747546e89f2600481eea296
Content-Type: text/plain; charset=ISO-8859-1

Another vote for more verbose class names.  The advantages far outweight the
disadvantages (typing more). It also seperates namespacing from class naming
entirely. For example, if you were writing a class to validate data specific
to a service API, it might make more since for that validator to live within
the namespace of those service classes, and not the global namespace:

 \Zend\Validate\FoobarUsername();

vs

\Zend\Service\Foobar\UsernameValidator();

There probably wouldn't be enough classes to justify the extra maintenance
of:

\Zend\Service\Foobar\Validate\Username();

On Tue, Mar 16, 2010 at 7:57 AM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> -- Ralph Schindler <[email-masked]> wrote
> (on Tuesday, 16 March 2010, 01:31 AM -0500):
> > On the Usage of Compound Names --
>
> (My commentary below...)
>
> > With namespaces, we have the opportunity to create aliases to
> > specific namespace our code consumes.  For example, we can do
> > something like this:
> >
> >
> > <?php
> > // in a script that consumes Zend Frameowrk
> > use Zend\Filter as f;
> >
> > $filter = new f\Something.php
> >
> > ?>
> >
> >
> > In the past, with fully prefixed names, it was easy to understand
> > the context of a particular class since the namespace is carried
> > with it. $filter = new Zend_Filter_Int(); is clearly an Integer
> > filter, and the class name fully reflects that.
> >
> > The question with namespaces is, should we use compound names to
> > identify classes separate of the namespace itself.  This can be
> > better demonstrated with the following code:
> >
> >
> > <?php
> >
> > use Zend\Filter as f;
> >
> > $filter = new f\Int();
> >
> > ?>
> >
> >
> > -- VS --
> >
> >
> > <?php
> >
> > use Zend\Filter as f;
> >
> > $filter = new f\IntFilter();
> >
> > ?>
>
> Honestly, choosing "f" as an alias just seems like a bad idea from the
> outset -- does it refer to "filter", or "form", or "file"? If you go
> with a more explicit alias:
>
>    use Zend\Filter;
>
>    $filter = new Filter\Int;
>
> the intent is already there.
>
> I can see your point being more present if you import a single class
> from a namespace:
>
>    use Zend\Filter\Int;
>    $filter = new Int();
>
> *This* example more properly shows the issues, to my thinking. But even
> then, better aliasing solves the problem:
>
>    use Zend\Filter\Int as IntFilter;
>    $filter = new IntFilter;
>
> This requires no changes to naming whatsoever, yet still solves the
> problems you describe -- but instead of doing it at the library level,
> it's at the end-user level.
>
> Yes, there will be a few places where we need to re-think names, such as
> Zend\CodeGenerator and Zend\Reflection, but I think in the bulk of
> instances, it shouldn't be a problem.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

-- 
A.J. Brown
Software Engineer, ZCE
blog : http://ajbrown.org
talk  : (937) 540-0099
chat : IntypicaAJ

--00151747546e89f2600481eea296
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Another vote for more verbose class names.=A0 The advantages far outweight =
the disadvantages (typing more). It also seperates namespacing from class n=
aming entirely. For example, if you were writing a class to validate data s=
pecific to a service API, it might make more since for that validator to li=
ve within the namespace of those service classes, and not the global namesp=
ace:<br>
<br>=A0\Zend\Validate\FoobarUsername();<br><br>vs <br><br>\Zend\Service\Foo=
bar\UsernameValidator();<br><br><br>There probably wouldn&#39;t be enough c=
lasses to justify the extra maintenance of:<br><br>\Zend\Service\Foobar\Val=
idate\Username();<br>
<br><br><div class=3D"gmail_quote">On Tue, Mar 16, 2010 at 7:57 AM, Matthew=
 Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
om">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">
-- Ralph Schindler &lt;<a href=3D"mailto:[email-masked]">ralph.sc=
[email-masked]</a>&gt; wrote<br>
(on Tuesday, 16 March 2010, 01:31 AM -0500):<br>
<div class=3D"im">&gt; On the Usage of Compound Names --<br>
<br>
</div>(My commentary below...)<br>
<div class=3D"im"><br>
&gt; With namespaces, we have the opportunity to create aliases to<br>
&gt; specific namespace our code consumes. =A0For example, we can do<br>
&gt; something like this:<br>
&gt;<br>
&gt;<br>
&gt; &lt;?php<br>
&gt; // in a script that consumes Zend Frameowrk<br>
&gt; use Zend\Filter as f;<br>
&gt;<br>
&gt; $filter =3D new f\Something.php<br>
&gt;<br>
&gt; ?&gt;<br>
&gt;<br>
&gt;<br>
&gt; In the past, with fully prefixed names, it was easy to understand<br>
&gt; the context of a particular class since the namespace is carried<br>
&gt; with it. $filter =3D new Zend_Filter_Int(); is clearly an Integer<br>
&gt; filter, and the class name fully reflects that.<br>
&gt;<br>
&gt; The question with namespaces is, should we use compound names to<br>
&gt; identify classes separate of the namespace itself. =A0This can be<br>
&gt; better demonstrated with the following code:<br>
&gt;<br>
&gt;<br>
&gt; &lt;?php<br>
&gt;<br>
&gt; use Zend\Filter as f;<br>
&gt;<br>
&gt; $filter =3D new f\Int();<br>
&gt;<br>
&gt; ?&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- VS --<br>
&gt;<br>
&gt;<br>
&gt; &lt;?php<br>
&gt;<br>
&gt; use Zend\Filter as f;<br>
&gt;<br>
&gt; $filter =3D new f\IntFilter();<br>
&gt;<br>
&gt; ?&gt;<br>
<br>
</div>Honestly, choosing &quot;f&quot; as an alias just seems like a bad id=
ea from the<br>
outset -- does it refer to &quot;filter&quot;, or &quot;form&quot;, or &quo=
t;file&quot;? If you go<br>
with a more explicit alias:<br>
<br>
 =A0 =A0use Zend\Filter;<br>
<br>
 =A0 =A0$filter =3D new Filter\Int;<br>
<br>
the intent is already there.<br>
<br>
I can see your point being more present if you import a single class<br>
from a namespace:<br>
<br>
 =A0 =A0use Zend\Filter\Int;<br>
 =A0 =A0$filter =3D new Int();<br>
<br>
*This* example more properly shows the issues, to my thinking. But even<br>
then, better aliasing solves the problem:<br>
<br>
 =A0 =A0use Zend\Filter\Int as IntFilter;<br>
 =A0 =A0$filter =3D new IntFilter;<br>
<br>
This requires no changes to naming whatsoever, yet still solves the<br>
problems you describe -- but instead of doing it at the library level,<br>
it&#39;s at the end-user level.<br>
<br>
Yes, there will be a few places where we need to re-think names, such as<br=
Zend\CodeGenerator and Zend\Reflection, but I think in the bulk of<br>
instances, it shouldn&#39;t be a problem.<br>
<div><div></div><div class=3D"h5"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>A.J. Brown<=
br>Software Engineer, ZCE<br>blog : <a href=3D"http://ajbrown.org">http://a=
jbrown.org</a><br>talk =A0: (937) 540-0099<br>chat : IntypicaAJ<br>

--00151747546e89f2600481eea296--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
Date: Tue, 16 Mar 2010 20:34:01 +0000
From: ptdorf <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

agree

2010/3/16 Giorgio Sironi <[email-masked]>:
> On Tue, Mar 16, 2010 at 7:25 AM, Ralph Schindler
> <[email-masked]> wrote:
>> But more importantly, it follows the adjective-noun naming. =A0For examp=
le:
>> Zend\Filter\AbstractFilter or Zend\Controller\AbstractController.
>>
>> Why force "ControllerAbstract" when "AbstractController" is more natural=
 =A0in
>> English speech? =A0Think about the two sentences (I know being an englis=
h
>> speaker is not a weighted argument, but all of the code written in ZF is=
 in
>> english anyway):
>
> Imho Abstract as a prefix is more readable. I guess it was a suffix
> originally because of the logical location of the file:
> Zend_View_Abstract goes in Zend/View folder. Instead of contrapting it
> to ViewAbstract, a meaningful name can be Zend\View\AbstractView.
>
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 13 Apr 2009 15:19:14 -0700
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming 
	Conventions

--001485f7786cc890240467771ae6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

That's fine, and I agree with the reasoning (standardization).  There are
still a couple of issues to resolve:

- I think Zend Framework should standardize on underscores or no underscores
in namespaces.
- Arrangement of abstract classes and interfaces: nested or not?  For
example, zend\controller\request and zend\controller\request\Http, or
zend\controller\request\RequestAbstract (or whatever) and
zend\controller\request\Http?
- PEAR standards also stipulate capitalized abbreviations in mixed-case
class names, e.g., zend\controller\request\HTTP.  Do we adhere to that as
well?  $httpRequest = new request\HTTP()?

-Matt

On Mon, Apr 13, 2009 at 5:49 AM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> I'm going to break a couple of rules here: I'm replying to my own email,
> as well as top-posting. Bear with me...
>
> Robin S. raised an interesting point that Matt R. picked up and agreed
> with:
>
>    I also notice that namespaces are written in Uppercase\Notation --
>    Zend\Controller\Request. Will this be the standard? Another
>    alternative is zend\controller\Request, which clearly distinguishes
>    what's the namespace and what's the class/interface.
>
> Additionally, it seems the primary push-back is with abstract class
> naming, particularly when there are also interfaces defined in the same
> namespace.
>
> After reading these responses, I reached out to some friends in the PEAR
> community, some of whom I've spoken with before about these issues. "Why
> PEAR?" some may ask. ZF standards are based on PEAR standards. One goal
> since the beginning of the ZF project has been to promote
> interoperability with established standards. PEAR CS are the "gold
> standard" in the PHP community, and whether you like or agree with them
> or not, they are used widely.
>
> The PEAR Group has been debating new standards to adopt for PEAR2 for
> some time now. PEAR2 is targeting a minimum required version of PHP 5.3,
> so they are addressing the very same issues we're discussing. They have
> also basically reached consensus, though they have not formally adopted
> the new standards yet. When it comes to namespaces and class naming, it
> is the ZF team's opinion that we need to be as close to PEAR standards
> as possible.
>
> The relevant documents are here:
>
>    http://wiki.php.net/pear/rfc/pear2_class_naming
>    http://wiki.php.net/pear/rfc/pear2_naming_standards
>
> In a nutshell, here's what they define:
>
>  * Namespaces are lowercase: zend\codegenerator\php
>  * Class names are MixedCase: zend\codegenerator\php\File
>  * Namespaces may contain underscores, but they do not translate to the
>   directory separator
>  * Class names may contain underscores, and they *do* translate to the
>   directory separator
>  * Interfaces should be named descriptively, and not contain the word
>   "Interface" or the sigil "I".
>  * It is preferred that Abstract classes are also named descriptively,
>   but *may* contain the *suffix* Abstract.
>
> There are some good arguments for each point in the linked RFCs.
>
> I think that adopting these standards addresses most concerns the ZF
> team has, as well as many if not most concerns posted in this thread.
>
> -- Matthew Weier O'Phinney <[email-masked]> wrote
> (on Friday, 10 April 2009, 02:24 PM -0400):
> > Greetings, all --
> >
> > Below is a proposal I am making to modify the Zend Framework Coding
> > Standards conventions for the naming of Interfaces and Abstract classes.
> >
> > This decision is basically already made, but I'd appreciate any feedback
> > that you may have on the matter.
> >
> > Thanks!
> >
> > The problem
> > ===========
> > PHP 5.3 introduces namespaces to the PHP language. While this won't have
> an
> > impact much on userland code, it will have an impact on library and
> framework
> > code, as it provides a useful paradigm for organizing components as well
> as
> > simplifying syntax. Instead of having to say things like:
> >
> >     $analyzer = new
> Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> >
> > we can instead do something like this:
> >
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >     $analyzer = new Common_TextNum();
> >
> > or even:
> >
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >     class Common_TextNum extends Common
> >     {
> >     }
> >
> > The problem that arises for Zend Framework has to do with how we name
> abstract
> > classes and interfaces. Currently, the final segment of such classes are
> > expected to end with _Abstract and _Interface, respectively. This will
> not work
> > when we migrate to utilize namespaces, for two reasons.
> >
> > First, and most obviously, 'abstract' and 'interface' are reserved PHP
> keywords.
> > As such, in situations such as the following:
> >
> >     namespace Zend\Controller\Request;
> >
> >     class Abstract
> >     {
> >     }
> >
> >     // or:
> >
> >     namespace Zend\Controller\Dispatcher;
> >
> >     interface Interface
> >     {
> >     }
> >
> > we'll run into issues.
> >
> > Second, and less obvious, is that perhaps the easiest solution breaks one
> of the
> > key principles of namespaces (which are designed to help encapsulate
> > components). This one's harder to explain, so let's look at examples.
> Consider a
> > component such as Zend_Controller_Request. The simplest solution would be
> to
> > name the abstract class or interface Zend\Controller\Request, and then
> have the
> > various concrete implementations under that namespace:
> >
> >     namespace Zend\Controller;
> >
> >     interface Request
> >     {
> >     }
> >
> >     // and concrete ones:
> >
> >     namespace Zend\Controller\Request;
> >
> >     class Http
> >     {
> >     }
> >
> > What's the problem here? The interface is not in the same namespace as
> the
> > concrete implementations.
> >
> > Potential solutions and recommendation
> > ======================================
> > So, how should Zend Framework "solve" these issues? A number of proposals
> and
> > recommendations have been floated around, both within ZF circles and in
> the
> > greater PHP community.
> >
> > Considerations include:
> >
> >  * Avoiding the use of PHP reserved keywords (already noted).
> >  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
> name
> >    describe its type -- which, to a degree, the current naming
> conventions
> >    already violate). (See
> http://en.wikipedia.org/wiki/Hungarian_Notation, the
> >    sections "Disadvantages of Systems Hungarian" and "Notable Opinions"
> for some
> >    of the arguments against using Hungarian Notation.)
> >
> > Approaches that have been considered include:
> >
> >  * Using 'I' to prefix interfaces. This derives from standards in other
> >    programming languages (.Net and python, in particular). This is just
> another
> >    form of Hungarian Notation, however.
> >
> >  * Using "Interface" or "Abstract" as a class name suffix:
> RequestInterface,
> >    RequestAbstract. Again, however this is Hungarian Notation.
> >
> >  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
> Base.
> >    This is just substituting the word Base for Abstract, however, and is
> really
> >    not much different than the above.
> >
> >  * Use generic, descriptive names indicative of functionality or
> behavior. As
> >    examples from the SPL, "Countable", "Iterator", "ArrayObject".
> >
> > My recommendation is to use the latter, as it solves all considerations.
> It will
> > take more thought when naming, but will ensure that components can live
> in a
> > self-contained namespace, do not use reserved keywords, and avoid
> Hungarian
> > Notation.
> >
> > Plan for implementation
> > =======================
> > I recommend that the Coding Standards documentation be updated to reflect
> this
> > approach.
> >
> > All new components going into 1.8 and onwards should adopt these
> standards. In
> > releases 1.9 and forward, we will begin migrating existing
> interfaces/abstract
> > classe. First, new classes/interfaces will be created that follow these
> > conventions and which extend the originals; later, any type-hinting based
> on the
> > original class/interface names will be updated to point to the new names;
> and
> > finally, in 2.0, we will remove the old interfaces/abstract classes
> entirely.
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> >
>
> --
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--001485f7786cc890240467771ae6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That&#39;s fine, and I agree with the reasoning (standardization).=C2=A0 Th=
ere are still a couple of issues to resolve:<br><br>- I think Zend Framewor=
k should standardize on underscores or no underscores in namespaces.<br>- A=
rrangement of abstract classes and interfaces: nested or not?=C2=A0 For exa=
mple, zend\controller\request and zend\controller\request\Http, or zend\con=
troller\request\RequestAbstract (or whatever) and zend\controller\request\H=
ttp?<br>
- PEAR standards also stipulate capitalized abbreviations in mixed-case cla=
ss names, e.g., zend\controller\request\HTTP.=C2=A0 Do we adhere to that as=
 well?=C2=A0 $httpRequest =3D new request\HTTP()?<br><br>-Matt<br><br><div =
class=3D"gmail_quote">
On Mon, Apr 13, 2009 at 5:49 AM, Matthew Weier O&#39;Phinney <span dir=3D"l=
tr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px soli=
d rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;m going to break a couple of rules here: I&#39;m replying to my own e=
mail,<br>
as well as top-posting. Bear with me...<br>
<br>
Robin S. raised an interesting point that Matt R. picked up and agreed<br>
with:<br>
<div class=3D"im"><br>
 =C2=A0 =C2=A0I also notice that namespaces are written in Uppercase\Notati=
on --<br>
 =C2=A0 =C2=A0Zend\Controller\Request. Will this be the standard? Another<b=
r>
 =C2=A0 =C2=A0alternative is zend\controller\Request, which clearly disting=
uishes<br>
 =C2=A0 =C2=A0what&#39;s the namespace and what&#39;s the class/interface.<=
br>
<br>
</div>Additionally, it seems the primary push-back is with abstract class<b=
r>
naming, particularly when there are also interfaces defined in the same<br>
namespace.<br>
<br>
After reading these responses, I reached out to some friends in the PEAR<br=
community, some of whom I&#39;ve spoken with before about these issues. &qu=
ot;Why<br>
PEAR?&quot; some may ask. ZF standards are based on PEAR standards. One goa=
l<br>
since the beginning of the ZF project has been to promote<br>
interoperability with established standards. PEAR CS are the &quot;gold<br>
standard&quot; in the PHP community, and whether you like or agree with the=
m<br>
or not, they are used widely.<br>
<br>
The PEAR Group has been debating new standards to adopt for PEAR2 for<br>
some time now. PEAR2 is targeting a minimum required version of PHP 5.3,<br=
so they are addressing the very same issues we&#39;re discussing. They have=
<br>
also basically reached consensus, though they have not formally adopted<br>
the new standards yet. When it comes to namespaces and class naming, it<br>
is the ZF team&#39;s opinion that we need to be as close to PEAR standards<=
br>
as possible.<br>
<br>
The relevant documents are here:<br>
<br>
 =C2=A0 =C2=A0<a href=3D"http://wiki.php.net/pear/rfc/pear2_class_naming" t=
arget=3D"_blank">http://wiki.php.net/pear/rfc/pear2_class_naming</a><br>
 =C2=A0 =C2=A0<a href=3D"http://wiki.php.net/pear/rfc/pear2_naming_standard=
s" target=3D"_blank">http://wiki.php.net/pear/rfc/pear2_naming_standards</a=
><br>
<br>
In a nutshell, here&#39;s what they define:<br>
<br>
=C2=A0* Namespaces are lowercase: zend\codegenerator\php<br>
=C2=A0* Class names are MixedCase: zend\codegenerator\php\File<br>
=C2=A0* Namespaces may contain underscores, but they do not translate to th=
e<br>
 =C2=A0 directory separator<br>
=C2=A0* Class names may contain underscores, and they *do* translate to the=
<br>
 =C2=A0 directory separator<br>
=C2=A0* Interfaces should be named descriptively, and not contain the word<=
br>
 =C2=A0 &quot;Interface&quot; or the sigil &quot;I&quot;.<br>
=C2=A0* It is preferred that Abstract classes are also named descriptively,=
<br>
 =C2=A0 but *may* contain the *suffix* Abstract.<br>
<br>
There are some good arguments for each point in the linked RFCs.<br>
<br>
I think that adopting these standards addresses most concerns the ZF<br>
team has, as well as many if not most concerns posted in this thread.<br>
<font color=3D"#888888"><br>
-- Matthew Weier O&#39;Phinney &lt;<a href=3D"mailto:[email-masked]">matt=
[email-masked]</a>&gt; wrote<br>
(on Friday, 10 April 2009, 02:24 PM -0400):<br>
</font><div><div></div><div class=3D"h5">&gt; Greetings, all --<br>
&gt;<br>
&gt; Below is a proposal I am making to modify the Zend Framework Coding<br=
&gt; Standards conventions for the naming of Interfaces and Abstract classe=
s.<br>
&gt;<br>
&gt; This decision is basically already made, but I&#39;d appreciate any fe=
edback<br>
&gt; that you may have on the matter.<br>
&gt;<br>
&gt; Thanks!<br>
&gt;<br>
&gt; The problem<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; PHP 5.3 introduces namespaces to the PHP language. While this won&#39;=
t have an<br>
&gt; impact much on userland code, it will have an impact on library and fr=
amework<br>
&gt; code, as it provides a useful paradigm for organizing components as we=
ll as<br>
&gt; simplifying syntax. Instead of having to say things like:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 $analyzer =3D new Zend_Search_Lucene_Analysis_Analyzer_C=
ommon_TextNum();<br>
&gt;<br>
&gt; we can instead do something like this:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 namespace Zend\Search\Lucene\Analysis\Analyzer;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 $analyzer =3D new Common_TextNum();<br>
&gt;<br>
&gt; or even:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 namespace Zend\Search\Lucene\Analysis\Analyzer;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 class Common_TextNum extends Common<br>
&gt; =C2=A0 =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; The problem that arises for Zend Framework has to do with how we name =
abstract<br>
&gt; classes and interfaces. Currently, the final segment of such classes a=
re<br>
&gt; expected to end with _Abstract and _Interface, respectively. This will=
 not work<br>
&gt; when we migrate to utilize namespaces, for two reasons.<br>
&gt;<br>
&gt; First, and most obviously, &#39;abstract&#39; and &#39;interface&#39; =
are reserved PHP keywords.<br>
&gt; As such, in situations such as the following:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 namespace Zend\Controller\Request;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 class Abstract<br>
&gt; =C2=A0 =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 // or:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 namespace Zend\Controller\Dispatcher;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 interface Interface<br>
&gt; =C2=A0 =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; we&#39;ll run into issues.<br>
&gt;<br>
&gt; Second, and less obvious, is that perhaps the easiest solution breaks =
one of the<br>
&gt; key principles of namespaces (which are designed to help encapsulate<b=
r>
&gt; components). This one&#39;s harder to explain, so let&#39;s look at ex=
amples. Consider a<br>
&gt; component such as Zend_Controller_Request. The simplest solution would=
 be to<br>
&gt; name the abstract class or interface Zend\Controller\Request, and then=
 have the<br>
&gt; various concrete implementations under that namespace:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 namespace Zend\Controller;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 interface Request<br>
&gt; =C2=A0 =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 // and concrete ones:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 namespace Zend\Controller\Request;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 class Http<br>
&gt; =C2=A0 =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; What&#39;s the problem here? The interface is not in the same namespac=
e as the<br>
&gt; concrete implementations.<br>
&gt;<br>
&gt; Potential solutions and recommendation<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; So, how should Zend Framework &quot;solve&quot; these issues? A number=
 of proposals and<br>
&gt; recommendations have been floated around, both within ZF circles and i=
n the<br>
&gt; greater PHP community.<br>
&gt;<br>
&gt; Considerations include:<br>
&gt;<br>
&gt; =C2=A0* Avoiding the use of PHP reserved keywords (already noted).<br>
&gt; =C2=A0* Avoiding Hungarian Notation (i.e., having the name or a portio=
n of the name<br>
&gt; =C2=A0 =C2=A0describe its type -- which, to a degree, the current nami=
ng conventions<br>
&gt; =C2=A0 =C2=A0already violate). (See <a href=3D"http://en.wikipedia.org=
/wiki/Hungarian_Notation" target=3D"_blank">http://en.wikipedia.org/wiki/Hu=
ngarian_Notation</a>, the<br>
&gt; =C2=A0 =C2=A0sections &quot;Disadvantages of Systems Hungarian&quot; a=
nd &quot;Notable Opinions&quot; for some<br>
&gt; =C2=A0 =C2=A0of the arguments against using Hungarian Notation.)<br>
&gt;<br>
&gt; Approaches that have been considered include:<br>
&gt;<br>
&gt; =C2=A0* Using &#39;I&#39; to prefix interfaces. This derives from stan=
dards in other<br>
&gt; =C2=A0 =C2=A0programming languages (.Net and python, in particular). T=
his is just another<br>
&gt; =C2=A0 =C2=A0form of Hungarian Notation, however.<br>
&gt;<br>
&gt; =C2=A0* Using &quot;Interface&quot; or &quot;Abstract&quot; as a class=
 name suffix: RequestInterface,<br>
&gt; =C2=A0 =C2=A0RequestAbstract. Again, however this is Hungarian Notatio=
n.<br>
&gt;<br>
&gt; =C2=A0* Using the term &quot;Base&quot; for abstract classes: BaseRequ=
est, RequestBase, Base.<br>
&gt; =C2=A0 =C2=A0This is just substituting the word Base for Abstract, how=
ever, and is really<br>
&gt; =C2=A0 =C2=A0not much different than the above.<br>
&gt;<br>
&gt; =C2=A0* Use generic, descriptive names indicative of functionality or =
behavior. As<br>
&gt; =C2=A0 =C2=A0examples from the SPL, &quot;Countable&quot;, &quot;Itera=
tor&quot;, &quot;ArrayObject&quot;.<br>
&gt;<br>
&gt; My recommendation is to use the latter, as it solves all consideration=
s. It will<br>
&gt; take more thought when naming, but will ensure that components can liv=
e in a<br>
&gt; self-contained namespace, do not use reserved keywords, and avoid Hung=
arian<br>
&gt; Notation.<br>
&gt;<br>
&gt; Plan for implementation<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
br>
&gt; I recommend that the Coding Standards documentation be updated to refl=
ect this<br>
&gt; approach.<br>
&gt;<br>
&gt; All new components going into 1.8 and onwards should adopt these stand=
ards. In<br>
&gt; releases 1.9 and forward, we will begin migrating existing interfaces/=
abstract<br>
&gt; classe. First, new classes/interfaces will be created that follow thes=
e<br>
&gt; conventions and which extend the originals; later, any type-hinting ba=
sed on the<br>
&gt; original class/interface names will be updated to point to the new nam=
es; and<br>
&gt; finally, in 2.0, we will remove the old interfaces/abstract classes en=
tirely.<br>
&gt;<br>
&gt; --<br>
&gt; Matthew Weier O&#39;Phinney<br>
&gt; Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:matthew@zen=
d.com">[email-masked]</a><br>
&gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://f=
ramework.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt;<br>
<br>
--<br>
Matthew Weier O&#39;Phinney<br>
Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:[email-masked]=
">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
</div></div></blockquote></div><br>

--001485f7786cc890240467771ae6--

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 14:26:35 -0500
From: Ralph Schindler <[email-masked]>
To: Stanislav Malyshev <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

Response inline..

>> <?php
>> // this class has a use statement
>>
>> namespace Foo;
>> use Qux\Garply as garp;
>>
>> class Bar
>> {
>> // this method accepts an instance of Qux\Garply\Bar
>> public static function baz(garp\Bar $bar) {}
>> }
> 
> And this one too, though you could "use" whole Qux\Garply\Bar as QGBar 
> as well :)

This is actually pretty close to my point.

It's clear to people consuming Zend Framework classes that Bar inside 
the method signature means Foo\Bar.  The question comes in when people 
are consuming a class that has outside dependencies (like the example 
above).

How is a developer suppose to know what the QGBar alias is short for? 
Moreover, if we are to use alias in method signatures, what kind of 
naming convention should be in play?

Additionally, do we restrict it to importing full namespaces? Or would 
we allow importing of single classes?  Do we allow importing an aliased 
class into a File and use that inside a method signature?

Imagine this:

<?php
namespace Zend\Some\NS;
use \ArrayObject as Container;

class Foo
{
    public function doSomething(Container $c);
}
?>

This is totally possible, and you could argue that its a superb use of 
namespaces.  Some might argue that it borders on runkit functionality 
(the ability to alias names bit). How is a developer suppose to know 
simply by looking at the method signature that he just needs to supply 
an ArrayObject?

Do we simply rely on tools to tell us what Container really means?

I totally agree with using "namespace resolved names" for method 
signatures, but I am skeptical on whether using "use resolved names" is 
going to produce easy to use APIs.

>> One thing to notice is that if method signatures contain a fully
>> qualified name (those starting with a \) for type hints, you don't need
>> to know anything about what namespaces or aliases are in play;
>> everything you need to know is right in front of you. However, on the
> 
> I have faith that Framework developers actually can remember inside 
> which class and namespace they are :)

By "Framework developers" do you mean people writing ZF code? or people 
consuming ZF code?  I actually don't care about the burden put on people 
writing code for ZF, b/c you only need to write it once.  It's the 
burden put on the consumers of the ZF library of code that I feel is 
more important.

>> Should library/framework specific code be more expressive using fully
>> qualified names in method signatures and consequently in docblocks? Or
>> is using unqualified names just as easy to understand and/or more 
>> readable?
> 
> Docblocks present interesting challenge, if they are used for typing 
> purposes. I guess there some solution might be needed, but maybe smart 
> tools can solve it...

I am guessing that docblock class names should probably be using the 
same namespace and use rule resolution that classes use.

-ralph

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 11 Nov 2009 13:38:57 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Zend Framework 2.0 Roadmap

Hey, all --

There have been a ton of questions about the ZF 2.0 roadmap, and my
answer has been consistently, "I'm working on it; I'll have something to
publish soon."

"Soon" is now:

    http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap

I'd like you, as contributors, to look over it, and start discussing the
various ramifications; we can do that either in comments to the pages or
on this list.

The roadmap is primarily a conceptual one right now, though a
proof-of-concept has been created for the proposed MVC. I'd like to stay
fairly high-level for now, and then start getting a flow of proposals
into the system for specific migration-related tasks.

Thanks everyone who has provided me input over the past many months, and
let's get started on the next generation of ZF!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:10 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Fri, 26 Feb 2010 00:20:26 +0100
To: Graham Anderson <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

I guess I'll have to confess I've been convinced ZF should use GIT,
not only because other major projects like Zym use it (:wink:), but
also because it seems to bring quite a lot of advantages, while hardly
bringing any disadvantages.

The cons (from the wiki):
> Tracking CLAs becomes more difficult. Currently with SVN, we only grant a=
ccess to those who have signed a CLA; if anybody can fork, we now need some=
 way to verify CLA status before pulling patches.
After all there's always someone who's committing to the 'main'
(master?) repository. You can always track who makes those 'main'
commits? The person committing to the main repos should then keep
track of
everybody contributing to a certain commit has signed a CLA (as is
done now when a patch is applied). There should however be a clear and
uptodate list of everybody who signed a CLA (that's more than a
selectbox in jira...).

> No good svn:externals equivalent
We could just commit a checkout of Dojo (and possibly Dcotrine) into
the ZF repository, making it read-only by anybody who's not a release
manager. For people who use svn for their own projects, there should
be an svn mirror for people to use for their svn:externals. If Zend
can't provide such mirror I (my company) would be happy to do so.

> Tooling across platforms is not as mature or robust
Who needs anything else than /usr/bin/git? Obviously should the
Atlassian tools should support git as well, but I guess they do these
days.

> Would potentially require (re-)training contributors
I have never worked with git myself, but how difficult can the basics
be? git clone, git pull, git status, git add, git commit -a should be
things any contributor can understand (right?). Instead of actively
train them, I'd be a fan of putting a link to
http://git.or.cz/course/svn.html in the topic of #zftalk.dev on
freenode (and the wiki etc...).

--Freeaqingme

P.s. For all of those not following me, I indeed had a different
opinion on this a few days ago...

On Thu, Feb 25, 2010 at 11:53 PM, Graham Anderson
<[email-masked]> wrote:
> On Thursday 25 February 2010 21:48:57 Matthew Weier O'Phinney wrote:
>>The release master can
>>track multiple repos from multiple collaborators, and then selectively
>>merge into their own "master" -- and push those patches into the
>>mainline.
>
> For the benefit of those who don't currently use Git one other powerful a=
spect
> of this collaborative work-flow is being able to cherry pick commits.
>
> In this situation you may have multiple branches, some of them may or may=
 not
> track other developers remote branches. Rather than merge the whole branc=
h
> from HEAD to 6 commits previously, you see that only one of the commits h=
as
> the changeset you need. Git cherry-pick allows you to merge a single comm=
it.
>
> This, and being able to merge at will from multiple remote branches is th=
e
> kind of functionality I believe makes Git more suitable than SVN for what=
 we
> do.
>
> There's more, much more. One of the key differences between Git and SVN, =
and
> this is extremely important, is that Git tracks the _content_ of your fil=
es
> whereas SVN tracks the files themselves. Git really doesn't care that the=
re
> are 10 or 20 or 1,000 files, it only cares about the content and it only =
cares
> how the content changes.
>
> Here's an example, since Layout.php has been in the codebase for a while =
I
> wanted to see who was responsible for last editing it. So i looked at the
> source and decided to lookup the method setMvcSuccessfulActionOnly(). It'=
s on
> line number 483-487.
>
> =C2=A0 =C2=A0git blame -L 483,487 Layout.php
>
> I'll trim the output and ommit the actual code which is appended to the e=
nd of
> the following lines but you can see the detailed info that is available.
>
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +00=
00
> 483)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +00=
00
> 484)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +00=
00
> 485)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +00=
00
> 486)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +00=
00
> 487)
>
> So in less than a quarter of a second I can search the whole commit histo=
ry of
> the main ZF repo and see who was responsible for last editing any line of=
 any
> file. There's lots more gems like this that let you unleash the power of =
Git
> if you want to look below the surface.
>
> The surface is a good place to be as well, let me offer a common work-flo=
w
> situation with git using every day commands.
>
> git checkout -b foobar
> edit foo/bar.php
> ... hack hack hack ...
> *ring ring* oops emergency fix needed
> git stash
> git checkout master
> edit emergency/fix.php
> git commit -am "Commit fix!"
> git checkout foobar
> git stash pop
> ... hack hack hack ...
> git checkout master
> git merge foobar
> *glug glug glug* cold beers while your colleagues are still fighting SVN.
>
> The story above is: Create and move into feature branch "foobar". Start
> hacking on the feature. Boss calls, X is broken!, stash your changes and
> quickly switch to master(trunk). Fix broken things, commit them, switch b=
ack
> to foobar branch. Pop your changes from the stash into your working set,
> continue hacking. Switch to master(trunk) and merge your new feature Foob=
ar.
> Profit!
>
> --
> =E2=80=9CWhat can be asserted without proof can be dismissed without proo=
f.=E2=80=9D
> - Christopher Hitchens

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 23 Mar 2010 09:04:06 -0400
From: Court Ewing <[email-masked]>
To: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] use statements -- usage?

--0016364c78efdb8d8504827772a8
Content-Type: text/plain; charset=ISO-8859-1

Howdy,

I don't have very strong opinions on the matter, but I generally disagree
with what has already been said.  For one, I don't think it is out of line
to say that you use an entire package as opposed to using individual
components of a package.  I think automated packaging *should* focus on
packages; that's kind of how package managers work anyway.  When I download
something via pacman, I get entire packages and their dependent packages
therein.  Downloading only portions of a package will just lead to confusion
and frustration down the line, and there really isn't an existing precedent
for it, so I don't think we should be starting one.

Aliases should be used to solve ambiguity in class names.  You alias
Zend\Controller\Action\Helper as "ActionHelper" because "Helper" is not only
ambiguous but it could also easily conflict with other namespaces.  You
don't alias stuff just for the sake of aliasing.

Imaging this scenario:

You create a class that uses a lot of components of Zend\Acl, and now your
import block looks like this:

use Zend\Acl,
      Zend\Acl\Resource as AclResource,
      Zend\Acl\Role as AclRole,
      Zend\Acl\Role\Registry as AclRoleRegistry;

How is that any more helpful than simply using Zend\Acl and then calling
other classes in the package as Acl\Resource?  Acl is a pretty shallow
package too; this sort of naming convention could have far more
unnecessarily pedantic results for deeper packages.

Not to mention the fact that every time you alias you are dropping literal
namespaces (which can easily be documented) for arbitrarily named aliases
(which you can only enforce through naming convention standards... which are
not always followed).  I think the entire codebase will remain far more
consistent if we try to stick to existing naming schemes (in this case,
naming namespaces) rather than adding additional standards to the mix.

Court Ewing
http://epixa.com

On Tue, Mar 23, 2010 at 5:51 AM, Julien Pauli <[email-masked]>wrote:

> Agree to have strict rules to name namespaces with "use" key word, so
> that we can guess them easilly
>
> J.Pauli
>
> On Mon, Mar 22, 2010 at 11:06 PM, Giorgio Sironi
> <[email-masked]> wrote:
> > This problem does not happen to me very often, because usually are
> > more specific components in sub namespaces that. I'm for aliasing them
> > all with use statements, since it was decided they must have
> > meaningful names (such as use Zend\Filter\Int as IntFilter) which can
> > be understood without problems.
> >
> > --
> > Giorgio Sironi
> > Piccolo Principe & Web Engineer
> > http://giorgiosironi.blogspot.com
> > http://twitter.com/giorgiosironi
> >
>

--0016364c78efdb8d8504827772a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">Howdy,<br><br>I don&#39;t have very strong opini=
ons on the matter, but I=20
generally disagree with what has already been said.=A0 For one, I don&#39;t=
=20
think it is out of line to say that you use an entire package as opposed
 to using individual components of a package.=A0 I think automated=20
packaging <i>should</i> focus on packages; that&#39;s kind of how package=
=20
managers work anyway.=A0 When I download something via pacman, I get=20
entire packages and their dependent packages therein.=A0 Downloading only=
=20
portions of a package will just lead to confusion and frustration down=20
the line, and there really isn&#39;t an existing precedent for it, so I=20
don&#39;t think we should be starting one.<br>
<br>Aliases should be used to solve ambiguity in class names.=A0 You alias
 Zend\Controller\Action\Helper as &quot;ActionHelper&quot; because &quot;He=
lper&quot; is not
 only ambiguous but it could also easily conflict with other=20
namespaces.=A0 You don&#39;t alias stuff just for the sake of aliasing.<br>
<br>Imaging this scenario:<br><br>You create a class that uses a lot of=20
components of Zend\Acl, and now your import block looks like this:<br><br>u=
se
 Zend\Acl,<br>=A0=A0=A0=A0=A0 Zend\Acl\Resource as AclResource,<br>=A0=A0=
=A0=A0=A0=20
Zend\Acl\Role as AclRole,<br>
=A0=A0=A0=A0=A0 Zend\Acl\Role\Registry as AclRoleRegistry;<br><br>How is th=
at any=20
more helpful than simply using Zend\Acl and then calling other classes=20
in the package as Acl\Resource?=A0 Acl is a pretty shallow package too;=20
this sort of naming convention could have far more unnecessarily=20
pedantic results for deeper packages.<br>
<br>Not to mention the fact that every time you alias you are dropping=20
literal namespaces (which can easily be documented) for arbitrarily=20
named aliases (which you can only enforce through naming convention=20
standards... which are not always followed).=A0 I think the entire=20
codebase will remain far more consistent if we try to stick to existing=20
naming schemes (in this case, naming namespaces) rather than adding=20
additional standards to the mix.<br><font color=3D"#888888">
<br>Court Ewing<br><a href=3D"http://epixa.com/" target=3D"_blank">http://e=
pixa.com</a><br><br></font>On Tue, Mar 23, 2010 at 5:51 AM, Julien Pauli <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">doctorrock83@=
gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Agree to have str=
ict rules to name namespaces with &quot;use&quot; key word, so<br>
that we can guess them easilly<br>
<br>
J.Pauli<br>
<div><div></div><div class=3D"h5"><br>
On Mon, Mar 22, 2010 at 11:06 PM, Giorgio Sironi<br>
&lt;<a href=3D"mailto:[email-masked]">piccoloprincipeazzu=
[email-masked]</a>&gt; wrote:<br>
&gt; This problem does not happen to me very often, because usually are<br>
&gt; more specific components in sub namespaces that. I&#39;m for aliasing =
them<br>
&gt; all with use statements, since it was decided they must have<br>
&gt; meaningful names (such as use Zend\Filter\Int as IntFilter) which can<=
br>
&gt; be understood without problems.<br>
&gt;<br>
&gt; --<br>
&gt; Giorgio Sironi<br>
&gt; Piccolo Principe &amp; Web Engineer<br>
&gt; <a href=3D"http://giorgiosironi.blogspot.com" target=3D"_blank">http:/=
/giorgiosironi.blogspot.com</a><br>
&gt; <a href=3D"http://twitter.com/giorgiosironi" target=3D"_blank">http://=
twitter.com/giorgiosironi</a><br>
&gt;<br>
</div></div></blockquote></div><br>

--0016364c78efdb8d8504827772a8--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: Andy Thompson <[email-masked]>
Date: Mon, 15 Mar 2010 20:53:23 +0000
From: Andy Thompson <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

Hi,

I'm not keen on adjective or noun names, I can't even fathome names like 
Elementable or Helpable. It sounds even worse if needing to define 
multi-word interfaces, e.g ControllerPlugable

However the shortening of FoobarAbstract to FoobarBase seems to make 
sense. Perhaps something similar could be done to FoobarInterface, say 
FoobarSpec?

Regards

Andy

On 15/03/2010 19:58, Matthew Weier O'Phinney wrote:
> Hey, all --
>
> I know this has been hashed out a fair bit already, and we've already
> established some guidelines, but as I play with code for ZF2, I'm
> beginning to question the naming conventions for Interfaces and Abstract
> Classes.
>
> When we made the decisions before, we were looking at the following
> three options for interfaces:
>
>   1. Prefix interfaces with "I" ("IFoobar").
>   2. Suffix interfaces with "Interface" ("FoobarInterface")
>   3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> For abstract classes, we looked at:
>
>   4. Prefix abstract classes with "A" ("AFoobar")
>   5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>   6. Prefix abstract classes with "Base" ("BaseFoobar")
>   7. Suffix abstract classes with "Base" ("FoobarBase")
>   8. Use normal class names ("Foobar")
>
> Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
> they smack of Hungarian Notation, the long forms lead to really long
> names, etc. Prefixing can lead to similar classes not being grouped when
> doing directory listings (i.e., all abstract class or interface files
> get clustered together). Also, for classes beginning with "I" or "A",
> there can potentially be confusion over whether or not the given class
> is supposed to be concrete. Finally, during refactoring, if you choose
> to make an interface an abstract class or concrete class, or an abstract
> class an interface or concrete class, you can't do so without renaming
> files and classes. (That said, you'll most likely need to make other
> changes anyways -- and ZF will likely never make an interface an
> abstract class or vice versa.)
>
> Regarding 3 and 8, the primary problems are that it's often hard to come
> up with meaningful names that do not conflict with concrete
> implementations, and that for non-native English speakers, this latter
> problem becomes an even bigger obstacle. Additionally, you can't
> determine which files contain abstract classes and/or interfaces just by
> the filename -- you have to look in the file or look in API
> documentation to determine this information.
>
> Now, as to the issues I've seen: the word "Interface" becomes a real
> pain to type (yes, even with autocompletion), and it doesn't really
> connote any real information. When type-hinting, I simply know what type
> I want to use -- the name doesn't need to tell me it's an interface, as
> I already know that information. If I'm writing code that consumes or
> interacts with the class, API docs will tell me what I need to do.
>
> That said, I don't use Abstract classes that often, but considering they
> are a foundation on which to build concrete classes (presumably to take
> care of many of the nitty gritty details and leave the concrete classes
> to implement specifics), I don't mind using a class suffix. "Abstract"
> feels like Hungarian notation, though.
>
> Based on my experiences writing code, I'm currently recommending that we
> do the following:
>
>   3. Use adjective/noun names for Interfaces such as "Foobarable",
>      "Foobarist"
>   7. Suffix abstract classes with "Base" ("FoobarableBase")
>
> The above solve most issues - names are reasonably sized, don't smack of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
> most importantly, meaningful. Since we already implement code review for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.
>
> Thoughts? Votes?
>
>    

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 05:52:10 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Discussion about Quality/Review Process -
	Community RM proposal

--0-672021064-1253710330=:60339
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Benjamin,=0A=0ATo be honest, I'm not sure a Release Manager would solve =
the perceived problem. I'm not saying it's a bad idea, it probably is a goo=
d idea for a slightly different set of reasons. My main reservation is that=
 applying a specific responsibility (prevent backwards compatibility breaks=
) to the role of Release Manager would be next to impossible to effectively=
 implement without some drastic changes in how QA is applied to the source =
code. In fact, I'd go so far as to say discussing a Release Manager role is=
 missing the obvious target.=0A=0AConsider how QA works in Zend Framework. =
We have unit tests, documentation, the issue tracker, and with a little luc=
k a responsible committer and/or Lead Developer per component. I think the =
issue tracker works just fine - it desperately needs more community involve=
ment and that's why I'm overjoyed to take part in the Bug Hunts (and encour=
age, shame, blackmail others into taking part too ;)). The other three howe=
ver have issues of their own.=0A=0AThe unit tests vary in quality from ones=
 that are sharp, focused, and methodically assert against behaviour slice b=
y slice to those which are so mistargeted or aggregated as to be perfectly =
useless. The second set represent a significant risk. I've already run afou=
l of several without realising it, and that experience would teach anyone t=
he folly of relying on such low-quality unit tests for anything. This preve=
nts other improvements, not simply new features to these components, but an=
y form of refactoring out of fear a BC break will emerge and remain undetec=
ted. It also goes without saying that "backwards compatibility" has never b=
een defined for the Zend Framework. I gather from IRC that there is some de=
bate over whether it applies to protected methods (which is close to insane=
 in my opinion since then how could we ever refactor) or not. In an environ=
ment like this, any Release Manager is constantly being undermined and will=
 be forced to personally
 peer review the entire component end to end, make a judgement call, and op=
en themselves up to arguments from anyone effected.=0A=0AAs for responsibil=
ity, not all components have a responsible person. During the Bug Hunt I st=
arted assigning all Zend_Feed and Zend_OpenId issues to myself (short of of=
ficially taking over), and I know others have been doing the same. This sti=
ll leaves a lot of orphaned components whose issues are transferred to a de=
fault Zend member who probably won't touch them with a barge pole. Not that=
 I remotely blame whoever that may be - fixing issues on an unfamiliar comp=
onent can be a frustrating and time-consuming exercise (especially when its=
 unit tests suck). Over the bug hunt, I spent half a day on one component f=
ixing three issues simply because I needed time to familiarise myself with =
it, review the unit tests, read the source code, etc. That was not even orp=
haned, and its unit tests were passable. Unfortunately, orphaned components=
 are often either already completely broken or have been impacted by a poor=
ly judged patch that nobody has gotten around to
 fixing yet. Our web service components are notorious in this regard.=0A=0A=
Documentation is the least of the worries. Mostly it's accurate, but it doe=
s need a fuller review at some point, or a deliberate restart for Zend Fram=
ework 2.0. It's main problem is that it's written by developers (that will =
not change ;)) but also that it seems impervious to any form of iterative i=
mprovement. Once written, documentation rarely changes and any of its flaws=
 become permanent problems that will very rarely ever reach the issue track=
er.=0A=0AWhen you combine all three, any Release Manager is going to very q=
uickly realise they cannot effectively perform a role in preventing backwar=
ds compatibility breaks. Unit tests will not help, components are orphaned =
with no point of contact, and the documentation can suck so badly that read=
ing the source code is actually easier and faster. Then there is the matter=
 of who will fix them all. Multiply by dozens of components. It's not a job=
 one single individual should be landed with.=0A=0AIn my opinion, we should=
 first improve how QA is performed and then, with some luck, revisit how a =
Release Manager role could operate.=0A=0AOf course all of my meandering has=
 one simple problem - how to motivate the community to actively take part a=
nd contribute their time and skill. Without that, it would all be doomed to=
 failure anyway.=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0A=
http://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Represent=
ative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Benjamin Eb=
erlei <[email-masked]>=0ATo: [email-masked]=0ASent: We=
dnesday, September 23, 2009 8:56:44 AM=0ASubject: [zf-contributors] Discuss=
ion about Quality/Review Process - Community RM proposal=0A=0A=0AHello cont=
ributors,=0A=0Aregarding the Backwards-Compabilitiy or not change problem w=
ith the 1.9.3=0Arelease we had a fairly extensive discussion on IRC yesterd=
ay that I=0Awould like to share with everyone who was not able to participa=
te.=0A=0ATo explain the issue, the 1.9.3 release had a BC break by changing=
=0Ahow the Zend_Db::factory works. A Use-Case that was never described=0Ain=
 documentation but was valid according to the methods docblock=0Awas change=
d.=0A=0ANow we had such problems in previous releases also and they are bou=
nd=0Ato happen again, however the question was how we could extend the qual=
ity=0Aprocess to minimize the effect of such problems and detect them as so=
on=0Aas possible.=0A=0ASeveral approaches were proposed for example:=0A1. c=
ommit kudos system=0A2. review system=0A3. community release master=0A=0ATh=
e third got the most attention. I'll shortly describe what was discussed.=
=0AA trusted community member would be appointed Release Master by the=0Aco=
ntributors=0Afor each .y release of the x.y.z release cycle. An additional =
Zend employee=0Ais appointed to help this release master out. A new RM woul=
d be chosen=0Awhenever the previous .y.0 release is shipped so that he can =
begin=0Areviewing changes to the trunk/library/ for potential BC or other p=
roblems,=0Ai.e. non component maintainers committing new undiscussed featur=
es=0Ainto a component.=0A=0AWhen the RMs branch is released as a new .y.0 r=
elease every merge from the=0Atrunk to his release branch has to be done by=
 him, or at least been=0Aapproved=0Aby him and otherwise gets reverted.=0A=
=0AIn practice there would always be two RMs at one point in time, one that=
=0Amaintains the current release branch and one that prepares the next=0Are=
lease branch.=0A=0ATime Frame for such a community involvment would therefo=
re be about 6-12=0Amonth=0Adepending on the release cycle.=0A=0AI hope this=
 discussion can continue here, so that we may even get some=0Aresults for t=
he 1.10 release.=0A=0Agreetings,=0ABenjamin
--0-672021064-1253710330=:60339
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Hi Benjamin,<br><br>To be honest, I'm not sure a Release Manag=
er would solve the perceived problem. I'm not saying it's a bad idea, it pr=
obably is a good idea for a slightly different set of reasons. My main rese=
rvation is that applying a specific responsibility (prevent backwards compa=
tibility breaks) to the role of Release Manager would be next to impossible=
 to effectively implement without some drastic changes in how QA is applied=
 to the source code. In fact, I'd go so far as to say discussing a Release =
Manager role is missing the obvious target.<br><br>Consider how QA works in=
 Zend Framework. We have unit tests, documentation, the issue tracker, and =
with a little luck a responsible committer and/or Lead Developer per compon=
ent. I think the issue tracker works just fine - it desperately needs
 more community involvement and that's why I'm overjoyed to take part in th=
e Bug Hunts (and encourage, shame, blackmail others into taking part too ;)=
). The other three however have issues of their own.<br><br>The unit tests =
vary in quality from ones that are sharp, focused, and methodically assert =
against behaviour slice by slice to those which are so mistargeted or aggre=
gated as to be perfectly useless. The second set represent a significant ri=
sk. I've already run afoul of several without realising it, and that experi=
ence would teach anyone the folly of relying on such low-quality unit tests=
 for anything. This prevents other improvements, not simply new features to=
 these components, but any form of refactoring out of fear a BC break will =
emerge and remain undetected. It also goes without saying that "backwards c=
ompatibility" has never been defined for the Zend Framework. I gather from =
IRC that there is some debate over whether it applies to protected
 methods (which is close to insane in my opinion since then how could we ev=
er refactor) or not. In an environment like this, any Release Manager is co=
nstantly being undermined and will be forced to personally peer review the =
entire component end to end, make a judgement call, and open themselves up =
to arguments from anyone effected.<br><br>As for responsibility, not all co=
mponents have a responsible person. During the Bug Hunt I started assigning=
 all Zend_Feed and Zend_OpenId issues to myself (short of officially taking=
 over), and I know others have been doing the same. This still leaves a lot=
 of orphaned components whose issues are transferred to a default Zend memb=
er who probably won't touch them with a barge pole. Not that I remotely bla=
me whoever that may be - fixing issues on an unfamiliar component can be a =
frustrating and time-consuming exercise (especially when its unit tests suc=
k). Over the bug hunt, I spent half a day on one component fixing
 three issues simply because I needed time to familiarise myself with it, r=
eview the unit tests, read the source code, etc. That was not even orphaned=
, and its unit tests were passable. Unfortunately, orphaned components are =
often either already completely broken or have been impacted by a poorly ju=
dged patch that nobody has gotten around to fixing yet. Our web service com=
ponents are notorious in this regard.<br><br>Documentation is the least of =
the worries. Mostly it's accurate, but it does need a fuller review at some=
 point, or a deliberate restart for Zend Framework 2.0. It's main problem i=
s that it's written by developers (that will not change ;)) but also that i=
t seems impervious to any form of iterative improvement. Once written, docu=
mentation rarely changes and any of its flaws become permanent problems tha=
t will very rarely ever reach the issue tracker.<br><br>When you combine al=
l three, any Release Manager is going to very quickly realise they
 cannot effectively perform a role in preventing backwards compatibility br=
eaks. Unit tests will not help, components are orphaned with no point of co=
ntact, and the documentation can suck so badly that reading the source code=
 is actually easier and faster. Then there is the matter of who will fix th=
em all. Multiply by dozens of components. It's not a job one single individ=
ual should be landed with.<br><br>In my opinion, we should first improve ho=
w QA is performed and then, with some luck, revisit how a Release Manager r=
ole could operate.<br><br>Of course all of my meandering has one simple pro=
blem - how to motivate the community to actively take part and contribute t=
heir time and skill. Without that, it would all be doomed to failure anyway=
.<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D=
"font-family: times new roman,new york,times,serif;" size=3D"3"><span style=
=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span
 style=3D"font-style: italic;"><font style=3D"font-family: times new roman,=
new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" hre=
f=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a r=
el=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com"=
>http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_bla=
nk" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Rep=
resentative</a><br></font></span></span><div><br></div><div style=3D"font-f=
amily: times new roman,new york,times,serif; font-size: 12pt;"><br><div sty=
le=3D"font-family: tahoma,new york,times,serif; font-size: 8pt;"><font face=
=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font-weight: bold;"=
>From:</span></b> Benjamin Eberlei &lt;[email-masked]&gt;<br><b><span =
style=3D"font-weight: bold;">To:</span></b> [email-masked]<=
br><b><span style=3D"font-weight: bold;">Sent:</span></b> Wednesday, Septem=
ber 23, 2009 8:56:44
 AM<br><b><span style=3D"font-weight: bold;">Subject:</span></b> [zf-contri=
butors] Discussion about Quality/Review Process - Community RM proposal<br>=
</font><br>=0A<br>Hello contributors,<br><br>regarding the Backwards-Compab=
ilitiy or not change problem with the 1.9.3<br>release we had a fairly exte=
nsive discussion on IRC yesterday that I<br>would like to share with everyo=
ne who was not able to participate.<br><br>To explain the issue, the 1.9.3 =
release had a BC break by changing<br>how the Zend_Db::factory works. A Use=
-Case that was never described<br>in documentation but was valid according =
to the methods docblock<br>was changed.<br><br>Now we had such problems in =
previous releases also and they are bound<br>to happen again, however the q=
uestion was how we could extend the quality<br>process to minimize the effe=
ct of such problems and detect them as soon<br>as possible.<br><br>Several =
approaches were proposed for example:<br>1. commit kudos system<br>2. revie=
w system<br>3. community release master<br><br>The third got the most atten=
tion. I'll shortly describe what was discussed.<br>A trusted community memb=
er
 would be appointed Release Master by the<br>contributors<br>for each .y re=
lease of the x.y.z release cycle. An additional Zend employee<br>is appoint=
ed to help this release master out. A new RM would be chosen<br>whenever th=
e previous .y.0 release is shipped so that he can begin<br>reviewing change=
s to the trunk/library/ for potential BC or other problems,<br>i.e. non com=
ponent maintainers committing new undiscussed features<br>into a component.=
<br><br>When the RMs branch is released as a new .y.0 release every merge f=
rom the<br>trunk to his release branch has to be done by him, or at least b=
een<br>approved<br>by him and otherwise gets reverted.<br><br>In practice t=
here would always be two RMs at one point in time, one that<br>maintains th=
e current release branch and one that prepares the next<br>release branch.<=
br><br>Time Frame for such a community involvment would therefore be about =
6-12<br>month<br>depending on the release cycle.<br><br>I hope this
 discussion can continue here, so that we may even get some<br>results for =
the 1.10 release.<br><br>greetings,<br>Benjamin<br><br></div></div></div></=
body></html>
--0-672021064-1253710330=:60339--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 26 Jul 2009 11:29:41 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services
	to ZendX Proposal

-- P=C3=A1draic Brady <[email-masked]> wrote
(on Sunday, 26 July 2009, 06:48 AM -0700):
> The problem isn't just restricted to those mentioned either. Other comp=
onents
> have been developed, tested, released - and then maintenance simple cea=
ses or
> continues in a minimalistic way - the issue tracker turnover rate is ho=
rrendous
> at times. One of the less obvious problems is that the lack of active
> development (i.e. accounting for API/protocol changes and featuresets) =
makes
> these difficult to rely on in practice since you can make a google sear=
ch and
> find something more up to the minute boasting new features, extensions =
or
> protocol support not offered by the Zend versions. This also does not b=
ode well
> for security/usability - it is not very cool to have users reporting pr=
oblems
> in the issue tracker than any decently designed test suite should pick =
up
> instantly.

I completely understand what you're saying, but I also need to step in
and say: if you are writing a component, you should be maintaining it.
We at Zend are a *VERY* small team (currently myself and two engineers),
and we simply do not have the manpower or expertise to maintain all
components -- and yet, for some reason, there is an expectation in the
community that we do, and that it *is* our job.

We need more community help in maintaining the framework. I have some
ideas on how to achieve this, but I need *your* ideas as well, as
contributors.

> Just to offer another example outside the services API area, since I'm =
the
> Irish rep sitting on its Europe Foundation, Zend_Openid persists in a s=
tate of
> limbo offering OpenID 2.0 Draft 11 compliance. OpenID 2.0 Final was rel=
eased
> back in December 2007... It has continually presented problems maintain=
ing
> compliance with OpenID servers from the likes of Google and Yahoo - it =
still
> doesn't. It still can't handle discovery. It also still can't operate w=
ith
> servers offering any popular extension outside of the Simple Registrati=
on
> module (which is steadily in decline as Attribute Exchange is adopted).=
 In
> short, it's rarely, if ever, been all that reliable.

Paddy, to be honest, this feels like a really daft criticism. Dmitry did
do the original Zend_OpenId component, but we have blocked on YOU to do
the 2.0 support. When Dmitry started the OpenId component, I had Andi
put him in touch with you so that the two of you could collaborate. At
that time, you indicated that you would assist as you could, but that
you would spend your efforts on OAuth and Yadis support, and then help
with shaping our 2.0 support. These components have remained in
basically proposal stage since spring 2008.=20

So, bad example; if you want to see further support for the 2.0 Draft 11
specs, then please help us by completing what you started -- or indicate
you won't do it, so that somebody else can potentially step in and
complete this effort.

> What's really needed is some form of maintainance oversight - if we
> can get a handle on what these components do, what standard/spec they
> should adhere to, and whether they are doing that, we can pinpoint the
> failing components. A maintenance log (svn log works at a pinch) and
> JIRA can pinpoint slack maintainance or a lack of active development.
> From there it should be easy to assess what components represent the
> greatest risk - then demote them as needed if work is not forthcoming.=20

I don't think demotion is an option. Even with the bugs, developers come
to rely on the components, and if they suddenly disappear in a given
release, this will cause some very real consternation -- much worse than
if they remained as-is.

What *is* needed is a way to hand off maintenance to new contributors
interested in the component.

> Same could be said of the Incubator (where I can be pretty guilty I
> know ;)).=20

See my notes above.

That said, I'm working on a process for better managing the proposal
process -- which should better be titled the "contribution process", as
it should include not only the proposal itself, but the process for
development, inclusion in the trunk, and long-term maintenance. I'd
welcome your ideas -- and those of anybody else on this list -- in how
you would envision this should work.

> The other perceivable problem is testing quality - some issues on Jira
> show a terrible record for problems arising which should be easily
> detected. The lack of actual testing against services (while
> understandable where support for developer testing accounts/IDs is not
> forthcoming) will always be problematic though.

Services are always difficult. There are some good approaches that can
be used, but the difficulty will always be present as APIs evolve.

> =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=
> From: Benjamin Eberlei <[email-masked]>
> To: [email-masked]
> Sent: Sunday, July 26, 2009 10:35:36 AM
> Subject: [zf-contributors] Zend_Service_Amazon API Upgrade + Services t=
o ZendX
> Proposal
>=20
> Hello Everyone,
>=20
> i took the time today to look at the Problem of Zend_Service_Amazon. Du=
e to an
> API upgrade the ZF component won't work anymore come August 15th. I jus=
t saw
> that the component uses the API from 2005, so its hopelessly out of dat=
e. I'll
> look into a possible fix, but i can't guarantee for this to work with t=
he 2005
> API and i dont know how complex a migration to the latest 2009 API is.
>=20
> This out of date problem is the case with most of the other Service com=
ponents
> besides Twitter, S3 and EC2. Their code-base is mostly crap and they ar=
e all
> unmaintained.
>=20
> I want to propose a change to ZFs handling of Service components. Since=
 they
> all rely on third party API (through them having to rely on the stabili=
ty of
> external webservices) they should all be moved into ZendX for 2.0. Also=
 every
> new service component from now on should only be included in ZendX, wit=
h the
> exception of service integration being programmed from companies that h=
ave an
> agreement with Zend, such as the Infocard, Google and AMF components, w=
here
> the stability and up-to-date API can be somewhat guaranteed.
>=20
> greetings,
> Benjamin
>=20
> --
> Benjamin Eberlei
> http://www.beberlei.de

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Tue, 7 Apr 2009 08:51:14 +0200
Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*

* Added  Zend_Json Expression support, contributed by Benjamin Eberlei
* Added Zend_Http_Client_Adapter_Curl, contributed by Benjamin Eberlei

On Monday 06 April 2009 22:07:01 Thomas Weidner wrote:
> My most important additions for 1.8 are:
>
> * several improvements to Zend_File_Transfer and Zend_Form_Element_File,
> contributed by Thomas Weidner
> * added file upload progress to Zend_File_Transfer, contributed by Thomas
> Weidner
> * added 84 new IDN's and completly reworked Zend_Validate_Hostname,
> contributed by Thomas Weidner
> * added locale support to Zend_Validate_Int and Zend_Validate_Float,
> contributed by Thomas Weidner
> * added phonecode support to Zend_Locale, contributed by Thomas Weidner
> * Zend_Validate_Iban, contributed by Thomas Weidner
> * Zend_Validate_File_WordCount, contributed by Thomas Weidner
> * Zend_Filter_Encrypt, contributed by Thomas Weidner
> * Zend_Filter_Decrypt, contributed by Thomas Weidner
> * added logging support to Zend_Translate, contributed by Thomas Weidner
> * added documentation of all Zend_Validate messages, contributed by Thomas
> Weidner
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: "Robin Skoglund" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, April 06, 2009 8:02 PM
> Subject: RE: [zf-contributors] 1.8 PR feature list and *acknowledgements*
>
>
> I believe Zend_Navigation is in if the minor changes that we have
> recommended are made. Matthew can tell you more. It is a really sweet
> component, BTW. J
>
>
>
> ,Wil
>
>
>
> From: Robin Skoglund [mailto:[email-masked]]
> Sent: Monday, April 06, 2009 11:02 AM
> To: Wil Sinclair
> Cc: [email-masked]
> Subject: Re: [zf-contributors] 1.8 PR feature list and
> *acknowledgements*
>
>
>
> On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <[email-masked]> wrote:
>
> NOTE: For this release, we'd like to try something new in the feature
> list- actually acknowledging the significant contributions that y' all
> have made. J The format would be like this:
>
>
>
> * Zend_Application, contributed by Matthew Weier O'Phinney and Ben
> Scholzen
>
>
>
> ,Wil
>
> Hi, I haven't gotten any answer on whether Zend_Navigation will be
> included in the PR, but here goes:
>
> * Zend_Navigation, contributed by Robin Skoglund
>
>         robinsk

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 26 Jul 2009 06:48:35 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
	ZendX Proposal

--0-1893194395-1248616115=:20690
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,=0A=0AThe problem isn't just restricted to those mentioned either. O=
ther components have been developed, tested, released - and then maintenanc=
e simple ceases or continues in a minimalistic way - the issue tracker turn=
over rate is horrendous at times. One of the less obvious problems is that =
the lack of active development (i.e. accounting for API/protocol changes an=
d featuresets) makes these difficult to rely on in practice since you can m=
ake a google search and find something more up to the minute boasting new f=
eatures, extensions or protocol support not offered by the Zend versions. T=
his also does not bode well for security/usability - it is not very cool to=
 have users reporting problems in the issue tracker than any decently desig=
ned test suite should pick up instantly.=0A=0AJust to offer another example=
 outside the services API area, since I'm the Irish rep sitting on its Euro=
pe Foundation, Zend_Openid persists in a state of limbo offering OpenID 2.0=
 Draft 11 compliance. OpenID 2.0 Final was released back in December 2007..=
. It has continually presented problems maintaining compliance with OpenID =
servers from the likes of Google and Yahoo - it still doesn't. It still can=
't handle discovery. It also still can't operate with servers offering any =
popular extension outside of the Simple Registration module (which is stead=
ily in decline as Attribute Exchange is adopted). In short, it's rarely, if=
 ever, been all that reliable.=0A=0AWhat's really needed is some form of ma=
intainance oversight - if we can get a handle on what these components do, =
what standard/spec they should adhere to, and whether they are doing that, =
we can pinpoint the failing components. A maintenance log (svn log works at=
 a pinch) and JIRA can pinpoint slack maintainance or a lack of active deve=
lopment. From there it should be easy to assess what components represent t=
he greatest risk - then demote them as needed if work is not forthcoming. S=
ame could be said of the Incubator (where I can be pretty guilty I know ;))=
. The other perceivable problem is testing quality - some issues on Jira sh=
ow a terrible record for problems arising which should be easily detected. =
The lack of actual testing against services (while understandable where sup=
port for developer testing accounts/IDs is not forthcoming) will always be =
problematic though.=0A=0A=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutu=
ra.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish =
Representative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Be=
njamin Eberlei <[email-masked]>=0ATo: [email-masked]=
=0ASent: Sunday, July 26, 2009 10:35:36 AM=0ASubject: [zf-contributors] Zen=
d_Service_Amazon API Upgrade + Services to ZendX Proposal=0A=0AHello Everyo=
ne,=0A=0Ai took the time today to look at the Problem of Zend_Service_Amazo=
n. Due to an =0AAPI upgrade the ZF component won't work anymore come August=
 15th. I just saw =0Athat the component uses the API from 2005, so its hope=
lessly out of date. I'll =0Alook into a possible fix, but i can't guarantee=
 for this to work with the 2005 =0AAPI and i dont know how complex a migrat=
ion to the latest 2009 API is.=0A=0AThis out of date problem is the case wi=
th most of the other Service components =0Abesides Twitter, S3 and EC2. The=
ir code-base is mostly crap and they are all =0Aunmaintained.=0A=0AI want t=
o propose a change to ZFs handling of Service components. Since they =0Aall=
 rely on third party API (through them having to rely on the stability of =
=0Aexternal webservices) they should all be moved into ZendX for 2.0. Also =
every =0Anew service component from now on should only be included in ZendX=
, with the =0Aexception of service integration being programmed from compan=
ies that have an =0Aagreement with Zend, such as the Infocard, Google and A=
MF components, where =0Athe stability and up-to-date API can be somewhat gu=
aranteed.=0A=0Agreetings,=0ABenjamin=0A=0A-- =0ABenjamin Eberlei=0Ahttp://w=
ww.beberlei.de=0A
--0-1893194395-1248616115=:20690
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Hi all,<br><br>The problem isn't just restricted to those ment=
ioned either. Other components have been developed, tested, released - and =
then maintenance simple ceases or continues in a minimalistic way - the iss=
ue tracker turnover rate is horrendous at times. One of the less obvious pr=
oblems is that the lack of active development (i.e. accounting for API/prot=
ocol changes and featuresets) makes these difficult to rely on in practice =
since you can make a google search and find something more up to the minute=
 boasting new features, extensions or protocol support not offered by the Z=
end versions. This also does not bode well for security/usability - it is n=
ot very cool to have users reporting problems in the issue tracker than any=
 decently designed test suite should pick up instantly.<br><br>Just to
 offer another example outside the services API area, since I'm the Irish r=
ep sitting on its Europe Foundation, Zend_Openid persists in a state of lim=
bo offering OpenID 2.0 Draft 11 compliance. OpenID 2.0 Final was released b=
ack in December 2007... It has continually presented problems maintaining c=
ompliance with OpenID servers from the likes of Google and Yahoo - it still=
 doesn't. It still can't handle discovery. It also still can't operate with=
 servers offering any popular extension outside of the Simple Registration =
module (which is steadily in decline as Attribute Exchange is adopted). In =
short, it's rarely, if ever, been all that reliable.<br><br>What's really n=
eeded is some form of maintainance oversight - if we can get a handle on wh=
at these components do, what standard/spec they should adhere to, and wheth=
er they are doing that, we can pinpoint the failing components. A maintenan=
ce log (svn log works at a pinch) and JIRA can pinpoint slack
 maintainance or a lack of active development. From there it should be easy=
 to assess what components represent the greatest risk - then demote them a=
s needed if work is not forthcoming. Same could be said of the Incubator (w=
here I can be pretty guilty I know ;)). The other perceivable problem is te=
sting quality - some issues on Jira show a terrible record for problems ari=
sing which should be easily detected. The lack of actual testing against se=
rvices (while understandable where support for developer testing accounts/I=
Ds is not forthcoming) will always be problematic though.<br><br><br><div>&=
nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-famil=
y: times new roman,new york,times,serif;" size=3D"3"><span style=3D"font-we=
ight: bold;">P=E1draic Brady<br><br></span></font><span style=3D"font-style=
: italic;"><font style=3D"font-family: times new roman,new york,times,serif=
;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font =
size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><span style=3D"font-weight: bo=
ld;">From:</span></b> Benjamin Eberlei &lt;[email-masked]&gt;<br><b><s=
pan style=3D"font-weight: bold;">To:</span></b> [email-masked].=
com<br><b><span style=3D"font-weight: bold;">Sent:</span></b> Sunday, July =
26, 2009 10:35:36 AM<br><b><span style=3D"font-weight: bold;">Subject:</spa=
n></b> [zf-contributors] Zend_Service_Amazon API Upgrade + Services to Zend=
X Proposal<br></font><br>=0AHello Everyone,<br><br>i took the time today to=
 look at the Problem of Zend_Service_Amazon. Due to an <br>API upgrade the =
ZF component won't work anymore come August 15th. I just saw <br>that the c=
omponent uses the API from 2005, so its hopelessly out of date. I'll <br>lo=
ok into a possible fix, but i can't guarantee for this to work with the 200=
5 <br>API and i dont know how complex a migration to the latest 2009 API is=
.<br><br>This out of date problem is the case with most of the other Servic=
e components <br>besides Twitter, S3 and EC2. Their code-base is mostly cra=
p and they are all <br>unmaintained.<br><br>I want to propose a change to Z=
Fs handling of Service components. Since they <br>all rely on third party A=
PI (through them having to rely on the stability of <br>external webservice=
s) they should all be moved into ZendX for 2.0. Also every <br>new service =
component from now on should only be included in ZendX, with the <br>except=
ion of service
 integration being programmed from companies that have an <br>agreement wit=
h Zend, such as the Infocard, Google and AMF components, where <br>the stab=
ility and up-to-date API can be somewhat guaranteed.<br><br>greetings,<br>B=
enjamin<br><br>-- <br>Benjamin Eberlei<br><span><a target=3D"_blank" href=
=3D"http://www.beberlei.de">http://www.beberlei.de</a></span><br></div></di=
v></div></body></html>
--0-1893194395-1248616115=:20690--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 23 Nov 2009 15:52:56 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.9.6 sanity check tarballs ready

Greetings!

Thanks everyone for participating in the Bug Hunt Days last week! Many
of the fruits of your labors will be released this week, with ZF 1.9.6.

I've prepared some sanity check tarballs:

 * Full packages:
   http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramework-1.9.6.tar.gz
   http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramework-1.9.6.zip

 * Minimal packages:
   http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramework-1.9.6-minimal.tar.gz
   http://framework.zend.com/releases/ZendFramework-1.9.6/ZendFramework-1.9.6-minimal.zip

At this time, we plan to release late tomorrow (Tuesday) or early
Wednesday (EST).

Please test and let me know ASAP if you discover any show stoppers. 

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 16:49:40 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] use statements -- usage?

Hey, all --

Within a namespace, you don't need to import subcomponent
namespaces, as you can use the relative namespaces to help identify
classes. As an example, from Zend\Acl:

    public function add(Role\RoleInterface $role) { }

    $registry = new Role\Registry\Registry();

    etc.

Does it make sense to create "use" statements for these, or simply start
using them without aliases? Part of me wants to define the "use"
statements to help with automating packaging; another feels we can
simply assume anything within the given namespace is going to be
packaged together anyways.

Thoughts?

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Sun, 12 Apr 2009 18:33:48 +0200
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

why do something that is not even accepted yet?

but in your case CloudDecorator and TagDecorator seem to be better than *Core 
for me

On Sunday 12 April 2009 18:05:33 Ben Scholzen 'DASPRiD' wrote:
> Hey Matthew,
>
> I'm currently reworking Zend_Tag to fit those new naming. I renamed
> Zend_Tag_IItem to Zend_Tag_Taggable, which sounds good. But now for the
> following two abstract classes:
>
> Zend_Tag_Cloud_Decorator_Cloud
> Zend_Tag_Cloud_Decorator_Tag
>
> How would you name them? I had the following in mind, but I'm not sure:
>
> Zend_Tag_Cloud_Decorator_CloudCore
> Zend_Tag_Cloud_Decorator_TagCore
>
> As those just substitute "Abstract" with "Core" then. Any thoughts on that?
>
> Ben
> ...................................
>
> :  ___   _   ___ ___ ___ _ ___    :
> : |   \ /_\ / __| _ \ _ (_)   \   :
> : | |) / _ \\__ \  _/   / | |) |  :
> : |
> : |___/_/:\_\___/_| |_|_\_|___/   :
> :
> :........:........................:
> : Web    : http://www.dasprids.de :
> : E-mail : [email-masked]       :
> : Jabber : [email-masked]     :
> : ICQ    : 105677955              :
> :........:........................:
>
> Matthew Weier O'Phinney schrieb:
> > Greetings, all --
> >
> > Below is a proposal I am making to modify the Zend Framework Coding
> > Standards conventions for the naming of Interfaces and Abstract classes.
> >
> > This decision is basically already made, but I'd appreciate any feedback
> > that you may have on the matter.
> >
> > Thanks!
> >
> > The problem
> > ===========
> > PHP 5.3 introduces namespaces to the PHP language. While this won't have
> > an impact much on userland code, it will have an impact on library and
> > framework code, as it provides a useful paradigm for organizing
> > components as well as simplifying syntax. Instead of having to say things
> > like:
> >
> >     $analyzer = new
> > Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> >
> > we can instead do something like this:
> >
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >     $analyzer = new Common_TextNum();
> >
> > or even:
> >
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >     class Common_TextNum extends Common
> >     {
> >     }
> >
> > The problem that arises for Zend Framework has to do with how we name
> > abstract classes and interfaces. Currently, the final segment of such
> > classes are expected to end with _Abstract and _Interface, respectively.
> > This will not work when we migrate to utilize namespaces, for two
> > reasons.
> >
> > First, and most obviously, 'abstract' and 'interface' are reserved PHP
> > keywords. As such, in situations such as the following:
> >
> >     namespace Zend\Controller\Request;
> >
> >     class Abstract
> >     {
> >     }
> >
> >     // or:
> >
> >     namespace Zend\Controller\Dispatcher;
> >
> >     interface Interface
> >     {
> >     }
> >
> > we'll run into issues.
> >
> > Second, and less obvious, is that perhaps the easiest solution breaks one
> > of the key principles of namespaces (which are designed to help
> > encapsulate components). This one's harder to explain, so let's look at
> > examples. Consider a component such as Zend_Controller_Request. The
> > simplest solution would be to name the abstract class or interface
> > Zend\Controller\Request, and then have the various concrete
> > implementations under that namespace:
> >
> >     namespace Zend\Controller;
> >
> >     interface Request
> >     {
> >     }
> >
> >     // and concrete ones:
> >
> >     namespace Zend\Controller\Request;
> >
> >     class Http
> >     {
> >     }
> >
> > What's the problem here? The interface is not in the same namespace as
> > the concrete implementations.
> >
> > Potential solutions and recommendation
> > ======================================
> > So, how should Zend Framework "solve" these issues? A number of proposals
> > and recommendations have been floated around, both within ZF circles and
> > in the greater PHP community.
> >
> > Considerations include:
> >
> >  * Avoiding the use of PHP reserved keywords (already noted).
> >  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
> > name describe its type -- which, to a degree, the current naming
> > conventions already violate). (See
> > http://en.wikipedia.org/wiki/Hungarian_Notation, the sections
> > "Disadvantages of Systems Hungarian" and "Notable Opinions" for some of
> > the arguments against using Hungarian Notation.)
> >
> > Approaches that have been considered include:
> >
> >  * Using 'I' to prefix interfaces. This derives from standards in other
> >    programming languages (.Net and python, in particular). This is just
> > another form of Hungarian Notation, however.
> >
> >  * Using "Interface" or "Abstract" as a class name suffix:
> > RequestInterface, RequestAbstract. Again, however this is Hungarian
> > Notation.
> >
> >  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
> > Base. This is just substituting the word Base for Abstract, however, and
> > is really not much different than the above.
> >
> >  * Use generic, descriptive names indicative of functionality or
> > behavior. As examples from the SPL, "Countable", "Iterator",
> > "ArrayObject".
> >
> > My recommendation is to use the latter, as it solves all considerations.
> > It will take more thought when naming, but will ensure that components
> > can live in a self-contained namespace, do not use reserved keywords, and
> > avoid Hungarian Notation.
> >
> > Plan for implementation
> > =======================
> > I recommend that the Coding Standards documentation be updated to reflect
> > this approach.
> >
> > All new components going into 1.8 and onwards should adopt these
> > standards. In releases 1.9 and forward, we will begin migrating existing
> > interfaces/abstract classe. First, new classes/interfaces will be created
> > that follow these conventions and which extend the originals; later, any
> > type-hinting based on the original class/interface names will be updated
> > to point to the new names; and finally, in 2.0, we will remove the old
> > interfaces/abstract classes entirely.

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 16 Nov 2009 08:54:46 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

-- Jurri=EBn Stutterheim <[email-masked]> wrote
(on Sunday, 15 November 2009, 08:21 PM +0100):
> The ideas and discussions for ZF 2.0 have been great so far, and I'm
> really looking forward to the actual release!
>=20
> There's a non-technical issue that ZF 2.0 should try to tackle. This
> issue is getting beginners up to speed quickly, and to get people more
> involved in the community.

This is an initiative the Zend team is currently working on, actually.
We have begun writing a series of tutorials that will be a part of the
manual:

    http://framework.zend.com/svn/framework/standard/branches/user/zf-dev=
team/documentation/en/

We're getting some "core" tutorials out there, but then plan to use the
proposal process to get new content in (either to request new content,
or submit new content).

That said, it needs to be a core requirement for 2.0 as well,
particularly since some areas will be changing dramatically.

> First off, developers should get the tools and knowledge to get
> started with developing right away. The Quickstart is doing great with
> this, but it could probably use a dedicated chapter for setting up a
> development environment. That is, Zend Server and PDT/ZSfE or
> Netbeans, with full debugging support etc.

This is a good point. I've had to answer a number of questions regarding
setting up virtual hosts over the past months -- something I took for
granted as a basic skill. I'll add this to my current TODO.

> What comes next is probably where ZF is currently lacking most.
> Currently the documentation we have are the quickstart, followed by
> the reference guide. For me - someone who's been using ZF since around
> v0.2 - that's perfectly fine, but the step is too big for a beginner.

The tutorials we're creating will be in a "Learning Zend Framework"
section that follows the introduction; this will be followed by the
current "Reference Guide" section. The way it will be shown is:

     I. Introduction to Zend Framework
    II. Learning Zend Framework
   III. Reference Guide
    IV. Appendixes

> Basically two things need to be made clear to someone who just
> finished the quickstart: how does the ZF community work (where can I
> get help, how can I help, etc.), and where do I go from here?=20

Good point on the community stuff. However, that part has traditionally
been the realm of the main website and wiki -- not the manual.

> Paddy has been doing some amazing work on the latter question with his
> Survive The Deep End book, that's freely available online
> (http://www.survivethedeepend.com/). Why not make this a permanent
> link on the ZF homepage, between quickstart and reference guide?  The
> former ("where can I get help/how can I help") could be made more
> clear to make links to the mailing lists and #zftalk and #zftalk.dev
> more visible on the ZF frontpage.=20

There have been a few notes about the mailing list visibility on the
website, and I'm hoping to address that soon.

> Expanding on the community point a bit, it might be a good thing to
> keep the level of experience of developers in mind on the wiki and the
> mailing list. Paddy and Kevin touched this topic in their discussion
> in this thread, and I've read the term "too compsci-y" somewhere in
> that discussion too. To be perfectly honest, I'm completely fine with
> discussions and proposals that expect some compsci experience from the
> reader. That said, it might be a good thing to get people without a
> compsci degree in on the discussions as well, which is probably
> actually quite a large group of people in the PHP world. For example,
> the Zend_Controller 2.0 proposal mentions an FSM. For people that do
> not know what an FSM is, a reference to an introductory article on
> FSMs might be interesting. In a discussion I had with a friend we
> couldn't agree on how this could be achieved best, without dumbing
> things down too much. I'd be interested to hear your opinions on this.

I can agree with this to a point. Right now, I'm trying to get primarily
architectural feedback, which really requires a fair bit of discussion
of design patterns and CS concepts.=20

When it's time for official proposals, we'll be focussing primarily on
use cases -- and *that* is where we can make things simpler and address
the full range of ZF developers. I figure the following:

    $application =3D new \zend\Application(
        APPLICATION_ENV,=20
        APPLICATION_PATH . '/configs/application.ini'
    );
    $application->bootstrap()
                ->run();

and:

    // Add a listener for pre-action dispatch:
    $manager =3D $this->getResource('event_manager');
    $pubsub  =3D $manager->getPubSub();
    $pubsub->subscribe('mvc.dispatcher.pre', 'my\plugins\ContextNegotiati=
on');

and:

    // Indicate it's time to send the response:
    $e->setState('response');
    return;

are concepts the end-user can easily grasp without needing to know a
whole lot about how it actually works internally.

> On Nov 11, 2009, at 19:38 , Matthew Weier O'Phinney wrote:
>=20
> > Hey, all --
> >=20
> > There have been a ton of questions about the ZF 2.0 roadmap, and my
> > answer has been consistently, "I'm working on it; I'll have something=
 to
> > publish soon."
> >=20
> > "Soon" is now:
> >=20
> >    http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+R=
oadmap
> >=20
> > I'd like you, as contributors, to look over it, and start discussing =
the
> > various ramifications; we can do that either in comments to the pages=
 or
> > on this list.
> >=20
> > The roadmap is primarily a conceptual one right now, though a
> > proof-of-concept has been created for the proposed MVC. I'd like to s=
tay
> > fairly high-level for now, and then start getting a flow of proposals
> > into the system for specific migration-related tasks.
> >=20
> > Thanks everyone who has provided me input over the past many months, =
and
> > let's get started on the next generation of ZF!
> >=20
> > --=20
> > Matthew Weier O'Phinney
> > Project Lead            | [email-masked]
> > Zend Framework          | http://framework.zend.com/
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Thu, 1 Oct 2009 18:13:49 +0200
Subject: Re: [zf-contributors] Google Wave Invites

I've added the guys I mentioned before to my invites Q, but I presume it wi=
ll=20
take a short while for the invites to get send out, here's what the form sa=
ys.

"Invitations will not be sent immediately. We have a lot of stamps to lick.=
"=20

So just be patient I guess :)

=2D-=20
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D
 =E2=98=98 Oscar Wilde

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 00:02:41 +0100
From: drm <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

Hi,

Regarding interfaces I'm in favor of 1. I've found that in theory the 
"readable English" naming feels better (as in e.g. Countable), but in 
practice not every thing is very well translated into adjectives. Nouns 
on the other hand render ambiguity. An "Element" interface might clash 
with an Element (base, not abstract per se) class, but the 'I' prefix 
gives the author all freedom to however he thinks the interface is named 
best, including the no 3 convention, e.g. IComparable. Last but not 
least, naming rules in coding standards are ideally checkable by a code 
sniffer imho. That's impossible if they're arbitrarily named.

Nonetheless, following the SPL naming style makes perfect sense to me too.

On abstract classes I've always preferred the Abstract prefix, so a 
variant of 6.

But at the end of the day it wouldn't be something I'd fight over, after 
all it remains a matter of taste :-)

drm / Gerard

Matthew Weier O'Phinney wrote:
> Hey, all --
>
> I know this has been hashed out a fair bit already, and we've already
> established some guidelines, but as I play with code for ZF2, I'm
> beginning to question the naming conventions for Interfaces and Abstract
> Classes.
>
> When we made the decisions before, we were looking at the following
> three options for interfaces:
>
>  1. Prefix interfaces with "I" ("IFoobar"). 
>  2. Suffix interfaces with "Interface" ("FoobarInterface")
>  3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> For abstract classes, we looked at:
>
>  4. Prefix abstract classes with "A" ("AFoobar")
>  5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>  6. Prefix abstract classes with "Base" ("BaseFoobar")
>  7. Suffix abstract classes with "Base" ("FoobarBase")
>  8. Use normal class names ("Foobar")
>
> Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
> they smack of Hungarian Notation, the long forms lead to really long
> names, etc. Prefixing can lead to similar classes not being grouped when
> doing directory listings (i.e., all abstract class or interface files
> get clustered together). Also, for classes beginning with "I" or "A",
> there can potentially be confusion over whether or not the given class
> is supposed to be concrete. Finally, during refactoring, if you choose
> to make an interface an abstract class or concrete class, or an abstract
> class an interface or concrete class, you can't do so without renaming
> files and classes. (That said, you'll most likely need to make other
> changes anyways -- and ZF will likely never make an interface an
> abstract class or vice versa.)
>
> Regarding 3 and 8, the primary problems are that it's often hard to come
> up with meaningful names that do not conflict with concrete
> implementations, and that for non-native English speakers, this latter
> problem becomes an even bigger obstacle. Additionally, you can't
> determine which files contain abstract classes and/or interfaces just by
> the filename -- you have to look in the file or look in API
> documentation to determine this information. 
>
> Now, as to the issues I've seen: the word "Interface" becomes a real
> pain to type (yes, even with autocompletion), and it doesn't really
> connote any real information. When type-hinting, I simply know what type
> I want to use -- the name doesn't need to tell me it's an interface, as
> I already know that information. If I'm writing code that consumes or
> interacts with the class, API docs will tell me what I need to do.
>
> That said, I don't use Abstract classes that often, but considering they
> are a foundation on which to build concrete classes (presumably to take
> care of many of the nitty gritty details and leave the concrete classes
> to implement specifics), I don't mind using a class suffix. "Abstract"
> feels like Hungarian notation, though.
>
> Based on my experiences writing code, I'm currently recommending that we
> do the following:
>
>  3. Use adjective/noun names for Interfaces such as "Foobarable",
>     "Foobarist"
>  7. Suffix abstract classes with "Base" ("FoobarableBase")
>
> The above solve most issues - names are reasonably sized, don't smack of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
> most importantly, meaningful. Since we already implement code review for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.
>
> Thoughts? Votes?
>
>   

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Date: Wed, 8 Apr 2009 08:13:00 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [zf-contributors] 1.8 Components Categories in JIRA

--_004_6B4A8009371807499638509271DEA796CC59256D62IMSCMAIL1imsc_
Content-Type: multipart/alternative;
	boundary="_000_6B4A8009371807499638509271DEA796CC59256D62IMSCMAIL1imsc_"

--_000_6B4A8009371807499638509271DEA796CC59256D62IMSCMAIL1imsc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am wondering when the new Component Categories will be created in JIRA fo=
r the new components in 1.8?

<http://zend.com/zce.php?c=3DZEND002524=
&r=3D219549271>

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]<mailto:[email-masked]>
P: (317) 492-8623 - F: (317) 492-6419

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

--_000_6B4A8009371807499638509271DEA796CC59256D62IMSCMAIL1imsc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Lucida Sans";
	panose-1:2 11 6 2 3 5 4 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal">I am wondering when the new Component Categories wil=
l be created in JIRA for the new components in 1.8?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<td width=3D"80" valign=3D"top" style=3D"width:60.0pt;padding:0in 0in 0in 0=
in">
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><a href=
=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><span style=
=3D"color:windowtext;text-decoration:none"><img border=3D"0" width=3D"73" h=
eight=3D"68" id=3D"Picture_x0020_1" src=3D"cid:[email-masked]=
60" alt=3D"php5_zce_logo_new"></span></a><span style=3D"font-size:12.0pt"><=
o:p></o:p></span></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Lu=
cida Sans&quot;,&quot;sans-serif&quot;">Jon Whitcraft<br>
Indianapolis Motor Speedway<br>
</span><span style=3D"font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><a href=3D"mailto:[email-masked]"><span style=3D=
"font-size:10.0pt;
  font-family:&quot;Lucida Sans&quot;,&quot;sans-serif&quot;;color:blue">jw=
[email-masked]</span></a><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span s=
tyle=3D"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-ser=
if&quot;">P: (317) 492-8623 - F: (317) 492-6419</span><span style=3D"font-s=
ize:9.0pt;font-family:
  &quot;Arial&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><br clear=3D"all">
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<br>
<font face=3D"Arial" color=3D"Gray" size=3D"1">********************<br>
********************<br>
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify
 the sender by reply E-mail and erase this E-mail from your system. Your as=
sistance is appreciated. E-mail transmission may not be secure or error-fre=
e. The company is not responsible for any loss/damage arising from any viru=
s transmitted.<br>
********************<br>
********************<br>
</font>
</body>
</html>

--_000_6B4A8009371807499638509271DEA796CC59256D62IMSCMAIL1imsc_--

--_004_6B4A8009371807499638509271DEA796CC59256D62IMSCMAIL1imsc_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=2553;
	creation-date="Wed, 08 Apr 2009 08:13:01 GMT";
	modification-date="Wed, 08 Apr 2009 08:13:01 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_004_6B4A8009371807499638509271DEA796CC59256D62IMSCMAIL1imsc_--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Vincent de Lau" <[email-masked]>
To: <[email-masked]>
Date: Tue, 19 May 2009 18:45:22 +0200
Subject: [zf-contributors] Zend_Html_Element

Hi all,

I'd like to point you all to this rather old proposal:

http://framework.zend.com/wiki/display/ZFPROP/Zend_Html+Proposal

As mentioned in the comments, I have a simpler class that represents a =
HTML (or XML) element. I find it very convenient for constructing HTML, =
especially when I need to change or add something later on in the =
application. The element can contain any type of data that can be =
converted to a string, which is being done in the __toString function. =
This allows late changes to contained elements.

I can imagine that for instance form elements and decorators can profit =
from such a programmatic approach. Adding a class name to the INPUT =
element can be done rather easy when having access to the HTML element. =
It also takes care of the proper output for HTML, XHTML and XML.

The interface in use so far is:

<?php
class Zend_Html_Element {
    public function __construct($name, $attributes =3D null, $content =
=3D null)

    // render the element and its content
    public function __toString()

    // access attributes
    public function set($attribute,$value)
    public function get($attribute)
    public function __set($attribute,$value)
    public function __get($attribute)

    // token based attributes like class (space separated values)
    public function addToken($name,$token)
    public function removeToken($name,$token)
    // addToken ('class',$value)
    public function addClass($value)

    // access content
    public function append($content)
    public function prepend($content)
    public function getContent()

    // access render mode (HTML/XHTML/XML)
    public static function setMode($mode)
    public static function getMode()
}

At this time, there is no knowledge of the DTD. There is only a list of =
empty HTML elements, for proper HTML and XHTML rendering. The other HTML =
specific thing is the addClass function.

My questions:
- Would such a component be considered useful?
- If this is being added, are there parts of the original proposal that =
people like to see?
- Would it be a good plan to rework Zend_Form to use this element? What =
would that mean for backward compatibility?

Thanks for reading!

Vincent de Lau
 [email-masked]

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Sun, 7 Feb 2010 01:22:39 +0100
To: Maghiel Dijksman <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] New Proposal: Change of
	ZendX_JQuery_View_Helper_AjaxLink 
	(ZendX_JQuery_View_Helper_AjaxRequest etc)

Hey Maghiel,

Proposals should be put in the wiki, and should then be announced on
the mailing lists (oh, and please do so in #zftalk.dev on freenode,
irc) as all described here:
http://framework.zend.com/wiki/display/ZFPROP/Proposal+Process

As to what the actual proposal is concerned, imho (note: that's just
an opinion) this is just a (slight) change in existing
behavior/functionality. Therefore I think you better contact the
maintainer of ZendX_Jquery (Benjamin Eberlei, aka Beberlei) for this
rather than actually putting an entire proposal out - which is usually
done for entire components.

Regards,

Dolf
-- Freeaqingme

On Sun, Feb 7, 2010 at 12:49 AM, Maghiel Dijksman <[email-masked]> wrote=
:
> This is my first idea for a proposal that i submit to the mailing list, s=
o
> pardon me if i take the wrong steps
> (and please correct me ;))
>
> I think it's a bit, ehm, weird that theres Zend_View_Helper_Url, which
> returns a url as string,
> and ZendX_JQuery_View_Helper_AjaxLink, which can only return a complete H=
TML
> hyperlink (although
> the naming DOES cleary state what you get).
>
> But what if a user wants to only have the JQuery function declaration
> returned as string, by example
> for usage in a onclick attribute of an element?
> ZendX_JQuery_View_Helper_AjaxLink has the inline option,
> but this makes the helper return a hyperlink with the function declared i=
n
> the onclick attribute of that hyperlink.
> So the only option the user has in my use case is to either create his/he=
r
> own view helper, or declare the function
> him/herself in the view.
>
> So I thought the following might be useful:
> Drop: ZendX_JQuery_View_Helper_AjaxLink
> Add:
> ZendX_JQuery_View_Helper_AjaxRequest_Abstract
> ZendX_JQuery_View_Helper_AjaxRequest (probably needs a better name :p)
> ZendX_JQuery_View_Helper_AjaxRequest_Link
>
> Something like:
> abstract class ZendX_JQuery_View_Helper_AjaxRequest_Abstract
> =C2=A0 =C2=A0extends Zend_View_Helper_HtmlElement
> {
> =C2=A0 =C2=A0protected $_jQuery;
> =C2=A0 =C2=A0protected $_jQHandler;
>
> =C2=A0 =C2=A0/**
> =C2=A0 =C2=A0 * Set JQuery view helper and JQuery Handler
> =C2=A0 =C2=A0 */
> =C2=A0 =C2=A0public function __construct()
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_jQuery =3D $this->view->jQuery();
> =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_jQuery->enable();
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_jQHandler =3D true =3D=3D=3D
> ZendX_JQuery_View_Helper_JQuery::getNoConflictMode() ? '$j' : '$';
> =C2=A0 =C2=A0}
>
> =C2=A0 =C2=A0/**
> =C2=A0 =C2=A0 * Get js string for the given effect (example: $this->_jQHa=
ndler .
> '(this).fadeOut();')
> =C2=A0 =C2=A0 *
> =C2=A0 =C2=A0 * @return string
> =C2=A0 =C2=A0 */
> =C2=A0 =C2=A0protected function getEffect()
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0}
>
> }
>
> class ZendX_JQuery_View_Helper_AjaxRequest extends
> ZendX_JQuery_View_Helper_AjaxRequest_Abstract
> {
>
> =C2=A0 =C2=A0/**
> =C2=A0 =C2=A0 * Create inline JQuery function that enables ajax-based req=
uests and
> handling of the response.
> =C2=A0 =C2=A0 * @see ZendX_JQuery_View_Helper_AjaxLink
> =C2=A0 =C2=A0 *
> =C2=A0 =C2=A0 * @param string url
> =C2=A0 =C2=A0 * @param array $options (optional)
> =C2=A0 =C2=A0 * @param array $params (optional)
> =C2=A0 =C2=A0 * @return string
> =C2=A0 =C2=A0 */
> =C2=A0 =C2=A0public function ajaxRequest($url, array $options =3D null, a=
rray $params =3D
> null)
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0}
>
> =C2=A0 =C2=A0/**
> =C2=A0 =C2=A0 * Determine which request method (GET or POST) should be us=
ed.
> =C2=A0 =C2=A0 *
> =C2=A0 =C2=A0 * Normally the request method is determined implicitly by t=
he rule,
> =C2=A0 =C2=A0 * if addiotional params are sent, POST, if not GET. You can=
 overwrite
> =C2=A0 =C2=A0 * this behaviiour by implicitly setting $options['method'] =
=3D "POST|GET";
> =C2=A0 =C2=A0 *
> =C2=A0 =C2=A0 * @param =C2=A0Array =C2=A0 $options
> =C2=A0 =C2=A0 * @param =C2=A0Boolean $hasParams
> =C2=A0 =C2=A0 * @return String
> =C2=A0 =C2=A0 */
> =C2=A0 =C2=A0protected function _determineRequestHandler($options, $hasPa=
rams)
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0}
>
> }
>
> class ZendX_JQuery_View_Helper_AjaxRequest_Link extends
> ZendX_JQuery_View_Helper_AjaxRequest
> {
>
> =C2=A0 =C2=A0private static $currentLinkCallbackId =3D 1;
>
> =C2=A0 =C2=A0public function ajaxLink($label, $url, $options=3Dnull, $par=
ams=3Dnull)
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0$js =3D parent::ajaxRequest($url, $options, $p=
arams);
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0// Etc
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return $js;
> =C2=A0 =C2=A0}
>
> =C2=A0 =C2=A0private function _getAttributes(array $attrib =3D array())
> =C2=A0 =C2=A0{
> =C2=A0 =C2=A0}
>
> }
>
>
>
> What do you guys think?
> If i'm coming up with a stupid proposal please flame me (although useful
> critics are more welcome ;))
>
> Regards,
> Maghiel
>

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 17 Jan 2010 13:51:32 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Serializer work

Thanks - I loosed sight of this tab

Am 17.01.2010 11:21, schrieb Menno Luiten:
> Don't think so; can't you just edit the issue, go to the tab called
> 'Internal Project Management Fields' and set Fix version/s from there?
>
> --Menno
>
> On zo, 2010-01-17 at 10:54 +0100, Julien Pauli wrote:
>   
>> Ok no problem for your patch ;-)
>>
>> (I think to change the status you have to re-open the issue, then
>> re-close it specifying a fix/version)
>>
>> J.Pauli
>>
>> On Sun, Jan 17, 2010 at 2:08 AM, Marc Bennewitz
>> <[email-masked]> wrote:
>>         Hi Julien,
>>         
>>         I changed ZF-8842 to use class_implements because on creating
>>         an
>>         instance you executes code on an unchecked class.
>>         
>>         I don't know how to change the "Fix/Version" on a closed
>>         issue.
>>         ZF-8842 is changed now because reopened.
>>         
>>         Marc
>>         
>>         Am 16.01.2010 23:52, schrieb Julien Pauli:
>>         
>>         > Hi,
>>         >
>>         > I recently commited 20343-20345-20346 for Zend_Serializer.
>>         > See http://framework.zend.com/issues/browse/ZF-8844 -
>>         > http://framework.zend.com/issues/browse/ZF-8842
>>         >
>>         > I forgot to set the "Fix/Version" to next minor (1.10) , how
>>         can I
>>         > edit that later ? Reopening the issue seems the only way
>>         right ?
>>         >
>>         > Anyway, tell me if something goes wrong with the patches
>>         (shouldn't) ;-)
>>         >
>>         > J.Pauli
>>         
>>
>>     
>
>
>   

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: Marc Bennewitz <[email-masked]>, "[email-masked]"
	<[email-masked]>
Date: Thu, 8 Oct 2009 14:20:20 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: RE: [zf-contributors] mailing list for contributors doesn't work on
	framework.zend.com

Marc,

I believe that is because this list is not archived.  I may be mistaken wit=
h that but Matthew or Ralph should know better than I.

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]
Phone: (317) 492-8623 :: Fax: (317) 492-6419

-----Original Message-----
From: Marc Bennewitz [mailto:[email-masked]]
Sent: Thursday, October 08, 2009 1:10 PM
To: [email-masked]
Subject: [zf-contributors] mailing list for contributors doesn't work on fr=
amework.zend.com

Hi,

The mailing list for contributors doesn't work:
http://framework.zend.com/archives/contributors

ERR:  An error occurred with this request: Action "contributors" does
not exist and was not trapped in __call().

The link is shown here:
http://framework.zend.com/wiki/display/ZFDEV/Contributing+to+Zend+Framework=
#ContributingtoZendFramework-mailinglists

All other mailing lists are working

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 20 Oct 2009 18:42:08 +0200
From: Marc Bennewitz <[email-masked]>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] JIRA Incubator Components Update

Hi P=E1draic

I'm not sure if Zend_Exception should add as a component but there are
changes on incubator.

P=E1draic Brady schrieb:
> The list I have is:
>=20
> Zend_Feed_Pubsubhubbub
> Zend_Cache_Manager
>=20
> Can I stop now? No? ;)
>=20
> Zend_Cache_Backend_Blackhole
> Zend_Amf
> Zend_Auth_Adapter_Cas
> Zend_Config_Writer
> Zend_Controller_Action_Helper_MultiPageForm
> Zend_Db_Mapper
> Zend_Entity
> Zend_Environment
> Zend_Form_Decorator_File
> Zend_Http_Client_Adapter_Curl
> Zend_Image
> Zend_Json_Server
> Zend_Markup
> Zend_Mime_Message
> Zend_Service_[LiveDocx|RememberTheMilk|TinyUrlCom|Gravatar|Tumblr|JdemC=
z]
> Zend_ShortUrl
> Zend_Validate_[CreditCard|EmailAddress|InArray|Isbn]
> Zend_View_Helper_Currency
>=20
> There are also a few files in the Zend directory but no matching name
> directory, e.g. Zend_Calendar.
>=20
> Not sure how fine-grained you want to get though, or even if all of
> these qualify. I'm not familiar with all of their activity/age. Also a
> few directories in the repository which are basically empty.
>=20
> Hope everyone's having a grand time at Zendcon while the rest of us
> analyse the Incubator :P.
> =20
> P=E1draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative <http://www.openideurope.=
eu/>
>=20
>=20
> -----------------------------------------------------------------------=
-
> *From:* Matthew Weier O'Phinney <[email-masked]>
> *To:* [email-masked]
> *Sent:* Mon, October 19, 2009 5:01:02 AM
> *Subject:* Re: [zf-contributors] JIRA Incubator Components Update
>=20
> -- P=E1draic Brady <[email-masked]
> <mailto:[email-masked]>> wrote
> (on Saturday, 17 October 2009, 06:15 AM -0700):
>> Just requesting that we add in the missing Incubator components to JIR=
A if
>> possible. At present we can't create issues for these.
>=20
> Can you refresh my memory as to which incubator components need to be
> added? I'll try and do so Tuesday, once I have a list.
>=20
>> Assuming everyone has recovered from fixing 100 issues during the bug
> hunt! :P
>=20
> Indeed! Awesome job, everyone! The final count for the official hunt wa=
s
> 95, and you can view the list here:
>=20
>   =20
> http://framework.zend.com/issues/secure/IssueNavigator.jspa?mode=3Dhide=
&requestId=3D11156
> <http://framework.zend.com/issues/secure/IssueNavigator.jspa?mode=3Dhid=
e&requestId=3D11156>
>=20
> I'll be announcing the winner on Tuesday -- but many thanks now to
> everyone who participated!
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead            | [email-masked] <mailto:[email-masked]>
> Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 07 Apr 2009 22:57:34 +0200
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] New Component proposal

You may probably ask Matthew or Wil about the password thingy.

Then, to your proposal:
There were some proposals for payment components, but mostly the just
included single payment methods, and did not cover multiple ones. We
discussed that a few times, and what we need is a component which offers
(if possible) a unified API for all payment providers. When you are
willing to do so, feel free to get on with your proposal, I will follow
it with interest.

Regards,
Ben
...................................
:  ___   _   ___ ___ ___ _ ___    :
: |   \ /_\ / __| _ \ _ (_)   \   :
: | |) / _ \\__ \  _/   / | |) |  :
: |___/_/:\_\___/_| |_|_\_|___/   :
:........:........................:
: Web    : http://www.dasprids.de :
: E-mail : [email-masked]       :
: Jabber : [email-masked]     :
: ICQ    : 105677955              :
:........:........................:

Vadim Gabriel schrieb:
> Hey,
> 
> I have never added a new proposal and searched the wiki about how to
> make those. I found this "Image" that displays the work flow of adding a
> new component, From opening a new proposal in the wiki upto getting it
> approved by the Zend Team.
> I have a few problems tough.
> 
> First i have lost my password, And now i can't access JIRA. I already
> signed the CLA, And would have reset my password, I just couldn't find
> the lost password feature anywhere. Do i need to ask someone to reset it
> for me?
> Second, Where and how do i start a new Wiki page about the component i
> would like to contribute. Do i need to add anything special like special
> information about it, Besides the usual description and technical
> specifications?
> Third, My component that i would like to share is Zend_Payments_Paypal
> class that allows to use paypal. This is the only thing i made so far by
> myself for Zend Framework but since i am working a lot with Ecommerce i
> will probably be writting more payment transfer options such as Google
> checkout, Moneybookers, 2checkout and more. I would like to know if this
> is something that might interest people and actually make it's way to
> the library rather then the archive?
> 
> Thanks, Vince.
> 
> -- 
> Vincent Gabriel.
> Lead Developer, Senior Support.
> Zend Certified Engineer.
> Zend Framework Certified Engineer.
> 
> 
> 
> 

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 08:22:39 +0100
From: =?UTF-8?B?0KHQsNGI0LAg0KHRgtCw0LzQtdC90LrQvtCy0LjRmw==?=
	<[email-masked]>
To: Guilherme Blanco <[email-masked]>
Cc: Robin Skoglund <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0016e6d7ed3080166b047827689d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Very nice!

What about Zend_Model? Will we have some official component for M in MVC, o=
r
we will stay on VC in zf 2.0?
Will Zend_Tool get more powerful, generating models from db scheme, unit
tests etc?

Regards,
Sa=C5=A1a Stamenkovi=C4=87

On Wed, Nov 11, 2009 at 9:37 PM, Guilherme Blanco <[email-masked]=
m
> wrote:

> http://groups.google.com/group/php-standards/web/final-proposal
>
> On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[email-masked]> wrote=
:
> > On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney <[email-masked]=
m>
> wrote:
> >>
> >> In looking at your above notes, I realize that there's another change
> >> that needs to be noted in the docs: targetting the PHP Interop Group's
> >> specifications. The Exception usage is in line with our current
> >> discussions, already. The package naming will work -- but the ideal is
> >> to ship package names as all lowercase. Any script for migration will
> >> need to take that into account as well.
> >
> > Do you have a link for the PHP Interop Group specifications? I was
> > about to make a comment in the wiki about the Exception usage, but I
> > guess I should read up on the mentioned docs first.
> >
>
>
>
> --
> Guilherme Blanco - Web Developer
> CBC - Certified Bindows Consultant
> Cell Phone: +55 (16) 9215-8480
> MSN: [email-masked]
> URL: http://blog.bisna.com
> S=C3=A3o Paulo - SP/Brazil
>

--0016e6d7ed3080166b047827689d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Very nice!<div><br></div><div>What about Zend_Model? Will we have some offi=
cial component for M in MVC, or we will stay on VC in zf 2.0?</div><div>Wil=
l Zend_Tool get more powerful, generating models from db scheme, unit tests=
 etc?<br>
<div><br>Regards,<br>Sa=C5=A1a Stamenkovi=C4=87<br>
<br><br><div class=3D"gmail_quote">On Wed, Nov 11, 2009 at 9:37 PM, Guilher=
me Blanco <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex;">
<a href=3D"http://groups.google.com/group/php-standards/web/final-proposal"=
 target=3D"_blank">http://groups.google.com/group/php-standards/web/final-p=
roposal</a><br>
<div><div></div><div class=3D"h5"><br>
On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund &lt;<a href=3D"mailto:robin=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; On Wed, Nov 11, 2009 at 20:40, Matthew Weier O&#39;Phinney &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; In looking at your above notes, I realize that there&#39;s another=
 change<br>
&gt;&gt; that needs to be noted in the docs: targetting the PHP Interop Gro=
up&#39;s<br>
&gt;&gt; specifications. The Exception usage is in line with our current<br=
&gt;&gt; discussions, already. The package naming will work -- but the idea=
l is<br>
&gt;&gt; to ship package names as all lowercase. Any script for migration w=
ill<br>
&gt;&gt; need to take that into account as well.<br>
&gt;<br>
&gt; Do you have a link for the PHP Interop Group specifications? I was<br>
&gt; about to make a comment in the wiki about the Exception usage, but I<b=
r>
&gt; guess I should read up on the mentioned docs first.<br>
&gt;<br>
<br>
<br>
<br>
</div></div><font color=3D"#888888">--<br>
Guilherme Blanco - Web Developer<br>
CBC - Certified Bindows Consultant<br>
Cell Phone: +55 (16) 9215-8480<br>
MSN: <a href=3D"mailto:[email-masked]">guilhermeblanco@hotmail=
.com</a><br>
URL: <a href=3D"http://blog.bisna.com" target=3D"_blank">http://blog.bisna.=
com</a><br>
S=C3=A3o Paulo - SP/Brazil<br>
</font></blockquote></div><br></div></div>

--0016e6d7ed3080166b047827689d--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 14 Nov 2009 13:32:14 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] I18N Webinar

-- Thomas Weidner <[email-masked]> wrote
(on Saturday, 14 November 2009, 05:59 PM +0100):
> Non of your points target translation.

Actually, I'd argue that points 1 and 3 *do* target translation. UTF-8
conversion is something that hampers some translation tasks, and setting
up a multi-lingual site in terms of language detection, routing, and IP
all affect the translations.

That said, it *is* your webinar, and I'll trust your judgment on how
much material you can cover! :)

Looking forward to catching this one!

> They will be talked about when we given an Localization talk (Zend_Loca=
le).
>=20
> For this webinar it would take too much time to focus also on this poin=
ts.
>=20
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>=20
> ----- Original Message ----- From: "P=E1draic Brady"
> <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>
> Cc: "Zend Framework Contributors" <[email-masked]>
> Sent: Saturday, November 14, 2009 5:24 PM
> Subject: Re: [zf-contributors] I18N Webinar
>=20
>=20
> Just a few suggestions based on common problems:
>=20
> 1. UTF8 conversion (still lots of people without a clue - judging by
> how my name is still not presented accurately on many sites).
> 2. Integer and Float normalisation across locales - particularly
> when commas/periods are both accepted through forms.
> 3. Basics of designing a multi-lingual site (language detection,
> routing solutions, IP region location).
>=20
> Paddy
>=20
>=20
> P=E1draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>=20
>=20
>=20
>=20
>=20
> ________________________________
> From: Thomas Weidner <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Sent: Sat, November 14, 2009 12:53:46 PM
> Subject: [zf-contributors] I18N Webinar
>=20
> Hy ZF interested community,
>=20
> I am preparing an webinar about I18N.
> This one will be a speak about Translation and all what's related to
> this task.
>=20
> So here comes your part:
> Which things do you want to know ?
> Which informations do you miss from manual or other sources ?
> What do you want to hear in this webinar ?
>=20
> Don't be shy and just reply :-)
>=20
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 01:31:04 -0500
From: Ralph Schindler <[email-masked]>
To: "Zend Framework Contributors" <[email-masked]>
Subject: [zf-contributors] Poll: 2.0 and Namespace impact of class names

Hey all-

One more to discuss for today ;)

On the Usage of Compound Names --

With namespaces, we have the opportunity to create aliases to specific 
namespace our code consumes.  For example, we can do something like this:

<?php
// in a script that consumes Zend Frameowrk
use Zend\Filter as f;

$filter = new f\Something.php

?>

In the past, with fully prefixed names, it was easy to understand the 
context of a particular class since the namespace is carried with it. 
$filter = new Zend_Filter_Int(); is clearly an Integer filter, and the 
class name fully reflects that.

The question with namespaces is, should we use compound names to 
identify classes separate of the namespace itself.  This can be better 
demonstrated with the following code:

<?php

use Zend\Filter as f;

$filter = new f\Int();

?>

-- VS --

<?php

use Zend\Filter as f;

$filter = new f\IntFilter();

?>

In the latter example, the original class name (without the prefix) 
might have been Int, but this class name has been 'suffixed' with a term 
that gives the class name more meaning.  (In english, this means that 
the class name now has the adjective 'Int' and the noun 'Filter', or a 
noun-noun combination).

Which is a better route to explore in your opinion? Which has more 
meaning to you as a developer consuming ZF?

As a technical side-note, this might be required for some prefixed names 
that reduce down into PHP reserved words, for example 
Zend_CodeGenerator_Php_Class cannot become namespace 
Zend\CodeGenerator\PHP class Class due to its restrictions on class naming.

Thoughts?
-ralph

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 08:39:15 -0800
From: Kevin McArthur <[email-masked]>
To: Diego Henrique Oliveira <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

The performance difference between a * and selected columns will be 
almost nil.... short of something like an unmaterialized and complex 
view [in the db sense] that is.

I'd think this would add a fair amount of complication to the api and 
codebase for what will be, for most people, practically zero benefit. 
In-fact, for most, the additional requirement of a couple method 
invocations and string operations will likely negate the effect of not 
returning the extraneous columns in the first place.

I'd vote no on this change.

Kevin

Diego Henrique Oliveira wrote:
> In the adapter DbTable, the generated query to the database is a 
> 'select *', and as it was being a bottleneck in my application (users 
> table with many fields), i made these changes in the component 
> Zend_Auth_Adapter_DbTable.
>
>
> class Zend_Auth_Adapter_DbTable
> {
>    
>     protected $_returnedFields;
>    
>     public function setReturnedFields( array $fields )
>     {
>         $this->_returnedFields = $fields;
>     }
>    
>     public function getReturnedFields()
>     {
>         if (is_null($this->_returnedFields))
>         {
>             return array('*');
>         }
>         return $this->_returnedFields;
>     }
>    
>     /**
>      * _authenticateCreateSelect() - This method creates a 
> Zend_Db_Select object that
>      * is completely configured to be queried against the database.
>      *
>      * @return Zend_Db_Select
>      */
>     protected function _authenticateCreateSelect()
>     {
>         // build credential expression
>         if (empty($this->_credentialTreatment) || 
> (strpos($this->_credentialTreatment, '?') === false)) {
>             $this->_credentialTreatment = '?';
>         }
>
>         $credentialExpression = new Zend_Db_Expr(
>             '(CASE WHEN ' .
>             $this->_zendDb->quoteInto(
>                 
> $this->_zendDb->quoteIdentifier($this->_credentialColumn, true)
>                 . ' = ' . $this->_credentialTreatment, $this->_credential
>                 )
>             . ' THEN 1 ELSE 0 END) AS '
>             . $this->_zendDb->quoteIdentifier(
>                 $this->_zendDb->foldCase('zend_auth_credential_match')
>                 )
>             );
>
>         // get select
>         $fields   = $this->getReturnedFields();
>         array_push( $fields, $credentialExpression );
>         $dbSelect = clone $this->getDbSelect();
>         $dbSelect->from($this->_tableName, $fields)
>                  
> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) 
> . ' = ?', $this->_identity);
>
>         return $dbSelect;
>     }
>    
> }
>
>
>
> What you guys think about these changes? And should I submit them to 
> the project?
>
>
> Cheers
>
> Diego
> http://diegoholiveira.com
>

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Robin Skoglund <[email-masked]>
Date: Fri, 10 Apr 2009 21:42:08 +0200
To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming 
	Conventions

--001636c5afb64f861e046738907b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Fri, Apr 10, 2009 at 20:24, Matthew Weier O'Phinney <[email-masked]>wrote:
>
>
>  * Use generic, descriptive names indicative of functionality or behavior.
> As
>   examples from the SPL, "Countable", "Iterator", "ArrayObject".
>

I agree that this is the best approach.

Will there be any guidelines on how to name classes which have all three
(interface, abstract, concrete) in the same namespace? Example: Zend_View::
* Zend_View_Interface ==> Zend\View\View? or Zend\View\IView?
* Zend_View_Abstract ==> Zend\View\ViewObject? or Zend\View\BasicView?
* Zend_View ==> Zend\View\View? or Zend\View\RunnableView?

I also notice that namespaces are written in Uppercase\Notation --
Zend\Controller\Request. Will this be the standard? Another alternative is
zend\controller\Request, which clearly distinguishes what's the namespace
and what's the class/interface.

        robinsk

--001636c5afb64f861e046738907b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 10, 2009 at 20:24, Matthew Weier O&#=
39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">matthe=
[email-masked]</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"=
border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddi=
ng-left: 1ex;">

<br>
=A0* Use generic, descriptive names indicative of functionality or behavior=
. As<br>
 =A0 examples from the SPL, &quot;Countable&quot;, &quot;Iterator&quot;, &q=
uot;ArrayObject&quot;.<font color=3D"#888888"><br>
</font></blockquote></div><br>I agree that this is the best approach.<br><b=
r>Will there be any guidelines on how to name classes which have all three =
(interface, abstract, concrete) in the same namespace? Example: Zend_View::=
<br>

* Zend_View_Interface =3D=3D&gt; Zend\View\View? or Zend\View\IView?<br>* Z=
end_View_Abstract =3D=3D&gt; Zend\View\ViewObject? or Zend\View\BasicView?<=
br>* Zend_View =3D=3D&gt; Zend\View\View? or Zend\View\RunnableView?<br><br=
>I also notice that namespaces are written in Uppercase\Notation -- Zend\Co=
ntroller\Request. Will this be the standard? Another alternative is zend\co=
ntroller\Request, which clearly distinguishes what&#39;s the namespace and =
what&#39;s the class/interface.<br>

<br>=A0=A0=A0=A0=A0=A0=A0 robinsk<br>

--001636c5afb64f861e046738907b--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Tue, 12 Jan 2010 14:42:15 +0100
Subject: Re: [zf-contributors] PHP error in framework docs search results.

On Tuesday 12 January 2010 14:14:00 Matthew Weier O'Phinney wrote:
>Regarding the undefined offset notices, I'll be discussing these with
>Alex, as they're indicative of potential issues in the Lucene component.

Please disregard my last email for the moment, I have spotted another 
potential local issue.

nFrom nobody Wed Apr  7 08:46:11 2010
Date: Tue, 8 Dec 2009 05:02:04 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>

--0-1199419319-1260277324=:54407
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Matthew,=0A=0A>Paddy --=0A>=0A>A few things. First, strip_tags and ZF's =
StripTags should _not_ be=0A>equated with XSS protection. The fact that peo=
ple do indicates to me a=0A>documentation and education problem, not necess=
arily a bona-fide=0A>security issue -- which would mean that the code _intr=
oduces_ a security=0A>issue.=0A=0AZend_Filter_StripTags operates by filteri=
ng HTML (or XML) and removing all tags and attributes that are not containe=
d on a whitelist. Tags or attributes on the whitelist are not filtered, i.e=
. the tags are allowed to remain. The only reason to allow some tags is tha=
t the end-user needs them for either additional processing or direct unesca=
ped output. This behaviour is one definition of an HTML oriented XSS filter=
. That it is an incomplete/broken XSS filter is irrelevant - there is a rea=
sonable expectation that the class does prevent XSS.=0A=0A>I do want to cla=
rify something: the issue reported earlier this year was=0A>not so much abo=
ut filtering XSS attacks, but about the fact that due to how=0A>attributes =
were matched, it _introduced_ an XSS attack vector. Because=0A>the regex di=
d not take into account newlines, it was possible to break=0A>an attribute =
value onto multiple lines to prevent it being matched --=0A>which provided =
the attack vector, as attributes not in the whitelist=0A>would be retained =
in the final filtered tag.=0A=0AIf the class worked, it would have filtered=
 out such XSS vectors. It's design and execution was (still is) deeply flaw=
ed.=0A=0A>This is very different from what you describe in your post and th=
is=0A>email. These are principally XSS vectors _within_ the attribute value=
s=0A>themselves -- i.e., the code is behaving as intended, and not=0A>intro=
ducing _new_ attack vectors through mishandling. Quite simply,=0A>StripTags=
 was never designed to strip XSS vectors in the first place.=0A=0AI describ=
ed a case where Zend_Filter_StripTags filtered no tags or attributes. This =
is not very different. The other case was different - it relied on insertin=
g a self-contained data URI which is valid HTML. =0A=0A>I do see your point=
 regarding the "setCommentsAllowed" functionality; it=0A>is, quite simply, =
a bad idea, as there is no semantic or structural=0A>value to keeping comme=
nts; sure, you could use them for conditional=0A>output, but that's a syste=
m ripe for abuse. I'm not entirely sure why=0A>this functionality was added=
 in the first place, and agree with you that=0A>it should be removed.=0A=0A=
Agreed.=0A=0A>So, with these points made, I'd like to ask how we should pro=
ceed? I=0A>think it's a bit alarmist to state that the filter should be imm=
ediately=0A>deprecated and removed ASAP. It does exactly as advertised -- a=
nd its=0A>documentation mentions nothing about protection from XSS.=0A=0AIt=
s documentation is non-existent. Its design clearly demonstrates its functi=
on is to selectively allow some HTML which meets a design goal of any XSS f=
ilter for HTML. The only conclusion that makes sense is that it is a partia=
l XSS filter. Your own Zend Framework Certification Guide provides an examp=
le of this exact use case. Why this is problematic is understandable - it t=
ook me almost two days to reach this conclusion myself. But it is a reasona=
ble conclusion.=0A=0A>May I suggest the following:=0A>=0A>* ZF-8483 and ZF-=
8484 should be resolved ASAP=0A>=0A>* As part of ZF-8484, which calls for b=
etter documenting the use cases=0A>  for StripTags, include a <warning> sec=
tion clearly stating that it is=0A>  not intended for XSS prevention=0A=0AI=
t is intended to prevent XSS. This is how it was designed, and how it is cu=
rrently being used in the wild. A simple documentation fix to deny the natu=
re of the class' design is insufficient.=0A=0A>* Create an HtmlPurifier fil=
ter that proxies to PEAR's HTML_Purifier=0A>  package; this would be includ=
ed in an upcoming release.=0A=0AThe PEAR repository contains no such packag=
e. I will assume you meant HTMLPurifier available from http://www.htmlpurif=
ier.org. This has been proposed by Thomas Weidner.=0A=0A>* Remove the setCo=
mmentsAllowed() functionality (by having it throw an=0A>  exception indicat=
ing the security vulnerabilities it opens)=0A=0AAgreed.=0A=0A>Finally, a re=
quest: in the future, when reporting suspected security=0A>vulnerabilities,=
 it's customary to notify the project _privately_ and=0A>allow some time fo=
r the project to address the vulnerability before=0A>making it public.=0A=
=0AThe public discussion started late Saturday when I wrote a blog post con=
cerning the end-user misuse of the class. The blog post did not refer to an=
y security vulnerabilities, and contained three separate and distinct clari=
fications that the Zend_Filter_StripTags class was not at fault.=0A=0AThis =
does not constitute an inappropriate public disclosure.=0A=0ADuring late Su=
nday and Monday, the debate on the issues was garnering divided opinions. I=
t was becoming clear that the class was interpreted as an XSS filter in the=
 wild. Once that interpretation was accounted for, the original blog post d=
id indeed appear to be an unwitting public disclosure. It took time for me =
to become fully convinced of that interpretation. Then I posted here.=0A=0A=
>As it is, you've created a very large, public=0A>discussion that will make=
 the project seem (a) reactionary, instead of=0A>proactive, and (b) paint u=
s as completely non-security minded. This is=0A>particularly bad in this si=
tuation, as, unless there's more to report,=0A>the primary issue here is on=
e of documentation and education, not actual=0A>vulnerabilities in the code=
 (with the exception of setCommentsAllowed()=0A>-- which isn't a vulnerabil=
ity per-se, but an ill-guided idea from the=0A>outset).=0A=0AThe Zend Frame=
work is the very definition of reactionary. This is not a proactive project=
 on security issues. If you wish to cultivate a different public image then=
 you may do so by actually earning it. You make the mistake of assuming I a=
m somehow supposed to be concerned with the project's public image. It's an=
 open source project, not a political party. At a technical level, security=
 in this area is appaling. We are the only major PHP5 framework without a w=
orking HTML XSS filter. If that is "proactive", I must need a new dictionar=
y.=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahtt=
p://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Representati=
ve=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Matthew Weier =
O'Phinney <[email-masked]>=0ATo: [email-masked]=0ASent: M=
on, December 7, 2009 3:46:19 PM=0ASubject: Re: [zf-contributors] XSS And Ma=
lformed HTML Vulnerabilities In Zend_Filter_StripTags=0A=0A-- P=E1draic Bra=
dy <[email-masked]> wrote=0A(on Monday, 07 December 2009, 06:26 AM=
 -0800):=0A> As some of you are probably aware, I wrote a blog over the wee=
kend titled=0A> "Zend_Filter_StripTags: Friend, Foe, or Security Nightmare?=
" (http://=0A> blog.astrumfutura.com/archives/=0A> 425-Zend_Filter_StripTag=
s-Friend,-Foe,-or-Security-Nightmare.html). The post=0A> was intended to ex=
pose the consequences of using the StripTags filter to clean=0A> HTML befor=
e it was directly output in the View without the application of=0A> escapin=
g. This is common in situations where user input is intended to allow=0A> s=
ome HTML, e.g. a comment form, or where an external data source contains HT=
ML=0A> intended for direct output, e.g. RSS and Atom feeds.=0A=0APaddy --=
=0A=0AA few things. First, strip_tags and ZF's StripTags should _not_ be=0A=
equated with XSS protection. The fact that people do indicates to me a=0Ado=
cumentation and education problem, not necessarily a bona-fide=0Asecurity i=
ssue -- which would mean that the code _introduces_ a security=0Aissue.=0A=
=0AI do want to clarify something: the issue reported earlier this year was=
=0Anot so much about filtering XSS attacks, but about the fact that due to =
how=0Aattributes were matched, it _introduced_ an XSS attack vector. Becaus=
e=0Athe regex did not take into account newlines, it was possible to break=
=0Aan attribute value onto multiple lines to prevent it being matched --=0A=
which provided the attack vector, as attributes not in the whitelist=0Awoul=
d be retained in the final filtered tag. =0A=0AThis is very different from =
what you describe in your post and this=0Aemail. These are principally XSS =
vectors _within_ the attribute values=0Athemselves -- i.e., the code is beh=
aving as intended, and not=0Aintroducing _new_ attack vectors through misha=
ndling. Quite simply,=0AStripTags was never designed to strip XSS vectors i=
n the first place. =0A=0AI do see your point regarding the "setCommentsAllo=
wed" functionality; it=0Ais, quite simply, a bad idea, as there is no seman=
tic or structural=0Avalue to keeping comments; sure, you could use them for=
 conditional=0Aoutput, but that's a system ripe for abuse. I'm not entirely=
 sure why=0Athis functionality was added in the first place, and agree with=
 you that=0Ait should be removed.=0A=0ASo, with these points made, I'd like=
 to ask how we should proceed? I=0Athink it's a bit alarmist to state that =
the filter should be immediately=0Adeprecated and removed ASAP. It does exa=
ctly as advertised -- and its=0Adocumentation mentions nothing about protec=
tion from XSS.=0A=0AMay I suggest the following:=0A=0A* ZF-8483 and ZF-8484=
 should be resolved ASAP=0A=0A* As part of ZF-8484, which calls for better =
documenting the use cases=0A   for StripTags, include a <warning> section c=
learly stating that it is=0A   not intended for XSS prevention=0A=0A* Creat=
e an HtmlPurifier filter that proxies to PEAR's HTML_Purifier=0A   package;=
 this would be included in an upcoming release.=0A=0A* Remove the setCommen=
tsAllowed() functionality (by having it throw an=0A   exception indicating =
the security vulnerabilities it opens)=0A=0AFinally, a request: in the futu=
re, when reporting suspected security=0Avulnerabilities, it's customary to =
notify the project _privately_ and=0Aallow some time for the project to add=
ress the vulnerability before=0Amaking it public. As it is, you've created =
a very large, public=0Adiscussion that will make the project seem (a) react=
ionary, instead of=0Aproactive, and (b) paint us as completely non-security=
 minded. This is=0Aparticularly bad in this situation, as, unless there's m=
ore to report,=0Athe primary issue here is one of documentation and educati=
on, not actual=0Avulnerabilities in the code (with the exception of setComm=
entsAllowed()=0A-- which isn't a vulnerability per-se, but an ill-guided id=
ea from the=0Aoutset).=0A=0A> In the post I offered three examples: a bug i=
n allowing HTML, a method of=0A> injecting malformed HTML capable of impact=
ing a site's layout, and a=0A> "self-contained" XSS vector using a data URI=
. I clarified the alarmist tone of=0A> the entry by explaining these "vulne=
rabilities" are the result of end-user=0A> misuse of the filter, i.e. the f=
ilter largely does as it is designed to and not=0A> one iota more.=0A> =0A>=
 After discussing this with others and my colleagues, I've been asked to ra=
ise=0A> this with ZF developers for immediate attention as a confirmed secu=
rity=0A> vulnerability with multiple vectors based on the following:=0A> =
=0A> 1. The filter allows for HTML exceptions to the filter-all default ind=
icating=0A> it was originally designed to safely filter HTML for direct out=
put.=0A> 2. The Zend Framework Certification Guide implies that the StripTa=
gs filter is=0A> an anti-XSS filter.=0A> 3. Miscellaneous websites claim th=
e StripTags filter prevents XSS, use it in=0A> this role, or offer advice i=
ncorporating dangerous configuration variations=0A> (e.g. allowed a set of =
attributes for ALL allowed tags) raising an expectation=0A> that it fulfils=
 this role.=0A> 4. In March 2009, a bug in matching tags led to the reporti=
ng of an XSS=0A> vulnerability in the StripTags filter requiring a new ZF v=
ersion and backports=0A> confirming XSS as a developer concern in the filte=
r.=0A> 5. The component appears to behave in a near-identical fashion to PH=
P's=0A> strip_tags which has an impact on the integrity of non-HTML input (=
e.g.=0A> deleting input after certain characters).=0A> =0A> There are curre=
ntly two related issues added to the issue tracker:=0A> =0A> ZF-8483: http:=
//framework.zend.com/issues/browse/ZF-8483=0A> ZF-8484: http://framework.ze=
nd.com/issues/browse/ZF-8484=0A> =0A> For myself, I was surprised by the ig=
norance I faced after the blog post. There=0A> have been suggestions raised=
 about patching the filter, replacing it with a=0A> reworked robust version=
, to the extreme of suggesting I overreacted. One=0A> individual suggested =
my XSS exploit was unrealistic, so I decided to make a=0A> point by exposin=
g another XSS exploit coupled with an obvious bug which doesn't=0A> need a =
fancy URI anyone can interpret as some kind of minimal concern.=0A> =0A> $f=
ilter =3D new Zend_Filter_StripTags;=0A> $filter->setCommentsAllowed(true);=
=0A> $html =3D "<!--[if gte IE 4]><SCRIPT>alert('XSS');</SCRIPT><![endif]--=
>";=0A> $out =3D $filter->filter($html);=0A> =0A> Output: <!--[if gte IE 4]=
><SCRIPT>alert('XSS');</SCRIPT><![endif]-->=0A> =0A> So much for stripping =
tags... The StripTags filter does not have so much as a=0A> cursory underst=
anding of the real world. Allowing comments allows for almost=0A> anything =
applicable to XSS on IE.=0A> =0A> So I disagree with all of these folk. The=
re appears to be an appreciable and=0A> real expectation that the StripTags=
 filter prevents XSS - a cursory search of=0A> Google provides examples of =
people suggesting its use which indicates it is=0A> used as such. I'm also =
fast forming the opinion that a lot of PHP developers=0A> are clueless abou=
t XSS out there (that probably shouldn't be a surprise to me)=0A> and we ne=
ed to do something about it besides wave our hands and leaving this=0A> mon=
strosity in the source code intact.=0A> =0A> Thomas Weidner has started the=
 ball rolling by proposing a Zend_Filter_Html=0A> component (http://framewo=
rk.zend.com/wiki/display/ZFPROP/=0A> Zend_Filter_Html+-+Thomas+Weidner) whi=
ch will be a wrapper around the=0A> HTMLPurifier 4.0 (http://www.htmlpurifi=
er.org) library. I support this=0A> unreservedly since I and others have be=
en using custom filters of this nature=0A> for years.=0A> =0A> I would also=
 suggest the following:=0A> =0A> a) Rework the filter's current four lines =
of documentation (http://=0A> framework.zend.com/manual/en/zend.filter.set.=
html#zend.filter.set.striptags) to=0A> cover the component in greater detai=
l clarifying its use cases, potential for=0A> misuse, and clarifying it is =
not XSS  or malformed HTML safe.=0A> b) Immediately deprecate in 1.9 branch=
 (and remove in 2.0 - preferably 1.10=0A> given its significance) its abili=
ty to flexibly allow some HTML/comments thus=0A> preserving its only truly =
worthwhile feature - stripping ALL HTML.=0A> c) Do this ASAP.=0A> =0A> It s=
hould be highlighted that the StripTags filter cannot be "fixed". It simply=
=0A> has little capacity to prevent XSS and is based on rudimentary regular=
=0A> expression matching which is has absolutely no place in preventing XSS=
. The=0A> filter simply must never ever be used in any role involving the s=
afe filtering=0A> of HTML.=0A> =0A> Paddy=0A>  =0A> P draic Brady=0A> =0A> =
http://blog.astrumfutura.com=0A> http://www.survivethedeepend.com=0A> OpenI=
D Europe Foundation Irish Representative=0A> =0A=0A-- =0AMatthew Weier O'Ph=
inney=0AProject Lead            | [email-masked]=0AZend Framework        =
  | http://framework.zend.com/=0A
--0-1199419319-1260277324=:54407
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Hi Matthew,<br><br>&gt;Paddy --<br>&gt;<br>&gt;A few things. F=
irst, strip_tags and ZF's StripTags should _not_ be<br>&gt;equated with XSS=
 protection. The fact that people do indicates to me a<br>&gt;documentation=
 and education problem, not necessarily a bona-fide<br>&gt;security issue -=
- which would mean that the code _introduces_ a security<br>&gt;issue.<br><=
br>Zend_Filter_StripTags operates by filtering HTML (or XML) and removing a=
ll tags and attributes that are not contained on a whitelist. Tags or attri=
butes on the whitelist are not filtered, i.e. the tags are allowed to remai=
n. The only reason to allow some tags is that the end-user needs them for e=
ither additional processing or direct unescaped output. This behaviour is o=
ne definition of an HTML oriented XSS filter. That it is an
 incomplete/broken XSS filter is irrelevant - there is a reasonable expecta=
tion that the class does prevent XSS.<br><br>&gt;I do want to clarify somet=
hing: the issue reported earlier this year was<br>&gt;not so much about fil=
tering XSS attacks, but about the fact that due to how<br>&gt;attributes we=
re matched, it _introduced_ an XSS attack vector. Because<br>&gt;the regex =
did not take into account newlines, it was possible to break<br>&gt;an attr=
ibute value onto multiple lines to prevent it being matched --<br>&gt;which=
 provided the attack vector, as attributes not in the whitelist<br>&gt;woul=
d be retained in the final filtered tag.<br><br>If the class worked, it wou=
ld have filtered out such XSS vectors. It's design and execution was (still=
 is) deeply flawed.<br><br>&gt;This is very different from what you describ=
e in your post and this<br>&gt;email. These are principally XSS vectors _wi=
thin_ the attribute values<br>&gt;themselves -- i.e., the code is
 behaving as intended, and not<br>&gt;introducing _new_ attack vectors thro=
ugh mishandling. Quite simply,<br>&gt;StripTags was never designed to strip=
 XSS vectors in the first place.<br><br>I described a case where Zend_Filte=
r_StripTags filtered no tags or attributes. This is not very different. The=
 other case was different - it relied on inserting a self-contained data UR=
I which is valid HTML. <br><br>&gt;I do see your point regarding the "setCo=
mmentsAllowed" functionality; it<br>&gt;is, quite simply, a bad idea, as th=
ere is no semantic or structural<br>&gt;value to keeping comments; sure, yo=
u could use them for conditional<br>&gt;output, but that's a system ripe fo=
r abuse. I'm not entirely sure why<br>&gt;this functionality was added in t=
he first place, and agree with you that<br>&gt;it should be removed.<br><br=
>Agreed.<br><br>&gt;So, with these points made, I'd like to ask how we shou=
ld proceed? I<br>&gt;think it's a bit alarmist to state that the
 filter should be immediately<br>&gt;deprecated and removed ASAP. It does e=
xactly as advertised -- and its<br>&gt;documentation mentions nothing about=
 protection from XSS.<br><br>Its documentation is non-existent. Its design =
clearly demonstrates its function is to selectively allow some HTML which m=
eets a design goal of any XSS filter for HTML. The only conclusion that mak=
es sense is that it is a partial XSS filter. Your own Zend Framework Certif=
ication Guide provides an example of this exact use case. Why this is probl=
ematic is understandable - it took me almost two days to reach this conclus=
ion myself. But it is a reasonable conclusion.<br><br>&gt;May I suggest the=
 following:<br>&gt;<br>&gt;* ZF-8483 and ZF-8484 should be resolved ASAP<br=
>&gt;<br>&gt;* As part of ZF-8484, which calls for better documenting the u=
se cases<br>&gt;&nbsp; for StripTags, include a &lt;warning&gt; section cle=
arly stating that it is<br>&gt;&nbsp; not intended for XSS
 prevention<br><br>It is intended to prevent XSS. This is how it was design=
ed, and how it is currently being used in the wild. A simple documentation =
fix to deny the nature of the class' design is insufficient.<br><br>&gt;* C=
reate an HtmlPurifier filter that proxies to PEAR's HTML_Purifier<br>&gt;&n=
bsp; package; this would be included in an upcoming release.<br><br><span>T=
he PEAR repository contains no such package. I will assume you meant HTMLPu=
rifier available from <a target=3D"_blank" href=3D"http://www.htmlpurifier.=
org">http://www.htmlpurifier.org</a>. This has been proposed by Thomas Weid=
ner.</span><br><br>&gt;* Remove the setCommentsAllowed() functionality (by =
having it throw an<br>&gt;&nbsp; exception indicating the security vulnerab=
ilities it opens)<br><br>Agreed.<br><br>&gt;Finally, a request: in the futu=
re, when reporting suspected security<br>&gt;vulnerabilities, it's customar=
y to notify the project _privately_ and<br>&gt;allow some time for the
 project to address the vulnerability before<br>&gt;making it public.<br><b=
r>The public discussion started late Saturday when I wrote a blog post conc=
erning the end-user misuse of the class. The blog post did not refer to any=
 security vulnerabilities, and contained three separate and distinct clarif=
ications that the Zend_Filter_StripTags class was not at fault.<br><br>This=
 does not constitute an inappropriate public disclosure.<br><br>During late=
 Sunday and Monday, the debate on the issues was garnering divided opinions=
. It was becoming clear that the class was interpreted as an XSS filter in =
the wild. Once that interpretation was accounted for, the original blog pos=
t did indeed appear to be an unwitting public disclosure. It took time for =
me to become fully convinced of that interpretation. Then I posted here.<br=
><br>&gt;As it is, you've created a very large, public<br>&gt;discussion th=
at will make the project seem (a) reactionary, instead
 of<br>&gt;proactive, and (b) paint us as completely non-security minded. T=
his is<br>&gt;particularly bad in this situation, as, unless there's more t=
o report,<br>&gt;the primary issue here is one of documentation and educati=
on, not actual<br>&gt;vulnerabilities in the code (with the exception of se=
tCommentsAllowed()<br>&gt;-- which isn't a vulnerability per-se, but an ill=
-guided idea from the<br>&gt;outset).<br><br>The Zend Framework is the very=
 definition of reactionary. This is not a proactive project on security iss=
ues. If you wish to cultivate a different public image then you may do so b=
y actually earning it. You make the mistake of assuming I am somehow suppos=
ed to be concerned with the project's public image. It's an open source pro=
ject, not a political party. At a technical level, security in this area is=
 appaling. We are the only major PHP5 framework without a working HTML XSS =
filter. If that is "proactive", I must need a new
 dictionary.<br><br>Paddy<br><div>&nbsp;</div><span style=3D"color: rgb(0, =
0, 191);"><font style=3D"font-family: times new roman,new york,times,serif;=
" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></sp=
an></font><span style=3D"font-style: italic;"><font style=3D"font-family: t=
imes new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=
=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.=
com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survive=
thedeepend.com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow"=
 target=3D"_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Found=
ation Irish Representative</a><br></font></span></span><div><br></div><div =
style=3D"font-family: times new roman,new york,times,serif; font-size: 12pt=
;"><br><div style=3D"font-family: tahoma,new york,times,serif; font-size: 8=
pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font=
-weight: bold;">From:</span></b>
 Matthew Weier O'Phinney &lt;[email-masked]&gt;<br><b><span style=3D"font=
-weight: bold;">To:</span></b> [email-masked]<br><b><span s=
tyle=3D"font-weight: bold;">Sent:</span></b> Mon, December 7, 2009 3:46:19 =
PM<br><b><span style=3D"font-weight: bold;">Subject:</span></b> Re: [zf-con=
tributors] XSS And Malformed HTML Vulnerabilities In Zend_Filter_StripTags<=
br></font><br>=0A-- P=E1draic Brady &lt;<a ymailto=3D"mailto:padraic.brady@=
yahoo.com" href=3D"mailto:[email-masked]">[email-masked]<=
/a>&gt; wrote<br>(on Monday, 07 December 2009, 06:26 AM -0800):<br>&gt; As =
some of you are probably aware, I wrote a blog over the weekend titled<br>&=
gt; "Zend_Filter_StripTags: Friend, Foe, or Security Nightmare?" (http://<b=
r>&gt; <a target=3D"_blank" href=3D"http://blog.astrumfutura.com/archives/"=
>blog.astrumfutura.com/archives/</a><br>&gt; 425-Zend_Filter_StripTags-Frie=
nd,-Foe,-or-Security-Nightmare.html). The post<br>&gt; was intended to expo=
se the consequences of using the StripTags filter to clean<br>&gt; HTML bef=
ore it was directly output in the View without the application of<br>&gt; e=
scaping. This is common in situations where user input is intended to allow=
<br>&gt; some HTML, e.g. a comment form, or where an external data source c=
ontains HTML<br>&gt; intended for direct output, e.g. RSS and Atom feeds.<b=
r><br>Paddy
 --<br><br>A few things. First, strip_tags and ZF's StripTags should _not_ =
be<br>equated with XSS protection. The fact that people do indicates to me =
a<br>documentation and education problem, not necessarily a bona-fide<br>se=
curity issue -- which would mean that the code _introduces_ a security<br>i=
ssue.<br><br>I do want to clarify something: the issue reported earlier thi=
s year was<br>not so much about filtering XSS attacks, but about the fact t=
hat due to how<br>attributes were matched, it _introduced_ an XSS attack ve=
ctor. Because<br>the regex did not take into account newlines, it was possi=
ble to break<br>an attribute value onto multiple lines to prevent it being =
matched --<br>which provided the attack vector, as attributes not in the wh=
itelist<br>would be retained in the final filtered tag. <br><br>This is ver=
y different from what you describe in your post and this<br>email. These ar=
e principally XSS vectors _within_ the attribute
 values<br>themselves -- i.e., the code is behaving as intended, and not<br=
>introducing _new_ attack vectors through mishandling. Quite simply,<br>Str=
ipTags was never designed to strip XSS vectors in the first place. <br><br>=
I do see your point regarding the "setCommentsAllowed" functionality; it<br=
>is, quite simply, a bad idea, as there is no semantic or structural<br>val=
ue to keeping comments; sure, you could use them for conditional<br>output,=
 but that's a system ripe for abuse. I'm not entirely sure why<br>this func=
tionality was added in the first place, and agree with you that<br>it shoul=
d be removed.<br><br>So, with these points made, I'd like to ask how we sho=
uld proceed? I<br>think it's a bit alarmist to state that the filter should=
 be immediately<br>deprecated and removed ASAP. It does exactly as advertis=
ed -- and its<br>documentation mentions nothing about protection from XSS.<=
br><br>May I suggest the following:<br><br> * ZF-8483 and ZF-8484
 should be resolved ASAP<br><br> * As part of ZF-8484, which calls for bett=
er documenting the use cases<br>&nbsp;  for StripTags, include a &lt;warnin=
g&gt; section clearly stating that it is<br>&nbsp;  not intended for XSS pr=
evention<br><br> * Create an HtmlPurifier filter that proxies to PEAR's HTM=
L_Purifier<br>&nbsp;  package; this would be included in an upcoming releas=
e.<br><br> * Remove the setCommentsAllowed() functionality (by having it th=
row an<br>&nbsp;  exception indicating the security vulnerabilities it open=
s)<br><br>Finally, a request: in the future, when reporting suspected secur=
ity<br>vulnerabilities, it's customary to notify the project _privately_ an=
d<br>allow some time for the project to address the vulnerability before<br=
>making it public. As it is, you've created a very large, public<br>discuss=
ion that will make the project seem (a) reactionary, instead of<br>proactiv=
e, and (b) paint us as completely non-security minded. This
 is<br>particularly bad in this situation, as, unless there's more to repor=
t,<br>the primary issue here is one of documentation and education, not act=
ual<br>vulnerabilities in the code (with the exception of setCommentsAllowe=
d()<br>-- which isn't a vulnerability per-se, but an ill-guided idea from t=
he<br>outset).<br><br>&gt; In the post I offered three examples: a bug in a=
llowing HTML, a method of<br>&gt; injecting malformed HTML capable of impac=
ting a site's layout, and a<br>&gt; "self-contained" XSS vector using a dat=
a URI. I clarified the alarmist tone of<br>&gt; the entry by explaining the=
se "vulnerabilities" are the result of end-user<br>&gt; misuse of the filte=
r, i.e. the filter largely does as it is designed to and not<br>&gt; one io=
ta more.<br>&gt; <br>&gt; After discussing this with others and my colleagu=
es, I've been asked to raise<br>&gt; this with ZF developers for immediate =
attention as a confirmed security<br>&gt; vulnerability with
 multiple vectors based on the following:<br>&gt; <br>&gt; 1. The filter al=
lows for HTML exceptions to the filter-all default indicating<br>&gt; it wa=
s originally designed to safely filter HTML for direct output.<br>&gt; 2. T=
he Zend Framework Certification Guide implies that the StripTags filter is<=
br>&gt; an anti-XSS filter.<br>&gt; 3. Miscellaneous websites claim the Str=
ipTags filter prevents XSS, use it in<br>&gt; this role, or offer advice in=
corporating dangerous configuration variations<br>&gt; (e.g. allowed a set =
of attributes for ALL allowed tags) raising an expectation<br>&gt; that it =
fulfils this role.<br>&gt; 4. In March 2009, a bug in matching tags led to =
the reporting of an XSS<br>&gt; vulnerability in the StripTags filter requi=
ring a new ZF version and backports<br>&gt; confirming XSS as a developer c=
oncern in the filter.<br>&gt; 5. The component appears to behave in a near-=
identical fashion to PHP's<br>&gt; strip_tags which has an impact on
 the integrity of non-HTML input (e.g.<br>&gt; deleting input after certain=
 characters).<br>&gt; <br>&gt; There are currently two related issues added=
 to the issue tracker:<br>&gt; <br><span>&gt; ZF-8483: <a target=3D"_blank"=
 href=3D"http://framework.zend.com/issues/browse/ZF-8483">http://framework.=
zend.com/issues/browse/ZF-8483</a></span><br><span>&gt; ZF-8484: <a target=
=3D"_blank" href=3D"http://framework.zend.com/issues/browse/ZF-8484">http:/=
/framework.zend.com/issues/browse/ZF-8484</a></span><br>&gt; <br>&gt; For m=
yself, I was surprised by the ignorance I faced after the blog post. There<=
br>&gt; have been suggestions raised about patching the filter, replacing i=
t with a<br>&gt; reworked robust version, to the extreme of suggesting I ov=
erreacted. One<br>&gt; individual suggested my XSS exploit was unrealistic,=
 so I decided to make a<br>&gt; point by exposing another XSS exploit coupl=
ed with an obvious bug which doesn't<br>&gt; need a fancy URI anyone can
 interpret as some kind of minimal concern.<br>&gt; <br>&gt; $filter =3D ne=
w Zend_Filter_StripTags;<br>&gt; $filter-&gt;setCommentsAllowed(true);<br>&=
gt; $html =3D "&lt;!--[if gte IE 4]&gt;&lt;SCRIPT&gt;alert('XSS');&lt;/SCRI=
PT&gt;&lt;![endif]--&gt;";<br>&gt; $out =3D $filter-&gt;filter($html);<br>&=
gt; <br>&gt; Output: &lt;!--[if gte IE 4]&gt;&lt;SCRIPT&gt;alert('XSS');&lt=
;/SCRIPT&gt;&lt;![endif]--&gt;<br>&gt; <br>&gt; So much for stripping tags.=
.. The StripTags filter does not have so much as a<br>&gt; cursory understa=
nding of the real world. Allowing comments allows for almost<br>&gt; anythi=
ng applicable to XSS on IE.<br>&gt; <br>&gt; So I disagree with all of thes=
e folk. There appears to be an appreciable and<br>&gt; real expectation tha=
t the StripTags filter prevents XSS - a cursory search of<br>&gt; Google pr=
ovides examples of people suggesting its use which indicates it is<br>&gt; =
used as such. I'm also fast forming the opinion that a lot of PHP
 developers<br>&gt; are clueless about XSS out there (that probably shouldn=
't be a surprise to me)<br>&gt; and we need to do something about it beside=
s wave our hands and leaving this<br>&gt; monstrosity in the source code in=
tact.<br>&gt; <br>&gt; Thomas Weidner has started the ball rolling by propo=
sing a Zend_Filter_Html<br><span>&gt; component (<a target=3D"_blank" href=
=3D"http://framework.zend.com/wiki/display/ZFPROP/">http://framework.zend.c=
om/wiki/display/ZFPROP/</a></span><br>&gt; Zend_Filter_Html+-+Thomas+Weidne=
r) which will be a wrapper around the<br><span>&gt; HTMLPurifier 4.0 (<a ta=
rget=3D"_blank" href=3D"http://www.htmlpurifier.org">http://www.htmlpurifie=
r.org</a>) library. I support this</span><br>&gt; unreservedly since I and =
others have been using custom filters of this nature<br>&gt; for years.<br>=
&gt; <br>&gt; I would also suggest the following:<br>&gt; <br>&gt; a) Rewor=
k the filter's current four lines of documentation (http://<br>&gt; <a
 target=3D"_blank" href=3D"http://framework.zend.com/manual/en/zend.filter.=
set.html#zend.filter.set.striptags">framework.zend.com/manual/en/zend.filte=
r.set.html#zend.filter.set.striptags</a>) to<br>&gt; cover the component in=
 greater detail clarifying its use cases, potential for<br>&gt; misuse, and=
 clarifying it is not XSS&nbsp; or malformed HTML safe.<br>&gt; b) Immediat=
ely deprecate in 1.9 branch (and remove in 2.0 - preferably 1.10<br>&gt; gi=
ven its significance) its ability to flexibly allow some HTML/comments thus=
<br>&gt; preserving its only truly worthwhile feature - stripping ALL HTML.=
<br>&gt; c) Do this ASAP.<br>&gt; <br>&gt; It should be highlighted that th=
e StripTags filter cannot be "fixed". It simply<br>&gt; has little capacity=
 to prevent XSS and is based on rudimentary regular<br>&gt; expression matc=
hing which is has absolutely no place in preventing XSS. The<br>&gt; filter=
 simply must never ever be used in any role involving the safe
 filtering<br>&gt; of HTML.<br>&gt; <br>&gt; Paddy<br>&gt;&nbsp; <br>&gt; P=
 draic Brady<br>&gt; <br><span>&gt; <a target=3D"_blank" href=3D"http://blo=
g.astrumfutura.com">http://blog.astrumfutura.com</a></span><br><span>&gt; <=
a target=3D"_blank" href=3D"http://www.survivethedeepend.com">http://www.su=
rvivethedeepend.com</a></span><br>&gt; OpenID Europe Foundation Irish Repre=
sentative<br>&gt; <br><br>-- <br>Matthew Weier O'Phinney<br>Project Lead&nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a ymailto=3D"mailto:matthew@zend.=
com" href=3D"mailto:[email-masked]">[email-masked]</a><br><span>Zend Fr=
amework&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a target=3D"_blank" href=3D"ht=
tp://framework.zend.com/">http://framework.zend.com/</a></span><br></div></=
div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compressed/chunked Mon Dec  7 03:29=
:14 PST 2009 -->=0A</div></body></html>
--0-1199419319-1260277324=:54407--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Thu, 25 Feb 2010 23:53:41 +0100
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

On Thursday 25 February 2010 21:48:57 Matthew Weier O'Phinney wrote:
>The release master can
>track multiple repos from multiple collaborators, and then selectively
>merge into their own "master" -- and push those patches into the
>mainline.

=46or the benefit of those who don't currently use Git one other powerful a=
spect=20
of this collaborative work-flow is being able to cherry pick commits.=20

In this situation you may have multiple branches, some of them may or may n=
ot=20
track other developers remote branches. Rather than merge the whole branch=
=20
from HEAD to 6 commits previously, you see that only one of the commits has=
=20
the changeset you need. Git cherry-pick allows you to merge a single commit.

This, and being able to merge at will from multiple remote branches is the=
=20
kind of functionality I believe makes Git more suitable than SVN for what w=
e=20
do.

There's more, much more. One of the key differences between Git and SVN, an=
d=20
this is extremely important, is that Git tracks the _content_ of your files=
=20
whereas SVN tracks the files themselves. Git really doesn't care that there=
=20
are 10 or 20 or 1,000 files, it only cares about the content and it only ca=
res=20
how the content changes.

Here's an example, since Layout.php has been in the codebase for a while I=
=20
wanted to see who was responsible for last editing it. So i looked at the=20
source and decided to lookup the method setMvcSuccessfulActionOnly(). It's =
on=20
line number 483-487.

    git blame -L 483,487 Layout.php

I'll trim the output and ommit the actual code which is appended to the end=
 of=20
the following lines but you can see the detailed info that is available.

b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000=
=20
483)
b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000=
=20
484)
b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000=
=20
485)
b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000=
=20
486)
b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000=
=20
487)

So in less than a quarter of a second I can search the whole commit history=
 of=20
the main ZF repo and see who was responsible for last editing any line of a=
ny=20
file. There's lots more gems like this that let you unleash the power of Gi=
t=20
if you want to look below the surface.

The surface is a good place to be as well, let me offer a common work-flow=
=20
situation with git using every day commands.

git checkout -b foobar
edit foo/bar.php
=2E.. hack hack hack ...
*ring ring* oops emergency fix needed
git stash
git checkout master
edit emergency/fix.php
git commit -am "Commit fix!"
git checkout foobar
git stash pop
=2E.. hack hack hack ...
git checkout master
git merge foobar
*glug glug glug* cold beers while your colleagues are still fighting SVN.

The story above is: Create and move into feature branch "foobar". Start=20
hacking on the feature. Boss calls, X is broken!, stash your changes and=20
quickly switch to master(trunk). Fix broken things, commit them, switch bac=
k=20
to foobar branch. Pop your changes from the stash into your working set,=20
continue hacking. Switch to master(trunk) and merge your new feature Foobar=
=2E=20
Profit!

=2D-=20
=E2=80=9CWhat can be asserted without proof can be dismissed without proof.=
=E2=80=9D
=2D Christopher Hitchens

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 16 Dec 2009 07:03:09 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Fwd

-- Sean P. O. MacCath-Moran <[email-masked]> wrote
(on Tuesday, 15 December 2009, 10:03 PM -0500):
> .... and he'll be summarily removed from this list, right?

Yep.

> On Tue, Dec 15, 2009 at 8:57 PM, H.N. <[email-masked]> wrote:
> 
>                        yhbnokdc - oqvffooxgafduw - prkjojirq
>                          <snipped the mind numbing garbage>

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 18 Nov 2009 10:04:11 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Dev Tools going down for an hour or two

Hey, all --

We need to upgrade Crowd, which provides the single sign-on capabilities
for the various developer tools (wiki, issue tracker, etc.). This will
require taking all of them offline for an hour or two.

I will post here again once they are all back up.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 18 May 2009 10:55:26 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Bug hunt week!

Greetings, all!

The internal team is having a bug hunt week. We're striving to clear out
as many of the most voted issues as possible:

    http://framework.zend.com/issues/secure/IssueNavigator.jspa?reset=true&&type=1&type=9&type=8&type=15&type=13&pid=10000&resolution=-1&sorter/field=issuekey&sorter/order=DESC&sorter/field=votes&sorter/order=DESC

We would appreciate any help *you* can provide us -- writing tests and
patches, fixing issues yourselves, etc.

In conjunction, I'll be at php|tek this week, and representing ZF at the
"Hackathon", which will occur both Wednesday and Thursday evenings. I
will be on IRC during that time; if you are attending or want to attend
virtually, any and all help will be appreciated!

Let's close as many issues as we can this week!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:11 2010
Date: Mon, 27 Jul 2009 10:55:48 -0500
From: Ralph Schindler <[email-masked]>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
CC: Matthew Weier O'Phinney <[email-masked]>, 
	Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services
	to ZendX Proposal

> 1. Hold a once monthly issue clearing day. I'm sure that's not 
> original... Having at least one day (anymore may risk it losing its 
> "special" status) to raise awareness on the blogs and mailing lists that 
> you need help clearing issues, how to get started, and who to call when 
> a commit goes completely off target might achieve something. Once a 
> month is also light enough that it remains a special event needing 
> minimal time commitments.

I am very much in favor of this.  Some time ago I attempted to field 
some community members to help with the backlog of issues in Zend_Db, 
and while I got a couple of bites and a few dedicated contributors that 
help out, ideally, there would be more.

I know the current testing suite for Zend_Db is pretty complex, and 
makes it hard to write new tests for a variety of issues, but I am 
addressing that in the coming month (work is already in my branch).

Outside of that, I think with a coordinated effort (a standard bug day), 
we can do alot more in the way of addressing issues.  This also allows 
the component maintainers to educate other developers on the internals 
of the component thus facilitating more people fixing issues.  But we'd 
need a day where people are focused singularly on addressing issues, as 
coordination is ultimately the key here.

> 2. There are a lot of issues where people have attached patches, so it 
> shouldn't be too hard to press gang some volunteers into a more organic 
> team responsible for reviewing those specifically. Giving them a fancy 
> name like "Matthew's Elite Hit Squad" would serve as additional 
> motivation. Failing that, tell them it's their patriotic duty (nation 
> dependent). Or park a Rentokil van outside their house at 2am.

Addressed above.  While the patches are fundamentally good, several of 
them need that final polishing to be taken in.  A bug day, and working 
with the patch contributor would solve this.

> 4. Not sure if this exists, but it's been mentioned before so maybe not 
> (Carlton Gibson), something like a help wanted board could help. Make it 
> a regular mailing list email for extra exposure. It's all about 
> awareness to be honest - if people don't know and don't care, nothing 
> will get done. Somewhat related, is there a page listing the most 
> pressing issues needing resolution? I remember something like this from 
> some time ago.

Like I said above: I'd be interested in coordinating a group effort here.

I've done this once before with the bug hunt that went down last october 
in europe.  20 people fixing issues, and I could field any questions 
they had, reviewed patches and more.  This works generally well, and I 
remember alot of issues being closed in that one weekend.

Some components are more complex than others, but that shouldn't be a 
hindrance in getting more people to support them in the long run.

-ralph

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 20 Oct 2009 23:27:57 +0200
From: Marc Bennewitz <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Zend_Serializer proposal

Hello everyone,

Today I created a new proposal "Zend_Serializer" and moved it to "Ready
for Review" section.
(http://framework.zend.com/wiki/display/ZFPROP/Zend_Serializer+-+Marc+Bennewitz)

This new component provides a consistency way of un-/serialize values
with different methods like php-serialize, igbinary, json, wddx, pickle,
amf*.

Cheers
Marc

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Jurian Sluiman <[email-masked]>
To: [email-masked]
Date: Sat, 23 Jan 2010 10:07:03 +0100
Cc: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors] Doctrine 1 Integration Ideas

On Friday 22 Jan 2010 12:57:05 Benjamin Eberlei wrote:
> Hello everyone,

Hi Benjamin,

I've been working on the integration as well. It's quite specified to my own 
work flow, but might be useful nevertheless.

> Therefore my idea is, two-fold:
> 
> I. Single ZF Module (Default)

Because my existing application uses many modules, this seems not useful to 
me. I haven't looked at single module integration.
 
> II. Doctrine + Multiple ZF MOdules:
> 
> Circumvent Doctrine_Core::loadModels() completely by introducing a new
> auto-loading
> mechanism and slightly modifying the Doctrine_Import_Schema class.

The Doctrine_Core::loadModels() is used by me on a modular basis. There is a 
module application resource which bootstraps all the module bootstrap classes. 
These classes load their own models which works really good for me.

> 1. Detect Module name by checking the first result of explode("_",
> $className)
> 
> 2. If the first is "Model", grab default module from Front-Controller,
> otherwise Check that second result is "Model"
> 
> 3. Write record, base-record and optionally table classes into the modules
> model directory.

This is done by using code generation -again- on modular basis. Thus no: zf 
generate doctrine.models, but always specified with a module name (zf generate 
doctrine.models blog). This might be extended using the profile to loop through 
the modulesDirectory context inside the .zfproject.xml file?

> Any ideas?

My implementation works currently as follows:

1) zf create doctrine-project blog will create a configs folder in the module 
folder (if it doesn't exist yet). Then it creates the folders schema, 
migrations, sql and data (and write changes in the .zfproject.xml).
2) now it's possible to create your own files in the schema directory with the 
modules you want (e.g. article.yml containing an Article model)
3) zf generate doctrine.models blog will look into the schema directory and 
generate the models. It's prefixed with Blog_Model and a base class is inside a 
Base subdirectory (containing the Blog_Model_Base_Article class). No table 
classes are generated.
4) zf generate doctrine.tables blog should generate the table classes for all 
the models in the blog module.

The last step works only for the first time (creation of tables). If you modify 
the yaml file and do zf generate doctrine.models blog all models are updated 
correctly. I get a lot of errors on zf generate doctrine.tables blog to modify 
the tables, and had no time figuring out why it fails. 

If I solved the problem, I can commit the work into my svn library if you 
want?

> greetings,
> Benjamin

Greetings, Jurian
-- 
Jurian Sluiman
CTO Soflomo V.O.F.
http://soflomo.com

nFrom nobody Wed Apr  7 08:46:11 2010
From: mkk <[email-masked]>
Reply-To: mkk <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>, [email-masked]
Subject: re: [zf-contributors] Re: requirements (documentation) of
	Zend_Serializer
Date: Wed, 20 Jan 2010 16:58:58 +0100 (CET)

------=_Part_19113_26072886.1264003138151
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I added these changes. I will merge them ASAP.

Mickael

> Message du 20/01/10 15:26
> De : "Matthew Weier O'Phinney"=20
> A : [email-masked]
> Copie =C3=A0 :=20
> Objet : [zf-contributors] Re: requirements (documentation) of Zend_Serial=
izer
>=20
>=20
> -- Marc Bennewitz wrote
> (on Tuesday, 19 January 2010, 11:39 PM +0100):
> > I added the requirements of Zend_Serializer to trunk but these files ar=
e
> > completely different to that in 1.10 branch.
> > Is there some work on it ?
>=20
> Merge the changes to the 1.10 branch, please.
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead | [email-masked]
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> -------------------------------------------------------------------------=
--------------
> Orange vous informe que cet e-mail a ete controle par l'anti-virus mail.=
=20
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>=20
>=20
>=20

------=_Part_19113_26072886.1264003138151
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I added these changes. I will merge them ASAP.<br /><br />Mickael<br /><br =
/><blockquote style=3D"border-left: 2px solid #ff0000; padding-left: 5px; m=
argin-left: 5px">&gt; Message du 20/01/10 15:26<br />&gt; De : &quot;Matthe=
w Weier O'Phinney&quot; <br />&gt; A : [email-masked]<br />=
&gt; Copie &agrave; : <br />&gt; Objet : [zf-contributors] Re: requirements=
 (documentation) of Zend_Serializer<br />&gt; <br />&gt; <br />&gt; -- Marc=
 Bennewitz  wrote<br />&gt; (on Tuesday, 19 January 2010, 11:39 PM +0100):<=
br />&gt; &gt; I added the requirements of Zend_Serializer to trunk but the=
se files are<br />&gt; &gt; completely different to that in 1.10 branch.<br=
 />&gt; &gt; Is there some work on it ?<br />&gt; <br />&gt; Merge the chan=
ges to the 1.10 branch, please.<br />&gt; <br />&gt; -- <br />&gt; Matthew =
Weier O'Phinney<br />&gt; Project Lead            | [email-masked]<br />&=
gt; Zend Framework          | http://framework.zend.com/<br />&gt; PGP key:=
 http://framework.zend.com/zf-matthew-pgp-key.asc<br />&gt; ---------------=
------------------------------------------------------------------------<br=
 />&gt; Orange vous informe que cet  e-mail a ete controle par l'anti-virus=
 mail. <br />&gt; Aucun virus connu a ce jour par nos services n'a ete dete=
cte.<br />&gt; <br />&gt; <br />&gt; <br /></blockquote>
------=_Part_19113_26072886.1264003138151--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 23 Feb 2010 19:01:20 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.10.2 preview packages available

Greetings, all --

I've finished packaging the 1.10.2 release of Zend Framework, and we
plan to release tomorrow. You can preview packages at the following
locations:

 * Full packages:
   http://framework.zend.com/releases/preview/ZendFramework-1.10.2/ZendFramework-1.10.2.tar.gz
   http://framework.zend.com/releases/preview/ZendFramework-1.10.2/ZendFramework-1.10.2.zip

 * Minimal packages:
   http://framework.zend.com/releases/preview/ZendFramework-1.10.2/ZendFramework-1.10.2-minimal.tar.gz
   http://framework.zend.com/releases/preview/ZendFramework-1.10.2/ZendFramework-1.10.2-minimal.zip

Please let myself or anyone on the ZF team know ASAP if you notice any
critical issues that need to be addressed.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 28 Nov 2009 16:04:18 +0100
From: =?UTF-8?B?R29yYW4gSnVyacSH?= <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Feed_Reader Assistance Needed (Or I'll
	Go Crazy)

This is a multi-part message in MIME format.
--------------050103090305030900020806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 28.11.2009. 15:30, P=C3=A1draic Brady wrote:
> Bit of an odd reason for this ;). I'm getting a fatal error (see=20
> bottom) when running the unit tests for Zend_Feed_Reader (via=20
> trunk/tests/Zend/Feed/AllTests.php). After two hours of staring at=20
> gedit without the slightest clue or knock of inspiration - I've just=20
> about exhausted my supply of patience.
>
> If someone is doing any ZF development over the weekend, would truly=20
> appreciate any insight on resolving this. It has me completely stumped.
>
> <cut>
>
>     0.6806   11464144  10.=20
> require_once('/home/padraic/projects/zf/trunk/tests/Zend/Feed/ReaderTes=
t.php')=20
> /home/padraic/projects/zf/trunk/tests/Zend/Feed/AllTests.php:48

Try moving the zf folder from /home/padraic/projects/zf/trunk to a=20
shorter path, like /opt/zf.

I had a weird bug a year, or two, ago when some of the ZF classes could=20
not be loaded because they were buried quite deep in my folder=20
structure. I just could not remember if it was on Ubuntu or on Windows.=20
Anyways, moving the ZF closer to the root worked so I didn't investigate=20
this issue any further.

Regards,

Goran Juric
http://gogs.info/

--------------050103090305030900020806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  <title></title>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
On 28.11.2009. 15:30, P=C3=A1draic Brady wrote:
<blockquote cite=3D"mid:[email-masked]"
 type=3D"cite">
  <style type=3D"text/css"><!-- DIV {margin:0px;} --></style>
  <div
 style=3D"font-family: times new roman,new york,times,serif; font-size: 1=
2pt;">Bit
of an odd reason for this ;). I'm getting a fatal error (see bottom)
when running the unit tests for Zend_Feed_Reader (via
trunk/tests/Zend/Feed/AllTests.php). After two hours of staring at
gedit without the slightest clue or knock of inspiration - I've just
about exhausted my supply of patience.<br>
  <br>
If someone is doing any ZF development over the weekend, would truly
appreciate any insight on resolving this. It has me completely stumped.<b=
r>
  <br>
&lt;cut&gt;<br>
  <br>
=C2=A0=C2=A0=C2=A0 0.6806=C2=A0=C2=A0 11464144=C2=A0 10.
require_once('/home/padraic/projects/zf/trunk/tests/Zend/Feed/ReaderTest.=
php')
/home/padraic/projects/zf/trunk/tests/Zend/Feed/AllTests.php:48<br>
  </div>
</blockquote>
<br>
Try moving the zf folder from /home/padraic/projects/zf/trunk to a
shorter path, like /opt/zf. <br>
<br>
I had a weird bug a year, or two, ago when some of the ZF classes could
not be loaded because they were buried quite deep in my folder
structure. I just could not remember if it was on Ubuntu or on Windows.
Anyways, moving the ZF closer to the root worked so I didn't
investigate this issue any further.<br>
<br>
Regards,<br>
<br>
Goran Juric<br>
<a class=3D"moz-txt-link-freetext" href=3D"http://gogs.info/">http://gogs=
.info/</a><br>
</body>
</html>

--------------050103090305030900020806--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 13 Apr 2009 22:59:56 +0200
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

As before, I mostly agree with those standards. I don't really like the
thing about lowercased namespaces, but the rest looks fine to me. I
already adopted the interface naming for Zend_Tag_IItem, as the name was
simply too awkward.
...................................
:  ___   _   ___ ___ ___ _ ___    :
: |   \ /_\ / __| _ \ _ (_)   \   :
: | |) / _ \\__ \  _/   / | |) |  :
: |___/_/:\_\___/_| |_|_\_|___/   :
:........:........................:
: Web    : http://www.dasprids.de :
: E-mail : [email-masked]       :
: Jabber : [email-masked]     :
: ICQ    : 105677955              :
:........:........................:

Matthew Weier O'Phinney schrieb:
> I'm going to break a couple of rules here: I'm replying to my own email,
> as well as top-posting. Bear with me...
> 
> Robin S. raised an interesting point that Matt R. picked up and agreed
> with:
> 
>     I also notice that namespaces are written in Uppercase\Notation --
>     Zend\Controller\Request. Will this be the standard? Another
>     alternative is zend\controller\Request, which clearly distinguishes
>     what's the namespace and what's the class/interface.
> 
> Additionally, it seems the primary push-back is with abstract class
> naming, particularly when there are also interfaces defined in the same
> namespace.
> 
> After reading these responses, I reached out to some friends in the PEAR
> community, some of whom I've spoken with before about these issues. "Why
> PEAR?" some may ask. ZF standards are based on PEAR standards. One goal
> since the beginning of the ZF project has been to promote
> interoperability with established standards. PEAR CS are the "gold
> standard" in the PHP community, and whether you like or agree with them
> or not, they are used widely.
> 
> The PEAR Group has been debating new standards to adopt for PEAR2 for
> some time now. PEAR2 is targeting a minimum required version of PHP 5.3,
> so they are addressing the very same issues we're discussing. They have
> also basically reached consensus, though they have not formally adopted
> the new standards yet. When it comes to namespaces and class naming, it
> is the ZF team's opinion that we need to be as close to PEAR standards
> as possible.
> 
> The relevant documents are here:
> 
>     http://wiki.php.net/pear/rfc/pear2_class_naming
>     http://wiki.php.net/pear/rfc/pear2_naming_standards
> 
> In a nutshell, here's what they define:
> 
>  * Namespaces are lowercase: zend\codegenerator\php
>  * Class names are MixedCase: zend\codegenerator\php\File
>  * Namespaces may contain underscores, but they do not translate to the
>    directory separator
>  * Class names may contain underscores, and they *do* translate to the
>    directory separator
>  * Interfaces should be named descriptively, and not contain the word
>    "Interface" or the sigil "I".
>  * It is preferred that Abstract classes are also named descriptively,
>    but *may* contain the *suffix* Abstract.
> 
> There are some good arguments for each point in the linked RFCs.
> 
> I think that adopting these standards addresses most concerns the ZF
> team has, as well as many if not most concerns posted in this thread. 
> 
> -- Matthew Weier O'Phinney <[email-masked]> wrote
> (on Friday, 10 April 2009, 02:24 PM -0400):
>> Greetings, all --
>>
>> Below is a proposal I am making to modify the Zend Framework Coding
>> Standards conventions for the naming of Interfaces and Abstract classes.
>>
>> This decision is basically already made, but I'd appreciate any feedback
>> that you may have on the matter.
>>
>> Thanks!
>>
>> The problem
>> ===========
>> PHP 5.3 introduces namespaces to the PHP language. While this won't have an
>> impact much on userland code, it will have an impact on library and framework
>> code, as it provides a useful paradigm for organizing components as well as
>> simplifying syntax. Instead of having to say things like:
>>
>>     $analyzer = new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
>>
>> we can instead do something like this:
>>
>>     namespace Zend\Search\Lucene\Analysis\Analyzer;
>>
>>     $analyzer = new Common_TextNum();
>>
>> or even:
>>
>>     namespace Zend\Search\Lucene\Analysis\Analyzer;
>>
>>     class Common_TextNum extends Common
>>     {
>>     }
>>
>> The problem that arises for Zend Framework has to do with how we name abstract
>> classes and interfaces. Currently, the final segment of such classes are
>> expected to end with _Abstract and _Interface, respectively. This will not work
>> when we migrate to utilize namespaces, for two reasons.
>>
>> First, and most obviously, 'abstract' and 'interface' are reserved PHP keywords.
>> As such, in situations such as the following:
>>
>>     namespace Zend\Controller\Request;
>>
>>     class Abstract
>>     {
>>     }
>>
>>     // or:
>>
>>     namespace Zend\Controller\Dispatcher;
>>
>>     interface Interface
>>     {
>>     }
>>
>> we'll run into issues.
>>
>> Second, and less obvious, is that perhaps the easiest solution breaks one of the
>> key principles of namespaces (which are designed to help encapsulate
>> components). This one's harder to explain, so let's look at examples. Consider a
>> component such as Zend_Controller_Request. The simplest solution would be to
>> name the abstract class or interface Zend\Controller\Request, and then have the
>> various concrete implementations under that namespace:
>>
>>     namespace Zend\Controller;
>>
>>     interface Request
>>     {
>>     }
>>
>>     // and concrete ones:
>>
>>     namespace Zend\Controller\Request;
>>
>>     class Http
>>     {
>>     }
>>
>> What's the problem here? The interface is not in the same namespace as the
>> concrete implementations.
>>
>> Potential solutions and recommendation
>> ======================================
>> So, how should Zend Framework "solve" these issues? A number of proposals and
>> recommendations have been floated around, both within ZF circles and in the
>> greater PHP community. 
>>
>> Considerations include:
>>
>>  * Avoiding the use of PHP reserved keywords (already noted).
>>  * Avoiding Hungarian Notation (i.e., having the name or a portion of the name
>>    describe its type -- which, to a degree, the current naming conventions
>>    already violate). (See http://en.wikipedia.org/wiki/Hungarian_Notation, the
>>    sections "Disadvantages of Systems Hungarian" and "Notable Opinions" for some
>>    of the arguments against using Hungarian Notation.)
>>
>> Approaches that have been considered include:
>>
>>  * Using 'I' to prefix interfaces. This derives from standards in other
>>    programming languages (.Net and python, in particular). This is just another
>>    form of Hungarian Notation, however.
>>
>>  * Using "Interface" or "Abstract" as a class name suffix: RequestInterface,
>>    RequestAbstract. Again, however this is Hungarian Notation.
>>
>>  * Using the term "Base" for abstract classes: BaseRequest, RequestBase, Base.
>>    This is just substituting the word Base for Abstract, however, and is really
>>    not much different than the above.
>>
>>  * Use generic, descriptive names indicative of functionality or behavior. As
>>    examples from the SPL, "Countable", "Iterator", "ArrayObject".  
>>    
>> My recommendation is to use the latter, as it solves all considerations. It will
>> take more thought when naming, but will ensure that components can live in a
>> self-contained namespace, do not use reserved keywords, and avoid Hungarian
>> Notation.
>>
>> Plan for implementation
>> =======================
>> I recommend that the Coding Standards documentation be updated to reflect this
>> approach. 
>>
>> All new components going into 1.8 and onwards should adopt these standards. In
>> releases 1.9 and forward, we will begin migrating existing interfaces/abstract
>> classe. First, new classes/interfaces will be created that follow these
>> conventions and which extend the originals; later, any type-hinting based on the
>> original class/interface names will be updated to point to the new names; and
>> finally, in 2.0, we will remove the old interfaces/abstract classes entirely.
>>
>> -- 
>> Matthew Weier O'Phinney
>> Software Architect      | [email-masked]
>> Zend Framework          | http://framework.zend.com/
>>
> 

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Oct 2009 12:08:02 -0700
From: Trevor Johns <[email-masked]>
To: Pieter Kokx <[email-masked]>
Cc: Ralph Schindler <[email-masked]>,
	"Whitcraft, Jon" <[email-masked]>,
	"[email-masked]" <[email-masked]>
Subject: Re: [zf-contributors] Code Review

On Sat, Oct 10, 2009 at 11:04 AM, Matthew Ratzloff
<[email-masked]> wrote:
>> (My personal experience with Crucible has not been great, but I have
>>
>> hope that it can be configured to work better.)
>
> Unfortunately, Crucible is the best of the bunch.  Using it with FishEye is
> basically a requirement, as is throwing several gigs of RAM at it.  Once you
> do that, it's not that bad.
> -Matt

My personal experience with Crucible has been pretty bad too. The
problem isn't performance, it's the workflow.

Namely:

1. The way we have Crucible setup, code reviews are started so that
everybody on the project is invited to the review, which is totally
impractical. If I just want to invite one person, I need to uncheck an
ungodly number of checkboxes.

2. It's not easy to do pre-commit reviews in Crucible, which I greatly
prefer over post-commit reviews. There is a mechanism to upload a
patch file, but that's done outside of SVN/Git. I don't believe
there's any way to start a code review from my command line.

Personally, the best code review experience I've had is with Gerrit
(review.source.android.com), with Rietveld (codereview.appspot.com)
coming in second place.

That being said, I'd love to have a formal code review policy in place
for ZF. I've had an unofficial policy in place for Zend_Gdata for a
while now, since I work directly with most of the other committers on
that module, and it's worked very well.

-- 
Trevor Johns

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 11 Nov 2009 18:37:22 -0200
From: Guilherme Blanco <[email-masked]>
To: Robin Skoglund <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

http://groups.google.com/group/php-standards/web/final-proposal

On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[email-masked]> wrote:
> On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney <[email-masked]>=
 wrote:
>>
>> In looking at your above notes, I realize that there's another change
>> that needs to be noted in the docs: targetting the PHP Interop Group's
>> specifications. The Exception usage is in line with our current
>> discussions, already. The package naming will work -- but the ideal is
>> to ship package names as all lowercase. Any script for migration will
>> need to take that into account as well.
>
> Do you have a link for the PHP Interop Group specifications? I was
> about to make a comment in the wiki about the Exception usage, but I
> guess I should read up on the mentioned docs first.
>

--=20
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [email-masked]
URL: http://blog.bisna.com
S=C3=A3o Paulo - SP/Brazil

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 4 Jun 2009 19:11:21 +0200
From: till <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] addScriptPath question

Hey,

debugging some code, and I noticed that addScripPath (and ultimately
_addPath()) in Zend_View_Abstract always prepends the path. I was
trying to add script paths as a fall back -- if not found in this
module, fallback to default (or where the other path leads to). Any
idea if we could add this kind of behavior for 2.0?

This is the code (from Zend/View/Abstract.php, _addPath()):

        switch ($type) {
                case 'script':
                    // add to the top of the stack.
                    array_unshift($this->_path[$type], $dir);
                    break;

Sort of related, it would be nice if there were no private methods in
that class. ;-(

Till

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 12 Mar 2010 17:37:46 -0500
From: "A.J. Brown" <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 10 Mar 2010

--000e0ce0480c3575de0481a22e29
Content-Type: text/plain; charset=ISO-8859-1

Hey Matthew,

Glad to see things moving along with ZF 2.0!

I'm not sure about the requirement for autoloading in _unit_ tests.
Autoloading adds another layer of code that's not directly related to the
unit under test.  A bug in AutoLoading could directly affect the outcome of
another unit test.  Imagine a situation where the wrong class is autoloaded
in the middle of a test, but it just so happens to work out.

Of course, autoloading should be incorporated in more comprehensive tests.

Thoughts?

On Wed, Mar 10, 2010 at 4:48 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> Greetings!
>
> Since the last update, myself and the team have been busy working on the
> test suite. We had the following goals:
>
>  * Strip (most) require_once calls
>   If we're going to be an autoloading framework, unit tests should use
>   autoloading as well.
>
>  * Remove all AllTests.php files
>   These are largely a relic of the early days of ZF development, and
>   are not really needed anymore. You can specify specific directories
>   in which to run tests, individual files, by group, and more;
>   additionally, there are better tools for building test suites.
>
>  * Create a phpunit.xml and test bootstrap
>   This will allow us to specify rules for running tests, as well as the
>   actual test environment for every test case.
>
>  * Have all tests passing (or at least in the same state as trunk)
>
> Ralph is working on Zend_Tool tests as I write this -- but that's the
> last component to be reviewed. Otherwise, all the tasks above are now
> accomplished. To run any tests, you simply change directory to the
> tests/ subdirectory, and then call phpunit with any arguments you want
> to specify (including directories or files).
>
> Additionally, we've made some changes to Zend_Loader_Autoloader. Since
> ZF users will likely be using both code with true PHP namespaces as well
> as code using simply pre-5.3 style vendor prefixes, we introduced a set
> of "registerPrefix" methods. The old familiar "registerNamespace"
> methods will now work only for classes using PHP namespace notation.
> This is definitely a BC break, but one that should be fairly trivial to
> script a fix for in existing codebases.
>
> Next on our list of "foundational tasks" to tackle:
>
>  * Conversion to namespaces
>  * Refactoring of exceptions
>
> These tasks will likely take longer than what we've done to date. We are
> aiming to balance automatic conversion, code readability, and
> performance -- and I'm not expecting a good solution to present itself
> on our first few tries.
>
> Until next time, happy programming!
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

-- 
A.J. Brown
Software Engineer, ZCE
blog : http://ajbrown.org
talk  : (937) 540-0099
chat : IntypicaAJ

--000e0ce0480c3575de0481a22e29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Matthew,<br><br>Glad to see things moving along with ZF 2.0!<br><br>I&#=
39;m not sure about the requirement for autoloading in _unit_ tests.=A0 Aut=
oloading adds another layer of code that&#39;s not directly related to the =
unit under test.=A0 A bug in AutoLoading could directly affect the outcome =
of another unit test.=A0 Imagine a situation where the wrong class is autol=
oaded in the middle of a test, but it just so happens to work out.=A0 <br>
<br>Of course, autoloading should be incorporated in more comprehensive tes=
ts.<br><br>Thoughts?<br><br><br><div class=3D"gmail_quote">On Wed, Mar 10, =
2010 at 4:48 PM, Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Greetings!<br>
<br>
Since the last update, myself and the team have been busy working on the<br=
test suite. We had the following goals:<br>
<br>
=A0* Strip (most) require_once calls<br>
 =A0 If we&#39;re going to be an autoloading framework, unit tests should u=
se<br>
 =A0 autoloading as well.<br>
<br>
=A0* Remove all AllTests.php files<br>
 =A0 These are largely a relic of the early days of ZF development, and<br>
 =A0 are not really needed anymore. You can specify specific directories<br=
 =A0 in which to run tests, individual files, by group, and more;<br>
 =A0 additionally, there are better tools for building test suites.<br>
<br>
=A0* Create a phpunit.xml and test bootstrap<br>
 =A0 This will allow us to specify rules for running tests, as well as the<=
br>
 =A0 actual test environment for every test case.<br>
<br>
=A0* Have all tests passing (or at least in the same state as trunk)<br>
<br>
Ralph is working on Zend_Tool tests as I write this -- but that&#39;s the<b=
r>
last component to be reviewed. Otherwise, all the tasks above are now<br>
accomplished. To run any tests, you simply change directory to the<br>
tests/ subdirectory, and then call phpunit with any arguments you want<br>
to specify (including directories or files).<br>
<br>
Additionally, we&#39;ve made some changes to Zend_Loader_Autoloader. Since<=
br>
ZF users will likely be using both code with true PHP namespaces as well<br=
as code using simply pre-5.3 style vendor prefixes, we introduced a set<br>
of &quot;registerPrefix&quot; methods. The old familiar &quot;registerNames=
pace&quot;<br>
methods will now work only for classes using PHP namespace notation.<br>
This is definitely a BC break, but one that should be fairly trivial to<br>
script a fix for in existing codebases.<br>
<br>
Next on our list of &quot;foundational tasks&quot; to tackle:<br>
<br>
=A0* Conversion to namespaces<br>
=A0* Refactoring of exceptions<br>
<br>
These tasks will likely take longer than what we&#39;ve done to date. We ar=
e<br>
aiming to balance automatic conversion, code readability, and<br>
performance -- and I&#39;m not expecting a good solution to present itself<=
br>
on our first few tries.<br>
<br>
Until next time, happy programming!<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>A.J. Brown<br>So=
ftware Engineer, ZCE<br>blog : <a href=3D"http://ajbrown.org">http://ajbrow=
n.org</a><br>talk =A0: (937) 540-0099<br>chat : IntypicaAJ<br>

--000e0ce0480c3575de0481a22e29--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 13:24:51 -0500
From: Court Ewing <[email-masked]>
To: Matthew Ratzloff <[email-masked]>
Cc: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--001485f5ae7017ee7e048070e63e
Content-Type: text/plain; charset=ISO-8859-1

Howdy,

I agree with this sentiment entirely.  While Doctrine 1.x is currently the
stable series, plans already exist to drop support for it in a little over a
year (according to the latest roadmap I've seen).  As this is a ZF2 email
chain, we should focus on Doctrine 2 integration with ZF2.

Doctrine 2, while under heavy development, is actually in a pretty stable
state.  Pretty much all of the currently implemented functionality will not
be changing over the next few months, so this sort of integration could
begin shortly after the initial ZF changes that Matthew has already
described.

Court Ewing

On Thu, Feb 25, 2010 at 1:10 PM, Matthew Ratzloff
<[email-masked]>wrote:

> I don't think it would be beneficial to include Doctrine 1.x support in
> Zend Framework 1.x for this reason.  There is no real "upgrade" path from
> version 1 to 2; they are very different.  It also divides contributors'
> limited time, and the idea that you'll be working hard on something that
> will quickly be deprecated is not very motivating.
>
> -Matt
>
>
> On Thu, Feb 25, 2010 at 8:46 AM, Giorgio Sironi <
> [email-masked]> wrote:
>
>> On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]>wrote:
>>
>>> I like the idea (as David Caunt mentioned) of releasing a 1.X branch with
>>> Doctrine 1 to test the waters and judging by the amount of work required
>>> decide to go with Doc2+ZF2 when the time comes.
>>>
>>
>> Beware that Doctrine 1 and Doctrine 2 are very different: the fomer is
>> ActiveRecord-based while the latter on the UnitOfWork pattern. Their
>> metadata management is not the same and 2.x is a complete rewrite of 1.x.
>>
>> Regards,
>> --
>> Giorgio Sironi
>> Piccolo Principe & Web Engineer
>> http://giorgiosironi.blogspot.com
>> http://twitter.com/giorgiosironi
>>
>
>

-- 
Regards,
Court Ewing
610-304-1624

--001485f5ae7017ee7e048070e63e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Howdy,<br><br>I agree with this sentiment entirely.=A0 While Doctrine 1.x i=
s currently the stable series, plans already exist to drop support for it i=
n a little over a year (according to the latest roadmap I&#39;ve seen).=A0 =
As this is a ZF2 email chain, we should focus on Doctrine 2 integration wit=
h ZF2.<br>
<br>Doctrine 2, while under heavy development, is actually in a pretty stab=
le state.=A0 Pretty much all of the currently implemented functionality wil=
l not be changing over the next few months, so this sort of integration cou=
ld begin shortly after the initial ZF changes that Matthew has already desc=
ribed.<br>
<br>Court Ewing<br><br><div class=3D"gmail_quote">On Thu, Feb 25, 2010 at 1=
:10 PM, Matthew Ratzloff <span dir=3D"ltr">&lt;<a href=3D"mailto:matt@built=
fromsource.com">[email-masked]</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;">
I don&#39;t think it would be beneficial to include Doctrine 1.x support in=
 Zend Framework 1.x for this reason. =A0There is no real &quot;upgrade&quot=
; path from version 1 to 2; they are very different. =A0It also divides con=
tributors&#39; limited time, and the idea that you&#39;ll be working hard o=
n something that will quickly be deprecated is not very motivating.<div>

<br></div><div>-Matt<div><div></div><div class=3D"h5"><br><br><div class=3D=
"gmail_quote">On Thu, Feb 25, 2010 at 8:46 AM, Giorgio Sironi <span dir=3D"=
ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bla=
nk">[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class=3D"gma=
il_quote"><div class=3D"gmail_quote"><div><div>On Thu, Feb 25, 2010 at 5:24=
 PM, Anthony Shireman <span dir=3D"ltr">&lt;<a href=3D"mailto:ashireman@gma=
il.com" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>

</div></div><div><div><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;">
I like the idea (as David Caunt mentioned) of releasing a 1.X branch with D=
octrine 1 to test the waters and judging by the amount of work required dec=
ide to go with Doc2+ZF2 when the time comes.<br clear=3D"all"></blockquote>

</div></div><div><br>Beware that Doctrine 1 and Doctrine 2 are very differe=
nt: the fomer is ActiveRecord-based while the latter on the UnitOfWork patt=
ern. Their metadata management is not the same and 2.x is a complete rewrit=
e of 1.x.<br>

</div></div><div><div></div><br clear=3D"all"></div></div><div><div></div><=
div>Regards,<br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Enginee=
r<br><a href=3D"http://giorgiosironi.blogspot.com" target=3D"_blank">http:/=
/giorgiosironi.blogspot.com</a><br>

<a href=3D"http://twitter.com/giorgiosironi" target=3D"_blank">http://twitt=
er.com/giorgiosironi</a><br>

</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Regards,<br>Court Ewing=
<br>610-304-1624<br>

--001485f5ae7017ee7e048070e63e--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 28 Jul 2009 04:05:38 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Thomas Weidner <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Contributor list

--0-1012628341-1248779138=:54388
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Thomas,=0A=0AJust a reference to something I edited while adding myself =
since I'm unclear on how it should be handled. In components with muliple p=
arts (for example Zend_Feed also hosts the completely independent Zend_Feed=
_Reader) we may not have a single lead. In that case was it okay for me to =
add Zend_Feed_Reader as a separate entry on the table? Easily reversed if n=
ot :).=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=
=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Repres=
entative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Thomas W=
eidner <[email-masked]>=0ATo: [email-masked]=0ASent:=
 Tuesday, July 28, 2009 8:12:05 AM=0ASubject: Re: [zf-contributors] Contrib=
utor list=0A=0ALike for all other pages within our wiki you need to login.=
=0AIt's the same process as if you edit one of your proposals.=0A=0AGreetin=
gs=0AThomas Weidner, I18N Team Leader, Zend Framework=0Ahttp://www.thomaswe=
idner.com=0A=0A----- Original Message ----- From: "Daniel Lo" <wilburlo@gma=
il.com>=0ATo: "Thomas Weidner" <[email-masked]>=0ASent: Tuesday, Jul=
y 28, 2009 8:00 AM=0ASubject: Re: [zf-contributors] Contributor list=0A=0A=
=0AHello Thomas,=0A=0AHow do we edit this page? or do we turn in this infor=
mation to you personally?=0A=0A-daniel=0A=0AJira: danlo=0A=0AMonday, July 2=
7, 2009, 8:25:10 AM, you wrote:=0A=0A> Hy all,=0A=0A> we have since several=
 months a contributor list.=0A> http://framework.zend.com/wiki/pages/viewpa=
ge.action?pageId=3D11036=0A=0A> Now for 1.9 it's time again to update this =
list.=0A> Every contributor/maintainer/component lead is announced to updat=
e this list=0A> with his own informations within the proper component.=0A=
=0A> Greetings=0A> Thomas Weidner, I18N Team Leader, Zend Framework=0A> htt=
p://www.thomasweidner.com=0A=0A=0A=0A=0A-- Best regards,=0ADaniel          =
                  mailto:[email-masked] =0A
--0-1012628341-1248779138=:54388
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Hi Thomas,<br><br>Just a reference to something I edited while=
 adding myself since I'm unclear on how it should be handled. In components=
 with muliple parts (for example Zend_Feed also hosts the completely indepe=
ndent Zend_Feed_Reader) we may not have a single lead. In that case was it =
okay for me to add Zend_Feed_Reader as a separate entry on the table? Easil=
y reversed if not :).<br><br>Paddy<br><div>&nbsp;</div><span style=3D"color=
: rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new york,tim=
es,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br=
><br></span></font><span style=3D"font-style: italic;"><font style=3D"font-=
family: times new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollo=
w" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font =
size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><span style=3D"font-weight: bo=
ld;">From:</span></b> Thomas Weidner &lt;[email-masked]&gt;<br><b><s=
pan style=3D"font-weight: bold;">To:</span></b> [email-masked].=
com<br><b><span style=3D"font-weight: bold;">Sent:</span></b> Tuesday, July=
 28, 2009 8:12:05 AM<br><b><span style=3D"font-weight: bold;">Subject:</spa=
n></b> Re: [zf-contributors] Contributor list<br></font><br>=0ALike for all=
 other pages within our wiki you need to login.<br>It's the same process as=
 if you edit one of your proposals.<br><br>Greetings<br>Thomas Weidner, I18=
N Team Leader, Zend Framework<br><span><a target=3D"_blank" href=3D"http://=
www.thomasweidner.com">http://www.thomasweidner.com</a></span><br><br>-----=
 Original Message ----- From: "Daniel Lo" &lt;<a ymailto=3D"mailto:wilburlo=
@gmail.com" href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<b=
r>To: "Thomas Weidner" &lt;<a ymailto=3D"mailto:[email-masked]" href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>Sent: Tu=
esday, July 28, 2009 8:00 AM<br>Subject: Re: [zf-contributors] Contributor =
list<br><br><br>Hello Thomas,<br><br>How do we edit this page? or do we tur=
n in this information to you personally?<br><br>-daniel<br><br>Jira: danlo<=
br><br>Monday, July 27, 2009, 8:25:10 AM, you wrote:<br><br>&gt; Hy all,<br=
><br>&gt; we have since several months a contributor
 list.<br><span>&gt; <a target=3D"_blank" href=3D"http://framework.zend.com=
/wiki/pages/viewpage.action?pageId=3D11036">http://framework.zend.com/wiki/=
pages/viewpage.action?pageId=3D11036</a></span><br><br>&gt; Now for 1.9 it'=
s time again to update this list.<br>&gt; Every contributor/maintainer/comp=
onent lead is announced to update this list<br>&gt; with his own informatio=
ns within the proper component.<br><br>&gt; Greetings<br>&gt; Thomas Weidne=
r, I18N Team Leader, Zend Framework<br>&gt; <a href=3D"http://www.thomaswei=
dner.com" target=3D"_blank">http://www.thomasweidner.com</a><br><br><br><br=
><br>-- Best regards,<br>Daniel&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; mailto:<a ymailto=3D"=
mailto:[email-masked]" href=3D"mailto:[email-masked]">wilburlo@gmai=
l.com</a> <br></div></div></div></body></html>
--0-1012628341-1248779138=:54388--

nFrom nobody Wed Apr  7 08:46:11 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 16:37:55 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

-- Court Ewing <[email-masked]> wrote
(on Monday, 15 March 2010, 04:21 PM -0400):
> I think adjective/noun names for interfaces are ideal because they are far more
> inline with the naming conventions already used in SPL, and I think that is
> something we should be striving to do wherever possible.
> 
> I support prefixes for abstract classes rather than suffixes, but it seems that
> has long been shot down as an option.
> 
> Regardless of whether we do prefixes or suffixes though, I think we should use
> the word "Abstract" rather than "Base".  All programmatic dogma aside, if I
> were to describe an abstract class to someone else (take an abstract Triangle
> class), I would tell the person that this is an abstract representation of a
> triangle; I wouldn't say it is a base representation of a triangle.  If you're
> going to cite hungarian notation as the reason for not using the word
> "abstract", then I don't know how you can justify using any keyword to denote
> that it is abstract.

Excellent and well-considered reply -- thanks!

> On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[email-masked]>
> wrote:
> 
>     Hey, all --
> 
>     I know this has been hashed out a fair bit already, and we've already
>     established some guidelines, but as I play with code for ZF2, I'm
>     beginning to question the naming conventions for Interfaces and Abstract
>     Classes.
> 
>     When we made the decisions before, we were looking at the following
>     three options for interfaces:
> 
>      1. Prefix interfaces with "I" ("IFoobar").
>      2. Suffix interfaces with "Interface" ("FoobarInterface")
>      3. Use adjective/noun names such as "Foobarable", "Foobarist"
> 
>     For abstract classes, we looked at:
> 
>      4. Prefix abstract classes with "A" ("AFoobar")
>      5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>      6. Prefix abstract classes with "Base" ("BaseFoobar")
>      7. Suffix abstract classes with "Base" ("FoobarBase")
>      8. Use normal class names ("Foobar")
> 
>     Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
>     they smack of Hungarian Notation, the long forms lead to really long
>     names, etc. Prefixing can lead to similar classes not being grouped when
>     doing directory listings (i.e., all abstract class or interface files
>     get clustered together). Also, for classes beginning with "I" or "A",
>     there can potentially be confusion over whether or not the given class
>     is supposed to be concrete. Finally, during refactoring, if you choose
>     to make an interface an abstract class or concrete class, or an abstract
>     class an interface or concrete class, you can't do so without renaming
>     files and classes. (That said, you'll most likely need to make other
>     changes anyways -- and ZF will likely never make an interface an
>     abstract class or vice versa.)
> 
>     Regarding 3 and 8, the primary problems are that it's often hard to come
>     up with meaningful names that do not conflict with concrete
>     implementations, and that for non-native English speakers, this latter
>     problem becomes an even bigger obstacle. Additionally, you can't
>     determine which files contain abstract classes and/or interfaces just by
>     the filename -- you have to look in the file or look in API
>     documentation to determine this information.
> 
>     Now, as to the issues I've seen: the word "Interface" becomes a real
>     pain to type (yes, even with autocompletion), and it doesn't really
>     connote any real information. When type-hinting, I simply know what type
>     I want to use -- the name doesn't need to tell me it's an interface, as
>     I already know that information. If I'm writing code that consumes or
>     interacts with the class, API docs will tell me what I need to do.
> 
>     That said, I don't use Abstract classes that often, but considering they
>     are a foundation on which to build concrete classes (presumably to take
>     care of many of the nitty gritty details and leave the concrete classes
>     to implement specifics), I don't mind using a class suffix. "Abstract"
>     feels like Hungarian notation, though.
> 
>     Based on my experiences writing code, I'm currently recommending that we
>     do the following:
> 
>      3. Use adjective/noun names for Interfaces such as "Foobarable",
>        "Foobarist"
>      7. Suffix abstract classes with "Base" ("FoobarableBase")
> 
>     The above solve most issues - names are reasonably sized, don't smack of
>     Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
>     most importantly, meaningful. Since we already implement code review for
>     any code coming into trunk, I think we can even solve the issues for
>     non-native speakers as well.
> 
>     Thoughts? Votes?
> 
>     --
>     Matthew Weier O'Phinney
>     Project Lead            | [email-masked]
>     Zend Framework          | http://framework.zend.com/
>     PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> 
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Wed, 31 Mar 2010 22:04:28 +0200
Subject: Re: [zf-contributors] Plugin implementations

-1 from me

I see no benefit of having 2 methods doing the same work

Additionally forcing __invoke() means that ZF does no longer work below P=
HP=20
5.3.
Even if we limit ZF 2.0 to 5.3 it does not mean that single components ar=
e=20
not able to work below 5.3.

And working with OOP I see no benefit of using objects by calling them as=
=20
function. It's like a step backwards from OOP.

my 3 cents

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Lukas K=F6ll" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 31, 2010 9:38 PM
Subject: Re: [zf-contributors] Plugin implementations

-1 from me, too - I'm totally agreeing with Renan.
Additionally I don't think design decisions should be based on how much w=
ork=20
it
is to write the corresponding unit tests. Don't get me wrong, of course t=
he=20
code
must be testable. But especially for framework code I think that a low=20
overhead
should be preferred against easier testability - infact framework code is
written (or changed) far more seldom than executed.

If, however you decide to use __invoke as proxy, I would recommend to=20
somehow
prevent the proxied methods (filter, validate) to be called from outside =
or=20
at least mark them as deprecated
so client code _must_ use invoke and we could then remove the proxies lat=
er=20
on if
it should be decided that the tests are rewritten.

best regards

Lukas K=F6ll

> -1
>
> Talking to my coworkers, a big piece of people take a little more time
> to understand something when there is more than one way to do what
> they want to do. I think that when we start a new project with
> unnecessary duplicated features it's not good. This usually happens
> after years, we should get this situations away. Obviously sometimes
> it's interesting we provide alternative ways to achieve a goal, but
> for those situations  (filter, validator...) it's not.
>
>>> The benefits:
>>>
>>> * Fewer changes necessary to existing unit tests
>
> time is the solution ;-)
>
>>> * interface method names may be more descriptive of intent
>
> they should pick a better name for their variables, like $filterFloat,
> $filterAlpha
>
>>> Problems:
>>>
>>> * Using __invoke() introduces overhead -- 2 method calls instead of o=
ne
>>> * Redundancy (two methods doing the same thing)
>
> that's my point! this extra way is not relevant, this one adds no new=20
> feature
>
>>> * A few extra tests to write (to ensure __invoke works as expecte)
>
> my 1 cent ;-)
>
> --
> Renan de Lima Barbosa
> gtalk/msn: [email-masked]
> skype: renandelima
> +55 61 8166-7755
> renandelima.com
>
>
>
> On 31 March 2010 11:38, Dennis Winter <[email-masked]>=
=20
> wrote:
>> +1 on this! It's ok to have two methods for the same thing! And the=20
>> benefit
>> of clearer interfaces is overwhelming the disadvantages!
>> Just my 2 cents!
>>
>> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney=20
>> <[email-masked]>:
>>
>>> Greetings, all --
>>>
>>> Per the roadmap, one change we're planning on making is making plugin
>>> usage consistent across components: plugins will implement __invoke()=
,
>>> which makes them inherently callable.
>>>
>>> In our refactoring branch, I've done this now with Zend_Filter. Howev=
er,
>>> it required a ton of refactoring on the unit tests (had to either cal=
l
>>> __invoke() directly, or $filter($value)), and it got me to thinking:
>>>
>>> Would it make sense to keep the original interfaces (filter, isValid,
>>> render, etc.), but also implement __invoke() -- having it proxy to th=
e
>>> appropriate interface method?
>>>
>>> As an example:
>>>
>>>   interface Filter
>>>   {
>>>       public function filter($value);
>>>       public function __invoke($value);
>>>   }
>>>
>>>   class Digits implements Filter
>>>   {
>>>       public function filter($value)
>>>       {
>>>           // ... logic...
>>>       }
>>>
>>>       public function __invoke($value)
>>>       {
>>>           return $this->filter($value);
>>>       }
>>>   }
>>>
>>> The benefits:
>>>
>>> * Fewer changes necessary to existing unit tests
>>> * interface method names may be more descriptive of intent
>>>
>>> Problems:
>>>
>>> * Using __invoke() introduces overhead -- 2 method calls instead of o=
ne
>>> * Redundancy (two methods doing the same thing)
>>> * A few extra tests to write (to ensure __invoke works as expecte)
>>>
>>> After discussion with Ralph and Alex, I'm leaning towards having
>>> __invoke() as an _additional_ method, instead of replacing existing
>>> methods.
>>>
>>> Any thoughts or comments?
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> Project Lead            | [email-masked]
>>> Zend Framework          | http://framework.zend.com/
>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>=20

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 13 Mar 2010 00:26:22 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] ZF 2.0 Status: 10 Mar 2010

David Abdemoulaie wrote on 12.03.2010 23:42:
> On Mar 12, 2010, at 4:37 PM, A.J. Brown wrote:
> 
>> I'm not sure about the requirement for autoloading in _unit_ tests. 
>> Autoloading adds another layer of code that's not directly related to
>> the unit under test.  A bug in AutoLoading could directly affect the
>> outcome of another unit test.  Imagine a situation where the wrong
>> class is autoloaded in the middle of a test, but it just so happens to
>> work out.  
> 
> This is a good point. I think it's important to be able to look at a
> unit test and see /exactly/ what's going on instead of relying on what
> the framework to take care of it (you hope).
> 
> --
> David Abdemoulaie
> http://hobodave.com

I don't see a real problem here, especially because we'll get native
autoloader support by SPL in the near future, where Zend\Loader won't be
(mostly) neccessary anymore.

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 14 Mar 2010 18:25:51 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 10 Mar 2010

-- A.J. Brown <[email-masked]> wrote
(on Friday, 12 March 2010, 05:37 PM -0500):
> Glad to see things moving along with ZF 2.0!
> 
> I'm not sure about the requirement for autoloading in _unit_ tests. 
> Autoloading adds another layer of code that's not directly related to the unit
> under test.  A bug in AutoLoading could directly affect the outcome of another
> unit test.  Imagine a situation where the wrong class is autoloaded in the
> middle of a test, but it just so happens to work out. 
> 
> Of course, autoloading should be incorporated in more comprehensive tests.
> 
> Thoughts?

The autoloading is regarding autoloading of the ZF components within the
tests themselves. Since the autoloader is already tested, this simply
works; if we start seeing issues within the testbed, then we have new
test cases to add to the autoloader.

Additionally, if we don't do autoloading, then the test cases become
more difficult, as the library is designed for autoloading. Since the
class files themselves do not have require_once statements in them, we
would have to go and create the entire list of equivalent require_once
statements necessary to load all dependencies -- which would also
introduce potential issues, and a ton of overhead for those testing the
systems.

We already have autoloading working perfectly with the test suite, by
the way (you can verify this by checking out the development-2.0
branch); I see no reason to change this.

> On Wed, Mar 10, 2010 at 4:48 PM, Matthew Weier O'Phinney <[email-masked]>
> wrote:
> 
>     Greetings!
> 
>     Since the last update, myself and the team have been busy working on the
>     test suite. We had the following goals:
> 
>      * Strip (most) require_once calls
>       If we're going to be an autoloading framework, unit tests should use
>       autoloading as well.
> 
>      * Remove all AllTests.php files
>       These are largely a relic of the early days of ZF development, and
>       are not really needed anymore. You can specify specific directories
>       in which to run tests, individual files, by group, and more;
>       additionally, there are better tools for building test suites.
> 
>      * Create a phpunit.xml and test bootstrap
>       This will allow us to specify rules for running tests, as well as the
>       actual test environment for every test case.
> 
>      * Have all tests passing (or at least in the same state as trunk)
> 
>     Ralph is working on Zend_Tool tests as I write this -- but that's the
>     last component to be reviewed. Otherwise, all the tasks above are now
>     accomplished. To run any tests, you simply change directory to the
>     tests/ subdirectory, and then call phpunit with any arguments you want
>     to specify (including directories or files).
> 
>     Additionally, we've made some changes to Zend_Loader_Autoloader. Since
>     ZF users will likely be using both code with true PHP namespaces as well
>     as code using simply pre-5.3 style vendor prefixes, we introduced a set
>     of "registerPrefix" methods. The old familiar "registerNamespace"
>     methods will now work only for classes using PHP namespace notation.
>     This is definitely a BC break, but one that should be fairly trivial to
>     script a fix for in existing codebases.
> 
>     Next on our list of "foundational tasks" to tackle:
> 
>      * Conversion to namespaces
>      * Refactoring of exceptions
> 
>     These tasks will likely take longer than what we've done to date. We are
>     aiming to balance automatic conversion, code readability, and
>     performance -- and I'm not expecting a good solution to present itself
>     on our first few tries.
> 
>     Until next time, happy programming!
> 
>     --
>     Matthew Weier O'Phinney
>     Project Lead            | [email-masked]
>     Zend Framework          | http://framework.zend.com/
>     PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> 
> 
> 
> 
> --
> A.J. Brown
> Software Engineer, ZCE
> blog : http://ajbrown.org
> talk  : (937) 540-0099
> chat : IntypicaAJ

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 21 Mar 2010 22:44:04 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

-- Giorgio Sironi <[email-masked]> wrote
(on Sunday, 21 March 2010, 03:15 PM +0100):
> From the wiki guidelines I thought the direct() method would be
> enforced in the Zend_View_Helper_Interface.

Yes -- this is exactly the idea, and the reason we started defining
this. (Currently, however, we do not support it in any meaningful way.)

I'm trying to decide if "direct" (which suggests strategy) or
"execute" makes more sense for the method name.

> Anyway, the workaround I use in the meantime is defining __call() to
> catch the helperBaseName() method call.

Interesting workaround. :)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Thu, 1 Oct 2009 21:27:15 +0200
Subject: [zf-contributors] Google Wave - public waves, tagging, contacts

One you guys get on Wave, at first you=C2=B4ll notice there's nothing much =
to do.=20
Your contact list may be empty and there may only be the "welcome" waves in=
=20
your inbox.

Quick start
=2D----------

Waves can be both private and public, to find public waves enter the query=
=20
term "with:public" in the search bar at the top of the wave list. You can=20
further refine the search by adding tags e.g. "with:public tag:help".

There are a few useful waves copied over from the sandbox, probably the mos=
t=20
useful at the moment is the "Wave FAQ", search for "with:public tag:faq".

Tagging
=2D------

It would of course seem sensible to tag anything related to Wave + ZF as=20
simply "zf" or "ZF", I'm not sure if tags and search by tag is case sensiti=
ve.=20
Multiple tags are of course supported.

Making a wave public
=2D-------------------

At the moment you can participate in a wave by either being added manually =
by=20
one of the existing wave participants, or by searching for a wave and then=
=20
contributing. If you are not added manually by someone else who may think t=
he=20
wave will be of interest to you, you can only discover a wave if it is made=
=20
public.

To make a wave public for now you need to add the special participant,=20
[email-masked]

You may find it convenient to add [email-masked] to your contacts, when=
=20
you try to do so the contact applet will tell you this is not a valid wave=
=20
address but just hit enter and it will be added anyway.

Contacts
=2D-------

Your Wave address will be the first part of your gmail/google account follo=
wed=20
by googlewave.com, e.g. My gmail address is [email-masked] so my=
=20
Wave contact address is [email-masked].

The contact applet within wave has some bugs, profile/avatar pics is flaky,=
=20
and contact management redirects you to your main google account contacts. =
It=20
doesn't seem possible to manage your wave contacts from here yet.

Searching for contacts is either suffering from the current lag/load levels=
 or=20
is just broken. To that end I'll create a public wave, tagged with "zf" as =
a=20
work-around contact list, edit the blip with known ZF'ers Wave contact deta=
ils=20
to add your own once you Wave account is activated.

See you soon on Wave :)

=2D-=20
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D
 =E2=98=98 Oscar Wilde

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 03 Aug 2009 13:09:29 -0700
From: Christoph Dorn <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [zf-contributors] Zend_Dom_Query & DOMDocument

Would it make sense to initialize the DOMDocument in the setDocument() 
method of Zend_Dom_Query instead of on every queryXpath() call?

The document is needed to make any queries and in my Zend_Dom_Query 
subclass I need access to the DOMDocument to make changes to it and be 
able to query it again efficiently.

Christoph

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 28 Jul 2009 10:32:44 -0400
From: Jon Whitcraft <[email-masked]>
To: Thomas Weidner <[email-masked]>
Cc: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>,
	Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Contributor list

Everyone,

I just added the Ec2, S3 and Twitter Service to that page.  The proposal=20
for Ec2 never got asigned a Zend Liaison so I didn't know what to put in=20
that field.

Thomas Weidner wrote:
> Hy P=E1draic,
>
> Feel free to edit this list to reflect also your component.
> Just add a new line with the informations of this component.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "P=E1draic Brady"=20
> <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>
> Cc: "Zend Framework Contributors" <[email-masked]>
> Sent: Tuesday, July 28, 2009 1:05 PM
> Subject: Re: [zf-contributors] Contributor list
>
>
> Hi Thomas,
>
> Just a reference to something I edited while adding myself since I'm=20
> unclear on how it should be handled. In components with muliple parts=20
> (for example Zend_Feed also hosts the completely independent=20
> Zend_Feed_Reader) we may not have a single lead. In that case was it=20
> okay for me to add Zend_Feed_Reader as a separate entry on the table?=20
> Easily reversed if not :).
>
> Paddy
>
> P=E1draic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>
>
>
>
>
> ________________________________
> From: Thomas Weidner <[email-masked]>
> To: [email-masked]
> Sent: Tuesday, July 28, 2009 8:12:05 AM
> Subject: Re: [zf-contributors] Contributor list
>
> Like for all other pages within our wiki you need to login.
> It's the same process as if you edit one of your proposals.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "Daniel Lo" <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>
> Sent: Tuesday, July 28, 2009 8:00 AM
> Subject: Re: [zf-contributors] Contributor list
>
>
> Hello Thomas,
>
> How do we edit this page? or do we turn in this information to you=20
> personally?
>
> -daniel
>
> Jira: danlo
>
> Monday, July 27, 2009, 8:25:10 AM, you wrote:
>
>> Hy all,=20
>
>> we have since several months a contributor list.
>> http://framework.zend.com/wiki/pages/viewpage.action?pageId=3D11036=20
>
>> Now for 1.9 it's time again to update this list.
>> Every contributor/maintainer/component lead is announced to update=20
>> this list
>> with his own informations within the proper component.=20
>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com=20
>
>
>
>
> -- Best regards,
> Daniel                            mailto:[email-masked]=20

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 12 Apr 2009 18:05:33 +0200
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

Hey Matthew,

I'm currently reworking Zend_Tag to fit those new naming. I renamed
Zend_Tag_IItem to Zend_Tag_Taggable, which sounds good. But now for the
following two abstract classes:

Zend_Tag_Cloud_Decorator_Cloud
Zend_Tag_Cloud_Decorator_Tag

How would you name them? I had the following in mind, but I'm not sure:

Zend_Tag_Cloud_Decorator_CloudCore
Zend_Tag_Cloud_Decorator_TagCore

As those just substitute "Abstract" with "Core" then. Any thoughts on that?

Ben
...................................
:  ___   _   ___ ___ ___ _ ___    :
: |   \ /_\ / __| _ \ _ (_)   \   :
: | |) / _ \\__ \  _/   / | |) |  :
: |___/_/:\_\___/_| |_|_\_|___/   :
:........:........................:
: Web    : http://www.dasprids.de :
: E-mail : [email-masked]       :
: Jabber : [email-masked]     :
: ICQ    : 105677955              :
:........:........................:

Matthew Weier O'Phinney schrieb:
> Greetings, all --
> 
> Below is a proposal I am making to modify the Zend Framework Coding
> Standards conventions for the naming of Interfaces and Abstract classes.
> 
> This decision is basically already made, but I'd appreciate any feedback
> that you may have on the matter.
> 
> Thanks!
> 
> The problem
> ===========
> PHP 5.3 introduces namespaces to the PHP language. While this won't have an
> impact much on userland code, it will have an impact on library and framework
> code, as it provides a useful paradigm for organizing components as well as
> simplifying syntax. Instead of having to say things like:
> 
>     $analyzer = new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> 
> we can instead do something like this:
> 
>     namespace Zend\Search\Lucene\Analysis\Analyzer;
> 
>     $analyzer = new Common_TextNum();
> 
> or even:
> 
>     namespace Zend\Search\Lucene\Analysis\Analyzer;
> 
>     class Common_TextNum extends Common
>     {
>     }
> 
> The problem that arises for Zend Framework has to do with how we name abstract
> classes and interfaces. Currently, the final segment of such classes are
> expected to end with _Abstract and _Interface, respectively. This will not work
> when we migrate to utilize namespaces, for two reasons.
> 
> First, and most obviously, 'abstract' and 'interface' are reserved PHP keywords.
> As such, in situations such as the following:
> 
>     namespace Zend\Controller\Request;
> 
>     class Abstract
>     {
>     }
> 
>     // or:
> 
>     namespace Zend\Controller\Dispatcher;
> 
>     interface Interface
>     {
>     }
> 
> we'll run into issues.
> 
> Second, and less obvious, is that perhaps the easiest solution breaks one of the
> key principles of namespaces (which are designed to help encapsulate
> components). This one's harder to explain, so let's look at examples. Consider a
> component such as Zend_Controller_Request. The simplest solution would be to
> name the abstract class or interface Zend\Controller\Request, and then have the
> various concrete implementations under that namespace:
> 
>     namespace Zend\Controller;
> 
>     interface Request
>     {
>     }
> 
>     // and concrete ones:
> 
>     namespace Zend\Controller\Request;
> 
>     class Http
>     {
>     }
> 
> What's the problem here? The interface is not in the same namespace as the
> concrete implementations.
> 
> Potential solutions and recommendation
> ======================================
> So, how should Zend Framework "solve" these issues? A number of proposals and
> recommendations have been floated around, both within ZF circles and in the
> greater PHP community. 
> 
> Considerations include:
> 
>  * Avoiding the use of PHP reserved keywords (already noted).
>  * Avoiding Hungarian Notation (i.e., having the name or a portion of the name
>    describe its type -- which, to a degree, the current naming conventions
>    already violate). (See http://en.wikipedia.org/wiki/Hungarian_Notation, the
>    sections "Disadvantages of Systems Hungarian" and "Notable Opinions" for some
>    of the arguments against using Hungarian Notation.)
> 
> Approaches that have been considered include:
> 
>  * Using 'I' to prefix interfaces. This derives from standards in other
>    programming languages (.Net and python, in particular). This is just another
>    form of Hungarian Notation, however.
> 
>  * Using "Interface" or "Abstract" as a class name suffix: RequestInterface,
>    RequestAbstract. Again, however this is Hungarian Notation.
> 
>  * Using the term "Base" for abstract classes: BaseRequest, RequestBase, Base.
>    This is just substituting the word Base for Abstract, however, and is really
>    not much different than the above.
> 
>  * Use generic, descriptive names indicative of functionality or behavior. As
>    examples from the SPL, "Countable", "Iterator", "ArrayObject".  
>    
> My recommendation is to use the latter, as it solves all considerations. It will
> take more thought when naming, but will ensure that components can live in a
> self-contained namespace, do not use reserved keywords, and avoid Hungarian
> Notation.
> 
> Plan for implementation
> =======================
> I recommend that the Coding Standards documentation be updated to reflect this
> approach. 
> 
> All new components going into 1.8 and onwards should adopt these standards. In
> releases 1.9 and forward, we will begin migrating existing interfaces/abstract
> classe. First, new classes/interfaces will be created that follow these
> conventions and which extend the originals; later, any type-hinting based on the
> original class/interface names will be updated to point to the new names; and
> finally, in 2.0, we will remove the old interfaces/abstract classes entirely.
> 

nFrom nobody Wed Apr  7 08:46:12 2010
Date: Tue, 19 Jan 2010 23:39:01 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
CC: Matthew Weier O'Phinney <[email-masked]>
Subject: requirements (documentation) of Zend_Serializer

Hi all,

I added the requirements of Zend_Serializer to trunk but these files are
completely different to that in 1.10 branch.
Is there some work on it ?

Greetings
Marc

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Sun, 5 Jul 2009 17:31:55 +0200
Subject: Re: [zf-contributors] Re: [fw-mvc] Two Proposals Ready for Review

to my knowledge there will definately be a 1.10, and even a slight chance that 
there will be a 1.11

greetings,
Benjamin

On Sunday 05 July 2009 02:48:38 pm Ralf Eggert wrote:
> Hi,
>
> just want to step in here:
>
> Whitcraft, Jon schrieb am 02.07.2009 14:40:
> > Please comment on these proposals so we can get the ball rolling for 1.9
> > or 1.10
>
> Are there any plans for a 1.10 release yet? I thought 1.9 will be the
> last minor release before 2.0?
>
> Thanks and best regards,
>
> Ralf

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 14 Dec 2009 04:58:29 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: takeshin <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Re: [fw-general] HTMLPurifier and autoloader

--0-265431786-1260795509=:96339
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

It's a bit like Doctrine - you can also register its own autoloader to the =
autoloader stack.=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumf=
utura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Iri=
sh Representative=0A=0A=0A=0A=0A=0A________________________________=0AFrom:=
 takeshin <[email-masked]>=0ATo: [email-masked]=0ASent: Mon, =
December 14, 2009 12:24:26 PM=0ASubject: [fw-general] HTMLPurifier and auto=
loader=0A=0A=0AHow do you setup HTMLPurifier and ZF?=0AIs require_once('Htm=
lPurifer.auto.php'); really needed?=0A=0A-- =0Aregards=0Atakeshin=0A-- =0AV=
iew this message in context: http://n4.nabble.com/HTMLPurifier-and-autoload=
er-tp963488p963488.html=0ASent from the Zend Framework mailing list archive=
 at Nabble.com.=0A
--0-265431786-1260795509=:96339
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">It's a bit like Doctrine - you can also register its own autol=
oader to the autoloader stack.<br><br>Paddy<br><div>&nbsp;</div><span style=
=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new=
 york,times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic=
 Brady<br><br></span></font><span style=3D"font-style: italic;"><font style=
=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><a rel=
=3D"nofollow" target=3D"_blank" href=3D"http://blog.astrumfutura.com">http:=
//blog.astrumfutura.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=
=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com</a><=
br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideurope.eu=
/">OpenID Europe Foundation Irish Representative</a><br></font></span></spa=
n><div><br></div><div
 style=3D"font-family: times new roman,new york,times,serif; font-size: 12p=
t;"><br><div style=3D"font-family: tahoma,new york,times,serif; font-size: =
8pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"fon=
t-weight: bold;">From:</span></b> takeshin &lt;[email-masked]&gt;<br><b>=
<span style=3D"font-weight: bold;">To:</span></b> [email-masked]=
<br><b><span style=3D"font-weight: bold;">Sent:</span></b> Mon, December 14=
, 2009 12:24:26 PM<br><b><span style=3D"font-weight: bold;">Subject:</span>=
</b> [fw-general] HTMLPurifier and autoloader<br></font><br>=0A<br>How do y=
ou setup HTMLPurifier and ZF?<br>Is require_once('HtmlPurifer.auto.php'); r=
eally needed?<br><br>-- <br>regards<br>takeshin<br>-- <br><span>View this m=
essage in context: <a target=3D"_blank" href=3D"http://n4.nabble.com/HTMLPu=
rifier-and-autoloader-tp963488p963488.html">http://n4.nabble.com/HTMLPurifi=
er-and-autoloader-tp963488p963488.html</a></span><br>Sent from the Zend Fra=
mework mailing list archive at <a target=3D"_blank" href=3D"http://Nabble.c=
om">Nabble.com</a>.<br></div></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com comp=
ressed/chunked Thu Dec 10 10:20:48 PST 2009 -->=0A</div></body></html>
--0-265431786-1260795509=:96339--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 10:03:37 -0800
From: Matthew Ratzloff <[email-masked]>
To: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--0016362837222150640480709ae4
Content-Type: text/plain; charset=UTF-8

Perhaps you don't do a lot of merging?  I'm constantly merging feature
branches into trunk and even in Subversion 1.5+ this can be problematic,
nevermind branching from branches.  This is the exact reason we've begun
moving to Git at my workplace (many of us use it for personal development
already).

-Matt

On Thu, Feb 25, 2010 at 8:44 AM, Luke Crouch <[email-masked]> wrote:

> Maybe I'm turning into a crotchety old programmer, but I'm not really
> impressed with git. We switched from svn to git at my day job and I
> haven't really seen any big benefits aside from a few sweet syntactic
> shortcuts like git stash. For larger projects with well-organized
> branching I just haven't seen much additional value from git.
>
> -L
>
> On Thu, Feb 25, 2010 at 10:27 AM, Julien Pauli <[email-masked]>
> wrote:
> > Well, as far as there is a reference guide for GIT for those who never
> > used it (me, for example), why not...
> >
> > J.Pauli
> >
> > On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]>
> wrote:
> >> Moving from SVN to Git seems like quite a major switch. But, with the
> step
> >> from 1.X to 2.0 it seems like a good time to do it. I like the idea (as
> >> David Caunt mentioned) of releasing a 1.X branch with Doctrine 1 to test
> the
> >> waters and judging by the amount of work required decide to go with
> Doc2+ZF2
> >> when the time comes. It's an exciting time to work with ZF and I'm
> looking
> >> forward to a time when ZF2 uses Git and Doctrine 2.
> >>
> >>
> >> On Thu, Feb 25, 2010 at 5:20 AM, Matthew Weier O'Phinney <
> [email-masked]>
> >> wrote:
> >>>
> >>> -- David Caunt <[email-masked]> wrote
> >>> (on Thursday, 25 February 2010, 11:13 AM +0000):
> >>> > Integration of Doctrine 1 with ZF 1.11 might be a good way to test
> the
> >>> > water and then community feedback may inform ZF2's integration with
> >>> > Doctrine 2.
> >>> >
> >>> > As keen as I am for ZF2, I think the amount of work to be done on the
> >>> > core is substantial and probably leaves enough time for a 1.11
> >>> > release.
> >>>
> >>> Well, that's what we're trying to gauge at this point. It seems like a
> >>> substantial amount of work, but if the initial development I outlined
> >>> goes quickly, we may find ourselves working on the various
> >>> rewrites/refactors much sooner, which could lead to an earlier release.
> >>> Then again, it may take much longer, meaning a delay. I don't want to
> >>> make a call either way yet, and thus the uncertainty about a 1.11
> >>> release.
> >>>
> >>> If we end up deciding to do a 1.11 branch, we'll very likely look at
> >>> doing integration with Doctrine 1.2 for the very reasons you describe,
> >>> but also to serve as an upgrade path for ZF users.
> >>>
> >>> > Are there any plans to maintain the 1.x series once 2.0 is released?
> >>>
> >>> This is another area we're trying to gauge -- whether to continue
> >>> maintenance on the 1.X branch following a 2.0 release.
> >>>
> >>> My personal feeling is that if we do, any future releases would address
> >>> only critical bugs or security issues, and no new features. As long as
> >>> we develop new features on the 1.X series, we'll hamper adoption of
> 2.0.
> >>> In this vein, we'd likely do like the PHP project did, and do a new
> >>> minor release on the version 1 branch simultaneous to 2.0 that would be
> >>> for tracking those issues.
> >>>
> >>> If we do, I'll likely look for a small team from the community to
> assist
> >>> as release masters for that branch.
> >>>
> >>>
> >>> > On 25 February 2010 10:46, Giorgio Sironi
> >>> > <[email-masked]>
> >>> > wrote:
> >>> >
> >>> >     On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley
> >>> > <[email-masked]>
> >>> >     wrote:
> >>> >
> >>> >         In my opinion if Doctrine integration is to be left until ZF
> >>> > 2.0, then
> >>> >         the integrated version of Doctrine should be the 2.0 version.
> >>> > Since
> >>> >         both 2.0 versions will require PHP 5.3.
> >>> >
> >>> >
> >>> >     I agree. Doctrine 2 will fill the lack of model infrastructure in
> >>> > Zend
> >>> >     Framework.
> >>> >     Anyway, the set of changes listed by Matthew is already a big
> step
> >>> > towards
> >>> >     simpler development (exploiting phpunit new features for
> example.)
> >>> >
> >>> >     Regards,
> >>> >     --
> >>> >     Giorgio Sironi
> >>> >     Piccolo Principe & Web Engineer
> >>> >     http://giorgiosironi.blogspot.com
> >>> >     http://twitter.com/giorgiosironi
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Save Water...Drink Ouzo !
> >>>
> >>> --
> >>> Matthew Weier O'Phinney
> >>> Project Lead            | [email-masked]
> >>> Zend Framework          | http://framework.zend.com/
> >>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >>
> >>
> >
>

--0016362837222150640480709ae4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Perhaps you don&#39;t do a lot of merging? =C2=A0I&#39;m constantly merging=
 feature branches into trunk and even in Subversion 1.5+ this can be proble=
matic, nevermind branching from branches. =C2=A0This is the exact reason we=
&#39;ve begun moving to Git at my workplace (many of us use it for personal=
 development already).<div>
<br></div><div>-Matt<br><br><div class=3D"gmail_quote">On Thu, Feb 25, 2010=
 at 8:44 AM, Luke Crouch <span dir=3D"ltr">&lt;<a href=3D"mailto:luke.crouc=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex;">
Maybe I&#39;m turning into a crotchety old programmer, but I&#39;m not real=
ly<br>
impressed with git. We switched from svn to git at my day job and I<br>
haven&#39;t really seen any big benefits aside from a few sweet syntactic<b=
r>
shortcuts like git stash. For larger projects with well-organized<br>
branching I just haven&#39;t seen much additional value from git.<br>
<font color=3D"#888888"><br>
-L<br>
</font><div><div></div><div class=3D"h5"><br>
On Thu, Feb 25, 2010 at 10:27 AM, Julien Pauli &lt;<a href=3D"mailto:doctor=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; Well, as far as there is a reference guide for GIT for those who never=
<br>
&gt; used it (me, for example), why not...<br>
&gt;<br>
&gt; J.Pauli<br>
&gt;<br>
&gt; On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman &lt;<a href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt; Moving from SVN to Git seems like quite a major switch. But, with =
the step<br>
&gt;&gt; from 1.X to 2.0 it seems like a good time to do it. I like the ide=
a (as<br>
&gt;&gt; David Caunt mentioned) of releasing a 1.X branch with Doctrine 1 t=
o test the<br>
&gt;&gt; waters and judging by the amount of work required decide to go wit=
h Doc2+ZF2<br>
&gt;&gt; when the time comes. It&#39;s an exciting time to work with ZF and=
 I&#39;m looking<br>
&gt;&gt; forward to a time when ZF2 uses Git and Doctrine 2.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Feb 25, 2010 at 5:20 AM, Matthew Weier O&#39;Phinney &lt;<=
a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -- David Caunt &lt;<a href=3D"mailto:[email-masked]">dcaunt@=
gmail.com</a>&gt; wrote<br>
&gt;&gt;&gt; (on Thursday, 25 February 2010, 11:13 AM +0000):<br>
&gt;&gt;&gt; &gt; Integration of Doctrine 1 with ZF 1.11 might be a good wa=
y to test the<br>
&gt;&gt;&gt; &gt; water and then community feedback may inform ZF2&#39;s in=
tegration with<br>
&gt;&gt;&gt; &gt; Doctrine 2.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; As keen as I am for ZF2, I think the amount of work to be=
 done on the<br>
&gt;&gt;&gt; &gt; core is substantial and probably leaves enough time for a=
 1.11<br>
&gt;&gt;&gt; &gt; release.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Well, that&#39;s what we&#39;re trying to gauge at this point.=
 It seems like a<br>
&gt;&gt;&gt; substantial amount of work, but if the initial development I o=
utlined<br>
&gt;&gt;&gt; goes quickly, we may find ourselves working on the various<br>
&gt;&gt;&gt; rewrites/refactors much sooner, which could lead to an earlier=
 release.<br>
&gt;&gt;&gt; Then again, it may take much longer, meaning a delay. I don&#3=
9;t want to<br>
&gt;&gt;&gt; make a call either way yet, and thus the uncertainty about a 1=
.11<br>
&gt;&gt;&gt; release.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If we end up deciding to do a 1.11 branch, we&#39;ll very like=
ly look at<br>
&gt;&gt;&gt; doing integration with Doctrine 1.2 for the very reasons you d=
escribe,<br>
&gt;&gt;&gt; but also to serve as an upgrade path for ZF users.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; Are there any plans to maintain the 1.x series once 2.0 i=
s released?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This is another area we&#39;re trying to gauge -- whether to c=
ontinue<br>
&gt;&gt;&gt; maintenance on the 1.X branch following a 2.0 release.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; My personal feeling is that if we do, any future releases woul=
d address<br>
&gt;&gt;&gt; only critical bugs or security issues, and no new features. As=
 long as<br>
&gt;&gt;&gt; we develop new features on the 1.X series, we&#39;ll hamper ad=
option of 2.0.<br>
&gt;&gt;&gt; In this vein, we&#39;d likely do like the PHP project did, and=
 do a new<br>
&gt;&gt;&gt; minor release on the version 1 branch simultaneous to 2.0 that=
 would be<br>
&gt;&gt;&gt; for tracking those issues.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If we do, I&#39;ll likely look for a small team from the commu=
nity to assist<br>
&gt;&gt;&gt; as release masters for that branch.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; On 25 February 2010 10:46, Giorgio Sironi<br>
&gt;&gt;&gt; &gt; &lt;<a href=3D"mailto:[email-masked]">p=
[email-masked]</a>&gt;<br>
&gt;&gt;&gt; &gt; wrote:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 On Thu, Feb 25, 2010 at 9:08 AM, Ashley Bro=
adley<br>
&gt;&gt;&gt; &gt; &lt;<a href=3D"mailto:[email-masked]">ashley@ls12=
style.co.uk</a>&gt;<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 wrote:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 In my opinion if Doctrine int=
egration is to be left until ZF<br>
&gt;&gt;&gt; &gt; 2.0, then<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 the integrated version of Doc=
trine should be the 2.0 version.<br>
&gt;&gt;&gt; &gt; Since<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 both 2.0 versions will requir=
e PHP 5.3.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 I agree. Doctrine 2 will fill the lack of m=
odel infrastructure in<br>
&gt;&gt;&gt; &gt; Zend<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 Framework.<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 Anyway, the set of changes listed by Matthe=
w is already a big step<br>
&gt;&gt;&gt; &gt; towards<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 simpler development (exploiting phpunit new=
 features for example.)<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 Regards,<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 --<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 Giorgio Sironi<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 Piccolo Principe &amp; Web Engineer<br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 <a href=3D"http://giorgiosironi.blogspot.co=
m" target=3D"_blank">http://giorgiosironi.blogspot.com</a><br>
&gt;&gt;&gt; &gt; =C2=A0 =C2=A0 <a href=3D"http://twitter.com/giorgiosironi=
" target=3D"_blank">http://twitter.com/giorgiosironi</a><br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; --<br>
&gt;&gt;&gt; &gt; Save Water...Drink Ouzo !<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; Matthew Weier O&#39;Phinney<br>
&gt;&gt;&gt; Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a hre=
f=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt;&gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"=
http://framework.zend.com/" target=3D"_blank">http://framework.zend.com/</a=
><br>
&gt;&gt;&gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-k=
ey.asc" target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc<=
/a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>

--0016362837222150640480709ae4--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 4 Jun 2009 22:50:37 +0200
From: till <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] addScriptPath question

On Thu, Jun 4, 2009 at 10:14 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- till <[email-masked]> wrote
> (on Thursday, 04 June 2009, 07:11 PM +0200):
>> debugging some code, and I noticed that addScripPath (and ultimately
>> _addPath()) in Zend_View_Abstract always prepends the path. I was
>> trying to add script paths as a fall back -- if not found in this
>> module, fallback to default (or where the other path leads to). Any
>> idea if we could add this kind of behavior for 2.0?
>>
>> This is the code (from Zend/View/Abstract.php, _addPath()):
>>
>> =A0 =A0 =A0 =A0 switch ($type) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case 'script':
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // add to the top of the stack.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 array_unshift($this->_path[$type=
], $dir);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>
> The behaviour of Zend_View is such that what you describe as what you
> want is how it should work. Basically, it searches the registered paths
> until it finds a matching view script.
>
> Am I missing something here?

My question was if we can add something to append the path, instead of
pre-pending it.

I'm in, Foo_IndexController::init(), I do:
$this->addScriptPath('/path/app/module/default/views/scripts');

Then I request /foo/index/index:

It should be:
app/modules/foo/views/scripts/index/index.phtml

But with the addScriptPath() to my default module, it will instead use:
app/modules/default/views/scripts/index/index.phtml

Reason why I wanted this was a fallback to, e.g. I am pulling a
another view script view $this->render('index/__header.phtml') it
would use the one inside the Foo module, but if there is none, it
would fallback to the default module.

>> Sort of related, it would be nice if there were no private methods in
>> that class. ;-(
>
> Dude, this has been covered *so* many times, and it even has a section
> in the manual covering the "why" of the design:
>
> =A0 =A0http://framework.zend.com/manual/en/zend.view.abstract.html
>
> Short answer: the private methods are not going away, as they are an
> important implementation detail.

Yeah, I actually found an issue in Jira but besides I didn't see the
above documentation.

Having read that and the issue in Jira. I still don't like it. =3D) I
need to jump through hoops so someone doesn't override something
because he got no idea. Using the interface is just pure overkill when
you want to change the behavior of a single method. All of the sudden
I need to implement my own view, essentially duplicate code, etc..

Jason essentially provided the workaround I am using already. I just
didn't like having to re-stack the arrays, was looking for something a
little nicer.

Till

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 20 Jan 2010 19:18:54 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Re: requirements (documentation) of
	Zend_Serializer

This is a multi-part message in MIME format.
--------------020604080306020004020009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Mickael
Now I merged the Zend_Serializer requirements to 1.10 branch.

Marc

Am 20.01.2010 16:58, schrieb mkk:
> I added these changes. I will merge them ASAP.
>
> Mickael
>
>     > Message du 20/01/10 15:26
>     > De : "Matthew Weier O'Phinney"
>     > A : [email-masked]
>     > Copie =C3=A0 :
>     > Objet : [zf-contributors] Re: requirements (documentation) of
>     Zend_Serializer
>     >
>     >
>     > -- Marc Bennewitz wrote
>     > (on Tuesday, 19 January 2010, 11:39 PM +0100):
>     > > I added the requirements of Zend_Serializer to trunk but these
>     files are
>     > > completely different to that in 1.10 branch.
>     > > Is there some work on it ?
>     >
>     > Merge the changes to the 1.10 branch, please.
>     >
>     > --
>     > Matthew Weier O'Phinney
>     > Project Lead | [email-masked]
>     > Zend Framework | http://framework.zend.com/
>     > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>     >
>     -------------------------------------------------------------------=
--------------------
>     > Orange vous informe que cet e-mail a ete controle par
>     l'anti-virus mail.
>     > Aucun virus connu a ce jour par nos services n'a ete detecte.
>     >
>     >
>     >
>

--------------020604080306020004020009
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  <title></title>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
Thanks Mickael<br>
Now I merged the Zend_Serializer requirements to 1.10 branch.<br>
<br>
Marc<br>
<br>
Am 20.01.2010 16:58, schrieb mkk:
<blockquote
 cite=3D"mid:19673232.19114.1264003138175.JavaMail.www@wwinf1e37"
 type=3D"cite">I added these changes. I will merge them ASAP.<br>
  <br>
Mickael<br>
  <br>
  <blockquote
 style=3D"border-left: 2px solid rgb(255, 0, 0); padding-left: 5px; margi=
n-left: 5px;">&gt;
Message du 20/01/10 15:26<br>
&gt; De : "Matthew Weier O'Phinney" <br>
&gt; A : <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:zf-contribu=
[email-masked]">[email-masked]</a><br>
&gt; Copie =C3=A0 : <br>
&gt; Objet : [zf-contributors] Re: requirements (documentation) of
Zend_Serializer<br>
&gt; <br>
&gt; <br>
&gt; -- Marc Bennewitz wrote<br>
&gt; (on Tuesday, 19 January 2010, 11:39 PM +0100):<br>
&gt; &gt; I added the requirements of Zend_Serializer to trunk but
these files are<br>
&gt; &gt; completely different to that in 1.10 branch.<br>
&gt; &gt; Is there some work on it ?<br>
&gt; <br>
&gt; Merge the changes to the 1.10 branch, please.<br>
&gt; <br>
&gt; -- <br>
&gt; Matthew Weier O'Phinney<br>
&gt; Project Lead | <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:=
[email-masked]">[email-masked]</a><br>
&gt; Zend Framework | <a class=3D"moz-txt-link-freetext" href=3D"http://f=
ramework.zend.com/">http://framework.zend.com/</a><br>
&gt; PGP key: <a class=3D"moz-txt-link-freetext" href=3D"http://framework=
.zend.com/zf-matthew-pgp-key.asc">http://framework.zend.com/zf-matthew-pg=
p-key.asc</a><br>
&gt;
-------------------------------------------------------------------------=
--------------<br>
&gt; Orange vous informe que cet e-mail a ete controle par l'anti-virus
mail. <br>
&gt; Aucun virus connu a ce jour par nos services n'a ete detecte.<br>
&gt; <br>
&gt; <br>
&gt; <br>
  </blockquote>
</blockquote>
</body>
</html>

--------------020604080306020004020009--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 28 Aug 2009 07:22:52 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in
	Zend_Entity

-- Benjamin Eberlei <[email-masked]> wrote
(on Thursday, 27 August 2009, 10:06 PM +0200):
> i am currently scratching my head on howto abstract the query API for different 
> storages and often think about CouchDb which has a fundamently different Query 
> concept than a RDBMS.
> 
> For clarification to the not so familiar, it the EntityManager is the sole 
> public API to the user of Zend_Entity and its facilities. It manages the life-
> cycle of domain objects.
> 
> Currently, it has the following API for queries:
> 
> EntityManager::load($entityClass, $id);
> EntityManager::createNamedQuery($name);
> EntityManager::createNativeQuery($input, $resultSetMapping);
> EntityManager::createNativeQueryBuilder($entityClass=null);
> EntityManager::createQuery($zql); // not implemented yet
> EntityManager::createQueryBuilder(); // not implemented yet
> 
> This is very large and still very RDBMS specific interface. To break that up
> I was thinking to go the following way, only have three methods:
> 
> EntityManager::load($entityClass, $id);
> EntityManager::createNamedQuery($name);
> EntityManager::createNativeQuery($input, $resultSetMapping);
> 
> And all the other Query related stuff is implemented and used explicitly by 
> calling for example:
> 
> $sqlQueryBuilder = new Zend_Db_Mapper_SqlQueryBuilder($entityManager);
> $queryBuilder = new Zend_Db_Mapper_QueryBuilder($entityManager);
> $zqlQuery = new Zend_Db_Mapper_ZqlQuery($entityManager);
> 
> This way the API can be hinted explicitly in IDEs (since its often quite 
> complex) and storage specific features can be implemented.

This seems like a very good approach to me. It keeps the primary query
types front and center, but offers the flexibility to create your own
without needing to inform Zend_Entity of them. I particularly like this
because it introduces the idea of a "criteria" object -- which can then
be as abstract as you want it, or specific to your particular data
storage implementation.

> Now you ask yourself, how is this storage independent? It is via the
> "createNamedQuery()" method. This method internally uses the plugin
> loader to instantiate queries via the command pattern. In a storage
> independent database, all operations have to be build as named query
> and executed such.  For each storage a corresponding implementation
> has to exist. 

This seems like it would be very compatible with CouchDB views,
actually.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 15:44:07 -0300
From: Guilherme Blanco <[email-masked]>
To: David Caunt <[email-masked]>
Cc: Court Ewing <[email-masked]>,
	Matthew Ratzloff <[email-masked]>, 
	"Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

I already created a _initDoctrine extensible.

Benjamin (beberlei) is dealing to turn it into a Resource to be
autoloaded by Bootstrap. It should be available soon.

I also integrated the CLI too, but nothing using the Zend_Tool since
it'd be duplicating most of what Doctrine2 already supports.
If you have any questions feel free to ask on a separate thread.

Cheers,

On Thu, Feb 25, 2010 at 3:39 PM, David Caunt <[email-masked]> wrote:
> I'm inclined to agree with Court and Matthew then - focus on doing a
> cracking job of ZF2 and Doctrine 2 and lets make something awesome!
>
>
> On 25 February 2010 18:24, Court Ewing <[email-masked]> wrote:
>>
>> Howdy,
>>
>> I agree with this sentiment entirely.=C2=A0 While Doctrine 1.x is curren=
tly the
>> stable series, plans already exist to drop support for it in a little ov=
er a
>> year (according to the latest roadmap I've seen).=C2=A0 As this is a ZF2=
 email
>> chain, we should focus on Doctrine 2 integration with ZF2.
>>
>> Doctrine 2, while under heavy development, is actually in a pretty stabl=
e
>> state.=C2=A0 Pretty much all of the currently implemented functionality =
will not
>> be changing over the next few months, so this sort of integration could
>> begin shortly after the initial ZF changes that Matthew has already
>> described.
>>
>> Court Ewing
>>
>> On Thu, Feb 25, 2010 at 1:10 PM, Matthew Ratzloff
>> <[email-masked]> wrote:
>>>
>>> I don't think it would be beneficial to include Doctrine 1.x support in
>>> Zend Framework 1.x for this reason. =C2=A0There is no real "upgrade" pa=
th from
>>> version 1 to 2; they are very different. =C2=A0It also divides contribu=
tors'
>>> limited time, and the idea that you'll be working hard on something tha=
t
>>> will quickly be deprecated is not very motivating.
>>> -Matt
>>>
>>> On Thu, Feb 25, 2010 at 8:46 AM, Giorgio Sironi
>>> <[email-masked]> wrote:
>>>>
>>>> On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]=
>
>>>> wrote:
>>>>>
>>>>> I like the idea (as David Caunt mentioned) of releasing a 1.X branch
>>>>> with Doctrine 1 to test the waters and judging by the amount of work
>>>>> required decide to go with Doc2+ZF2 when the time comes.
>>>>
>>>> Beware that Doctrine 1 and Doctrine 2 are very different: the fomer is
>>>> ActiveRecord-based while the latter on the UnitOfWork pattern. Their
>>>> metadata management is not the same and 2.x is a complete rewrite of 1=
.x.
>>>>
>>>> Regards,
>>>> --
>>>> Giorgio Sironi
>>>> Piccolo Principe & Web Engineer
>>>> http://giorgiosironi.blogspot.com
>>>> http://twitter.com/giorgiosironi
>>>
>>
>>
>>
>> --
>> Regards,
>> Court Ewing
>> 610-304-1624
>
>
>
> --
> Save Water...Drink Ouzo !
>

--=20
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [email-masked]
URL: http://blog.bisna.com
S=C3=A3o Paulo - SP/Brazil

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Sat, 23 Jan 2010 12:15:19 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors] Doctrine 1 Integration Ideas

Hello Jurien,

How in your solution do models of different modules relate to each other?

My solution has a global approach, plus allows to filter model generation
by module, which i think is a good approach. In the end both approaches
feel the same from the CLI i guess.

greetings,
Benjamin

On Sat, 23 Jan 2010 10:07:03 +0100, Jurian Sluiman
<[email-masked]> wrote:
> On Friday 22 Jan 2010 12:57:05 Benjamin Eberlei wrote:
>> Hello everyone,
>=20
> Hi Benjamin,
>=20
> I've been working on the integration as well. It's quite specified to m=
y
> own=20
> work flow, but might be useful nevertheless.
>=20
>> Therefore my idea is, two-fold:
>>=20
>> I. Single ZF Module (Default)
>=20
> Because my existing application uses many modules, this seems not usefu=
l
> to=20
> me. I haven't looked at single module integration.
> =20
>> II. Doctrine + Multiple ZF MOdules:
>>=20
>> Circumvent Doctrine_Core::loadModels() completely by introducing a new
>> auto-loading
>> mechanism and slightly modifying the Doctrine_Import_Schema class.
>=20
> The Doctrine_Core::loadModels() is used by me on a modular basis. There
is
> a=20
> module application resource which bootstraps all the module bootstrap
> classes.=20
> These classes load their own models which works really good for me.
>=20
>> 1. Detect Module name by checking the first result of explode("_",
>> $className)
>>=20
>> 2. If the first is "Model", grab default module from Front-Controller,
>> otherwise Check that second result is "Model"
>>=20
>> 3. Write record, base-record and optionally table classes into the
>> modules
>> model directory.
>=20
> This is done by using code generation -again- on modular basis. Thus no=
:
> zf=20
> generate doctrine.models, but always specified with a module name (zf
> generate=20
> doctrine.models blog). This might be extended using the profile to loop
> through=20
> the modulesDirectory context inside the .zfproject.xml file?
>=20
>> Any ideas?
>=20
> My implementation works currently as follows:
>=20
> 1) zf create doctrine-project blog will create a configs folder in the
> module=20
> folder (if it doesn't exist yet). Then it creates the folders schema,=20
> migrations, sql and data (and write changes in the .zfproject.xml).
> 2) now it's possible to create your own files in the schema directory
with
> the=20
> modules you want (e.g. article.yml containing an Article model)
> 3) zf generate doctrine.models blog will look into the schema directory
> and=20
> generate the models. It's prefixed with Blog_Model and a base class is
> inside a=20
> Base subdirectory (containing the Blog_Model_Base_Article class). No
table=20
> classes are generated.
> 4) zf generate doctrine.tables blog should generate the table classes
for
> all=20
> the models in the blog module.
>=20
> The last step works only for the first time (creation of tables). If yo=
u
> modify=20
> the yaml file and do zf generate doctrine.models blog all models are
> updated=20
> correctly. I get a lot of errors on zf generate doctrine.tables blog to
> modify=20
> the tables, and had no time figuring out why it fails.=20
>=20
> If I solved the problem, I can commit the work into my svn library if
you=20
> want?
>=20
>> greetings,
>>=20
>> Benjamin
>=20
> Greetings, Jurian

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: David Caunt <[email-masked]>
Date: Thu, 25 Feb 2010 11:13:26 +0000
To: Giorgio Sironi <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--00151747373a60e8ad04806ae0b1
Content-Type: text/plain; charset=UTF-8

Integration of Doctrine 1 with ZF 1.11 might be a good way to test the water
and then community feedback may inform ZF2's integration with Doctrine 2.

As keen as I am for ZF2, I think the amount of work to be done on the core
is substantial and probably leaves enough time for a 1.11 release.

Are there any plans to maintain the 1.x series once 2.0 is released?

Dave

On 25 February 2010 10:46, Giorgio Sironi
<[email-masked]>wrote:

> On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley <[email-masked]>wrote:
>
>> In my opinion if Doctrine integration is to be left until ZF 2.0, then the
>> integrated version of Doctrine should be the 2.0 version. Since both 2.0
>> versions will require PHP 5.3.
>>
>
> I agree. Doctrine 2 will fill the lack of model infrastructure in Zend
> Framework.
> Anyway, the set of changes listed by Matthew is already a big step towards
> simpler development (exploiting phpunit new features for example.)
>
> Regards,
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>

-- 
Save Water...Drink Ouzo !

--00151747373a60e8ad04806ae0b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Integration of Doctrine 1 with ZF 1.11 might be a good way to test the wate=
r and then community feedback may inform ZF2&#39;s integration with Doctrin=
e 2.<div><br></div><div>As keen as I am for ZF2, I think the amount of work=
 to be done on the core is substantial and probably leaves enough time for =
a 1.11 release.<br>

<div><div><br></div><div>Are there any plans to maintain the 1.x series onc=
e 2.0 is released?</div><div><br></div><div>Dave<br><br><div class=3D"gmail=
_quote">On 25 February 2010 10:46, Giorgio Sironi <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">piccoloprincipeazzurro@gma=
il.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im"><div class=3D"gmail_quote=
">On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email-masked]" target=3D"_blank">ashley@ls12style.=
co.uk</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"border-left:1px solid rgb(204, 2=
04, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">

In my opinion if Doctrine integration is to be left until ZF 2.0, then the =
integrated version of Doctrine should be the 2.0 version. Since both 2.0 ve=
rsions will require PHP 5.3.<br></blockquote></div><br clear=3D"all"></div>

I agree. Doctrine 2 will fill the lack of model infrastructure in Zend Fram=
ework.<br>
Anyway, the set of changes listed by Matthew is already a big step towards =
simpler development (exploiting phpunit new features for example.)<br><br>R=
egards,<br><font color=3D"#888888">-- <br>Giorgio Sironi<br>Piccolo Princip=
e &amp; Web Engineer<br>

<a href=3D"http://giorgiosironi.blogspot.com" target=3D"_blank">http://gior=
giosironi.blogspot.com</a><br><a href=3D"http://twitter.com/giorgiosironi" =
target=3D"_blank">http://twitter.com/giorgiosironi</a><br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water...Dri=
nk Ouzo !<br>
</div></div></div>

--00151747373a60e8ad04806ae0b1--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 29 Sep 2009 12:55:58 -0400
From: Eric Coleman <[email-masked]>
To: Graham Anderson <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Google Wave Invites

I'd gladly take an account.  eric [at] aplosmedia.com  (@ericcoleman)

On Tue, Sep 29, 2009 at 12:17 PM, Graham Anderson
<[email-masked]> wrote:
> The first wave (pardon the pun) of mass invites for Google Wave are going=
 out
> tomorrow, people with existing accounts and new invitees will be allocate=
d 8
> additional invites.
>
> If you don't already have a wave account and have *not* signed up to get =
one,
> I'll send out my 8 invites in on a first come first served basis on this =
list.
>
> Graham
> --
> =E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=
=9D
> =C2=A0=E2=98=98 Oscar Wilde
>

--=20
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 22:34:01 +0100
From: Ralf Eggert <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

Hi Matthew,

Could you feed this discussion with some real world examples? For
example "Foobarable" and "Foobarist" sound a little weird to me.

Please name some interfaces with their current name and the future
variations for the options 1 to 8. Maybe this could help a little more
in the discussion. For example how should Zend_Acl_Role_Interface oder
Zend_Captcha_Adapter or Zend_Pdf_ElementFactory_Interface be renamed?

Thanks and best regards,

Ralf

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 3 Apr 2010 12:41:11 +0200
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

>From a design point of view we can make an example:
<?php
interface CapableOfSomething
{
    public function doSomething(MyClass $value);
    public function __invoke(MyClass $value);
}
When there is a type hint on the parameter, it is clearer that there
is a duplication in place: the methods accomplish the same thing, and
are coupled to change together. I agree that removing the analogue to
doSomething() makes the code less readable when using a single object,
so probably __invoke() has to go.
Placing an __invoke() method only on implementations it's useful to
simplify the chaining, but there is no way to enforce its
implementation (maybe a separate interface Chainable?)

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: =?UTF-8?Q?P=C3=A1draic_Brady?= <[email-masked]>,
	"Dolf Schimmel" <[email-masked]>
Cc: "Zend Framework Contributors" <[email-masked]>
Date: Fri, 26 Feb 2010 08:46:55 +0100
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

If there is a working integration into Eclipse than things are also ok fo=
r=20
people who are using Windows (like me).

But when you must always open a linux virtual machine or go down to comma=
nd=20
line from Eclipse to commit anything than this is a real blocker as it=20
breaks the complete workflow and makes them less efficient.

I have this problem and actually I am between 150 to 300 commits per mont=
h=20
just to give a number.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "P=C3=A1draic Brady" <[email-masked]>
To: "Dolf Schimmel" <[email-masked]>
Cc: "Zend Framework Contributors" <[email-masked]>
Sent: Friday, February 26, 2010 12:45 AM
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins=
!

I suppose just to make two points (I am pro-git but they need=20
consideration).

>> Tooling across platforms is not as mature or robust
>Who needs
anything else than /usr/bin/git? Obviously should the
>Atlassian tools should support git as well, but I guess they do these
>days.

Original comment was referring to Windows. The tools are heavily Linux=20
centric and I'm sure many of us are more than comfortable doing things th=
e=20
Linux way. I know I rarely, if ever, leave the command line except to swi=
tch=20
to my editor or browser ;). Is everyone though? On Windows, the story is=20
less kind and the tools somewhat cumbersome. On the other hand, for SVN, =
the=20
Windows tooling is very mature, easy to use, and integrates right in=20
alongside pretty much everything.

Paddy

 P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

________________________________
From: Dolf Schimmel <[email-masked]>
To: Graham Anderson <[email-masked]>
Cc: [email-masked]
Sent: Thu, February 25, 2010 11:20:26 PM
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins=
!

I guess I'll have to confess I've been convinced ZF should use GIT,
not only because other major projects like Zym use it (:wink:), but
also because it seems to bring quite a lot of advantages, while hardly
bringing any disadvantages.

The cons (from the wiki):
> Tracking CLAs becomes more difficult. Currently with SVN, we only grant=
=20
> access to those who have signed a CLA; if anybody can fork, we now need=
=20
> some way to verify CLA status before pulling patches.
After all there's always someone who's committing to the 'main'
(master?) repository. You can always track who makes those 'main'
commits? The person committing to the main repos should then keep
track of
everybody contributing to a certain commit has signed a CLA (as is
done now when a patch is applied). There should however be a clear and
uptodate list of everybody who signed a CLA (that's more than a
selectbox in jira...).

> No good svn:externals equivalent
We could just commit a checkout of Dojo (and possibly Dcotrine) into
the ZF repository, making it read-only by anybody who's not a release
manager. For people who use svn for their own projects, there should
be an svn mirror for people to use for their svn:externals. If Zend
can't provide such mirror I (my company) would be happy to do so.

> Tooling across platforms is not as mature or robust
Who needs anything else than /usr/bin/git? Obviously should the
Atlassian tools should support git as well, but I guess they do these
days.

> Would potentially require (re-)training contributors
I have never worked with git myself, but how difficult can the basics
be? git clone, git pull, git status, git add, git commit -a should be
things any contributor can understand (right?). Instead of actively
train them, I'd be a fan of putting a link to
http://git.or.cz/course/svn.html in the topic of #zftalk.dev on
freenode (and the wiki etc...).

--Freeaqingme

P.s. For all of those not following me, I indeed had a different
opinion on this a few days ago...

On Thu, Feb 25, 2010 at 11:53 PM, Graham Anderson
<[email-masked]> wrote:
> On Thursday 25 February 2010 21:48:57 Matthew Weier O'Phinney wrote:
>>The release master can
>>track multiple repos from multiple collaborators, and then selectively
>>merge into their own "master" -- and push those patches into the
>>mainline.
>
> For the benefit of those who don't currently use Git one other powerful=
=20
> aspect
> of this collaborative work-flow is being able to cherry pick commits.
>
> In this situation you may have multiple branches, some of them may or m=
ay=20
> not
> track other developers remote branches. Rather than merge the whole bra=
nch
> from HEAD to 6 commits previously, you see that only one of the commits=
=20
> has
> the changeset you need. Git cherry-pick allows you to merge a single=20
> commit.
>
> This, and being able to merge at will from multiple remote branches is =
the
> kind of functionality I believe makes Git more suitable than SVN for wh=
at=20
> we
> do.
>
> There's more, much more. One of the key differences between Git and SVN=
,=20
> and
> this is extremely important, is that Git tracks the _content_ of your=20
> files
> whereas SVN tracks the files themselves. Git really doesn't care that=20
> there
> are 10 or 20 or 1,000 files, it only cares about the content and it onl=
y=20
> cares
> how the content changes.
>
> Here's an example, since Layout.php has been in the codebase for a whil=
e I
> wanted to see who was responsible for last editing it. So i looked at t=
he
> source and decided to lookup the method setMvcSuccessfulActionOnly(). I=
t's=20
> on
> line number 483-487.
>
>    git blame -L 483,487 Layout.php
>
> I'll trim the output and ommit the actual code which is appended to the=
=20
> end of
> the following lines but you can see the detailed info that is available=
.
>
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
> +0000
> 483)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
> +0000
> 484)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
> +0000
> 485)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
> +0000
> 486)
> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=20
> +0000
> 487)
>
> So in less than a quarter of a second I can search the whole commit=20
> history of
> the main ZF repo and see who was responsible for last editing any line =
of=20
> any
> file. There's lots more gems like this that let you unleash the power o=
f=20
> Git
> if you want to look below the surface.
>
> The surface is a good place to be as well, let me offer a common work-f=
low
> situation with git using every day commands.
>
> git checkout -b foobar
> edit foo/bar.php
> ... hack hack hack ...
> *ring ring* oops emergency fix needed
> git stash
> git checkout master
> edit emergency/fix.php
> git commit -am "Commit fix!"
> git checkout foobar
> git stash pop
> ... hack hack hack ...
> git checkout master
> git merge foobar
> *glug glug glug* cold beers while your colleagues are still fighting SV=
N.
>
> The story above is: Create and move into feature branch "foobar". Start
> hacking on the feature. Boss calls, X is broken!, stash your changes an=
d
> quickly switch to master(trunk). Fix broken things, commit them, switch=
=20
> back
> to foobar branch. Pop your changes from the stash into your working set=
,
> continue hacking. Switch to master(trunk) and merge your new feature=20
> Foobar.
> Profit!
>
> --
> =E2=80=9CWhat can be asserted without proof can be dismissed without pr=
oof.=E2=80=9D
> - Christopher Hitchens

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 09 Mar 2010 00:04:59 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] ZF 2.0 Status: 8 Mar 2010

Matthew Weier O'Phinney wrote on 08.03.2010 22:41:
>     # from tests/ directory
>     % phpunit --group Zend_Acl .

Why not just do phpunit --filter Zend_Acl instead? That makes the @group
stuff obsolete.

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 16 Oct 2009 15:29:41 -0700
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] Simple Cloud Storage API ready for review. . .

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA4EB0.2869A3D4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You can check it out here:
http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/

=20

Keep in mind that it's still under heavy development, and many of the
tests have been marked incomplete or skipped. Also, the API targets
common functionality, so don't expect to find all the bells and whistles
of your favorite cloud service in there. What it does offer, however, is
an API that helps you keep your apps portable in the cloud with
configuration changes alone, calling out any design or development
decisions that break compatibility among cloud application services. As
with all ZF initiatives, we welcome community contributions. Big plus:
if you're implementing an adapter, the unit tests are already written
for you.

=20

Please let me know what you think. It's not ready for tracking issues
yet, so send them to the list or comment here:
http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/

=20

All pot shots at this old Java developer's code will be discussed in my
weekly therapy session with /dev/null. J

=20

Thanks all!

,Wil

------_=_NextPart_001_01CA4EB0.2869A3D4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>You can check it out here: <a
href=3D"http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/tru=
nk/">http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/=
</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Keep in mind that it&#8217;s still under heavy =
development,
and many of the tests have been marked incomplete or skipped. Also, the =
API targets
common functionality, so don&#8217;t expect to find all the bells and =
whistles
of your favorite cloud service in there. What it does offer, however, is =
an API
that helps you keep your apps portable in the cloud with configuration =
changes
alone, calling out any design or development decisions that break =
compatibility
among cloud application services. As with all ZF initiatives, we welcome
community contributions. Big plus: if you&#8217;re implementing an =
adapter, the
unit tests are already written for you.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Please let me know what you think. It&#8217;s not =
ready for
tracking issues yet, so send them to the list or comment here: <a
href=3D"http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/tru=
nk/">http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/=
</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>All pot shots at this old Java developer&#8217;s =
code will
be discussed in my weekly therapy session with /dev/null. <span
style=3D'font-family:Wingdings'>J</span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks all!<o:p></o:p></p>

<p class=3DMsoNormal>,Wil<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01CA4EB0.2869A3D4--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: David Caunt <[email-masked]>
Date: Fri, 5 Feb 2010 14:49:50 +0000
To: Maarten Balliauw <[email-masked]>
Cc: Juan Felipe Alvarez Saldarriaga <[email-masked]>,
	develop <[email-masked]>, 
	Nigel Chapman <[email-masked]>, 
	Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

--0023545bd49c80c9c9047edb91e9
Content-Type: text/plain; charset=UTF-8

My biggest concern is separation of concerns. At the moment this component
does some genuinely useful tasks, but parts are about building data, and
others are about presentation of data, which should probably be handled by
View Helpers.

Some kind of datasource component might be more appropriate, which then has
an interface mapping to View Helpers. Array would be one such adapter to
this component. I can see genuine value in being able to easily convert
between datasources, and a datasource provides a nice interface for other
components to consume data without worrying about it's origin.

I might be way off but interested to hear others' thoughts.

Dave

On 5 February 2010 14:10, Maarten Balliauw <[email-masked]>wrote:

> Also check http://phplinq.codeplex.com for that matter. It's an
> abstraction over arrays and optionally also over Zend_Db_Table, Windows
> Azure Table Storage, ...
>
> Maarten
>
> On Fri, Feb 5, 2010 at 3:00 PM, Juan Felipe Alvarez Saldarriaga <
> [email-masked]> wrote:
>
>> Hey, nice proposal, a little bit like LINQ right? my concern is about
>> performance too.
>>
>> Saludos.
>>
>> On Fri, Feb 5, 2010 at 3:56 AM, Carlos Medina
>> <[email-masked]> wrote:
>> > Nigel Chapman schrieb:
>> >>
>> >> Hi All,  (? -- not sure how active this list is.)
>> >>
>> >> Just a note to announce a new proposal:
>> >>
>> >> Zend_Array is a fluent wrapper for PHP's array functions.
>> >>
>> >> It lets you deal with arrays rather as you would in Ruby or JQuery,
>> >> with chained operators and closures.
>> >>
>> >> Over the next few weeks, I'll be workign on the doc standards and test
>> >> suite, and thinking if it needs more (or less!) core methods.
>> >>
>> >> Comments? Improvements?
>> >>
>> >> * http://chapman.id.au/zend-array/
>> >>
>> >> *
>> http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman
>> >>
>> >> I sometimes appear on #zftalk as kale77in.
>> >>
>> >> Thanks,
>> >>
>> >> Nigel.
>> >>
>> >>
>> >>
>> >
>> > Hi Nigel,
>> > i think this is a very usefull proposal. The question is: performance?
>> have
>> > you tests about this.
>> >
>> > Regards
>> >
>> > Carlos
>> >
>>
>
>

-- 
Save Water...Drink Ouzo !

--0023545bd49c80c9c9047edb91e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

My biggest concern is separation of concerns. At the moment this component =
does some genuinely useful tasks, but parts are about building data, and ot=
hers are about presentation of data, which should probably be handled by Vi=
ew Helpers.<div>

<br></div><div>Some kind of datasource component might be more appropriate,=
 which then has an interface mapping to View Helpers. Array would be one su=
ch adapter to this component. I can see genuine value in being able to easi=
ly convert between datasources, and a datasource provides a nice interface =
for other components to consume data without worrying about it&#39;s origin=
.</div>

<div><br></div><div>I might be way off but interested to hear others&#39; t=
houghts.</div><div><br></div><div>Dave</div><div><br></div><div><br><br><di=
v class=3D"gmail_quote">On 5 February 2010 14:10, Maarten Balliauw <span di=
r=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=
k">[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>Also check <a href=3D"http://phplinq.co=
deplex.com/" target=3D"_blank">http://phplinq.codeplex.com</a> for that mat=
ter. It&#39;s an abstraction over arrays and optionally also over Zend_Db_T=
able, Windows Azure Table Storage, ...</div>

<div>=C2=A0</div><font color=3D"#888888">
<div>Maarten<br><br></div></font><div><div></div><div>
<div class=3D"gmail_quote">On Fri, Feb 5, 2010 at 3:00 PM, Juan Felipe Alva=
rez Saldarriaga <span dir=3D"ltr">&lt;<a href=3D"mailto:jfalvarez@vesifront=
.org" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote style=3D"border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex" class=3D"gmail_quote">Hey, nice proposal, a little bit like=
 LINQ right? my concern is about<br>performance too.<br><br>Saludos.<br>
<br>On Fri, Feb 5, 2010 at 3:56 AM, Carlos Medina<br>&lt;<a href=3D"mailto:=
[email-masked]" target=3D"_blank">[email-masked]</a=
>&gt; wrote:<br>&gt; Nigel Chapman schrieb:<br>&gt;&gt;<br>&gt;&gt; Hi All,=
 =C2=A0(? -- not sure how active this list is.)<br>

&gt;&gt;<br>&gt;&gt; Just a note to announce a new proposal:<br>&gt;&gt;<br=
>&gt;&gt; Zend_Array is a fluent wrapper for PHP&#39;s array functions.<br>=
&gt;&gt;<br>&gt;&gt; It lets you deal with arrays rather as you would in Ru=
by or JQuery,<br>

&gt;&gt; with chained operators and closures.<br>&gt;&gt;<br>&gt;&gt; Over =
the next few weeks, I&#39;ll be workign on the doc standards and test<br>&g=
t;&gt; suite, and thinking if it needs more (or less!) core methods.<br>

&gt;&gt;<br>&gt;&gt; Comments? Improvements?<br>&gt;&gt;<br>&gt;&gt; * <a h=
ref=3D"http://chapman.id.au/zend-array/" target=3D"_blank">http://chapman.i=
d.au/zend-array/</a><br>&gt;&gt;<br>&gt;&gt; * <a href=3D"http://framework.=
zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman" target=3D"_blank">=
http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman</a=
><br>

&gt;&gt;<br>&gt;&gt; I sometimes appear on #zftalk as kale77in.<br>&gt;&gt;=
<br>&gt;&gt; Thanks,<br>&gt;&gt;<br>&gt;&gt; Nigel.<br>&gt;&gt;<br>&gt;&gt;=
<br>&gt;&gt;<br>&gt;<br>&gt; Hi Nigel,<br>&gt; i think this is a very usefu=
ll proposal. The question is: performance? have<br>

&gt; you tests about this.<br>&gt;<br>&gt; Regards<br>&gt;<br>&gt; Carlos<b=
r>&gt;<br></blockquote></div><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water.=
..Drink Ouzo !<br>
</div>

--0023545bd49c80c9c9047edb91e9--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Tue, 12 Jan 2010 14:50:16 +0100
Subject: Re: [zf-contributors] PHP error in framework docs search results.

On Tuesday 12 January 2010 14:14:00 Matthew Weier O'Phinney wrote:
>Regarding the undefined offset notices, I'll be discussing these with
>Alex, as they're indicative of potential issues in the Lucene component.

I was just double checking my includes, the previous errors and failures *do* 
occur for me under 1.9.7

PHP 5.3.0 
PHPUnit 3.4.5

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 1 Apr 2010 11:50:48 -0600
From: Tommy Smith <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

--00151750e6e0c457a30483308087
Content-Type: text/plain; charset=ISO-8859-1

I probably only have about 1/2 cent worth to give - but, I think that is a
very reasonable solution that should satisfy good programming practices. I
really like the idea of leaving the interfaces __invoke() free... :-)

Thanks,
Tommy Smith

On Thu, Apr 1, 2010 at 11:19 AM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> Ralph and I were just talking about this, and had a realization.
>
> is_callable() returns true for objects that implement __invoke().
>
> What this means is: even for filter chains and the like, we simply test
> to see if what was passed is callable. If not, we throw an exception or
> use another strategy. (In Phly_PubSub, if I get a non-callable first
> argument, I check for a second argument, which would be the method to
> call on the first argument.)
>
> As such, he and I are leaning towards no definition of __invoke() in the
> interface, but defining it in the abstract classes and/or concrete
> classes that implement the interface. This solves the issue of ensuring
> clear interfaces, while also solving the issue of using __invoke() as a
> general-purpose, consistent callback paradigm within the framework.
>
> Thoughts?
>
> -- Matthew Weier O'Phinney <[email-masked]> wrote
> (on Thursday, 01 April 2010, 11:43 AM -0400):
> > -- Dolf Schimmel <[email-masked]> wrote
> > (on Thursday, 01 April 2010, 04:48 PM +0200):
> > > > Now, since the Symfony Live conference, I've also been thinking about
> > > > something Fabien said about Symfony 2: "less magic." To clarify, the
> > > > idea is to design components so that they are explicit about what
> they
> > > > can do. As an example, instead of using __get() and __set(), using
> > > > explicit getters and setters; instead of using __call(), explicitly
> > > > defining methods; instead of having __call() proxy to helpers, having
> a
> > > > broker from which you pull them as needed.
> > >
> > > Apparently the rumors on twitter were in place; the conference did
> > > have a bad influence on you :D
> >
> > Umm... there are good ideas everywhere, and bad ones as well. Neither ZF
> > nor SF have a monopoloy on either.
> >
> > > More seriously, I think this can in no way be compared with SF's
> > > "magic" (does the fact that our Zend_Magic only is imaginative mean ZF
> > > does at this moment not contain any magic?).
> >
> > I wasn't trying to explicitly link the two. In fact, the examples I gave
> > were examples of applying Fabien's ideas to ZF.
> >
> > > Firstly, if you have a class called foo\Filter which contains an
> > > __invoke() method,
> > > that method should obviously filter. As long as it does that and only
> > > that, there's no magic imho involved.
> >
> > I can see this POV. For somebody who doesn't know what the interface's
> > purpose is, however, it's less clear. Let me point that out with your
> > next examples:
> >
> > > Same goes for foo\Validator (its
> > > __invoke() method is supposed to validate), and foo\Bootstrap (guess
> > > what: __invoke() should bootstrap here).
> >
> > Validator defines two method types: validation, and error message
> > retrieval. In the original interface, this is pretty clear: isValid()
> > and getMessages(). If we change to __invoke() and getMessages(), the
> > latter method is clear, but the former is not -- what exactly is
> > happening here?
> >
> > Looking at the bootstrap, this is also a bit more unclear: right now, we
> > have a bootstrap() method and a run() method: which one does __invoke()
> > define? Resources might be a bit more clear: the init() method might
> > make sense to instead map to __invoke() -- but the intent is less clear.
> > init() at least implies that we're initializing something; what does
> > __invoke() do?
> >
> > > If we can get it done consistently I'm pretty sure everybody will be
> > > used to it within the first 5 seconds they look at a random piece of
> > > code.
> >
> > I *do* want to see consistency. I just don't want to sacrifice end-user
> > comprehension of the code. Our current usage of __call(), __get(), and
> > __set() throughout the framework *does* make the code less easy to
> > understand. I've had plenty of people indicate that they have had
> > trouble understanding view helpers because they can't find the methods
> > in the view object; I don't want the same thing happening with usage of
> > __invoke().
> >
> > > Secondly Symfony's magic is on an entirely different scale of
> > > magnitude than the naming of one type of method.  Compare
> > > $random->method() generating an entire application for you with
> > > $object() which exactly does what the name of the object implies.
> >
> > Please see my notes above. I wasn't talking about this type of magic.
> >
> > > Situations in which you have two methods doing exactly the same are
> > > often/usually a result of willing to change, but also struggling with
> > > inability to do so due to backwards compatibility constraints.
> > > However, now that we're busy on something where potentially all BC may
> > > be broken, I really don't think having two methods doing exactly the
> > > same would be beneficial to anybody. In fact, it would increase the
> > > amount of options to do something with (give or take) N! which is an
> > > awful lot, without any added value.
> >
> > This is the primary argument I can see against having both an explicit
> > method name defined and __invoke(), and it hits home with other
> > complaints about the current state of ZF: understanding how ZF is
> > difficult when there's more than one way to do things.
> >
> > I want to be clear that the primary reason for using __invoke() in the
> > first place is for dynamic calls using call_user_func() and
> > call_user_func_array(). While using __invoke() with these is faster than
> > a traditional callback, it's still way slower than calling the method
> > directly -- around 3 times slower. __invoke() simply provides a slight
> > optimization in a pattern that we're likely to use many, many times
> > throughout a given request.
> >
> > For single usage, though, would you rather do this:
> >
> >     $value = $plugin($data);
> >
> >     or:
> >
> >     $value = $plugin->filter($data);
> >
> > I realize it's a bit contrived -- you might name the object to better
> > describe its purpose. However, the latter more clearly explains what
> > you're doing to the data: you're filtering it. Let's look at a
> > validator:
> >
> >     $test = $plugin($value);
> >
> >     or:
> >
> >     $test = $plugin->isValid($value);
> >
> > I actually think this one benefits a ton -- even with a well-named
> > variable:
> >
> >     $test = $validator($value);
> >
> > What is "$validator"? and what is it doing here? When we call the
> > method, we know we're checking for validity; when we call it via
> > __invoke(), we could be filtering it, validating it, pushing in a
> > value... who knows?
> >
> > In my earlier post, I probably should have made it more clear: I see
> > __invoke() as a way to more easily and efficiently define and execute
> > *callbacks*, and hence my rationale that it makes sense to define both
> > an explicit method as well as __invoke() for those class types that will
> > be used with filter chains and/or brokers.
> >
> >
> > > On Thu, Apr 1, 2010 at 3:07 PM, Matthew Weier O'Phinney
> > > <[email-masked]> wrote:
> > > > I've been following this thread as well as discussions on IRC with
> > > > interest, as, honestly, I can completely buy into all arguments,
> which
> > > > are, to sum things up:
> > > >
> > > >  * Use only __invoke()
> > > >  * Use a method name specific to the interface
> > > >  * Use a standardized method name, such as "run" or "execute"
> > > >  * Use a combination of __invoke() and either a meaningful or
> > > >   standardized method name.
> > > >
> > > > I got to thinking about why I suggested "__invoke()" in the first
> place,
> > > > and went back to the plugin architecture page:
> > > >
> > > >  *
> http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures
> > > >
> > > > The original rationale was for using pubsub/filter chain systems. In
> > > > such systems, you attach callbacks:
> > > >
> > > >    $chain->attach($callback);
> > > >
> > > > If your objects implement __invoke(), $callback can simply be your
> > > > object -- you're done. Otherwise, you also have to provide the
> method:
> > > >
> > > >    $chain->attach($object, $method);
> > > >
> > > > Interestingly, in this document, I also recommended that for existing
> > > > interfaces, __invoke() be added as an _additional_ method, and that
> it
> > > > should proxy to the appropriate interface method. In this case, we'd
> > > > simply be taking advantage of a language feature in places it makes
> > > > sense.
> > > >
> > > > Now, since the Symfony Live conference, I've also been thinking about
> > > > something Fabien said about Symfony 2: "less magic." To clarify, the
> > > > idea is to design components so that they are explicit about what
> they
> > > > can do. As an example, instead of using __get() and __set(), using
> > > > explicit getters and setters; instead of using __call(), explicitly
> > > > defining methods; instead of having __call() proxy to helpers, having
> a
> > > > broker from which you pull them as needed.
> > > >
> > > > This has several implications:
> > > >
> > > >  * Less need for explicit documentation. If you have behaviors
> relying
> > > >   on the magic methods, developers *must* read the the documentation
> in
> > > >   order to know how a class/component works. If everything is
> explicit,
> > > >   the class is self-documenting, and you can get the information you
> > > >   need from API docs, your IDE, etc.
> > > >
> > > >  * Performance. Magic methods are reportedly less performant than
> using
> > > >   straight method calls (more on this later).
> > > >
> > > > These are important factors, and the test-driven developer in me
> > > > particularly likes less magic; it's much easier to test when you have
> > > > explicit behaviors.
> > > >
> > > > That said, I decided to run some tests. These were the scenarios:
> > > >
> > > >  * No Proxying:
> > > >   * Defined "filter" method returns value
> > > >   * Defined "__call" method returns value
> > > >   * Defined "__invoke" method returns value
> > > >  * Proxying:
> > > >   * Defined "filter" method returns value
> > > >   * Defined "__call" method proxies to "filter"
> > > >   * Defined "__invoke" method proxies to "filter"
> > > >  * Inverse proxying
> > > >   * Defined "filter" method calls invoke (as "$this();")
> > > >   * Defined "__invoke" method returns value
> > > >  * call_user_func_array()
> > > >   * Using array($obj, 'filter') callback
> > > >   * Using __invoke() with no proxying
> > > >   * Using __invoke() with proxying
> > > >
> > > > The results were quite interesting. Across the board, using __call()
> is
> > > > awful -- even if you simply return a value, it's on average 6x slower
> > > > than a straight method call; proxying to another method, however,
> > > > doesn't take significantly longer (so long as you're not using
> > > > call_user_func_array() internally, that is).
> > > >
> > > > __invoke(), however, turns out to be quite different. When not
> proxying,
> > > > it's actually *faster* than a method call (about 25% on average).
> > > > Proxing __invoke() to a method call or doing the inverse are roughly
> the
> > > > same speed -- about 2.5x slower than a straight method call (which,
> as
> > > > you'll note, is still over twice as fast as using __call()).
> > > >
> > > > What was *really* interesting, however, was using
> > > > call_user_func_array(), which is commonly used in filter chains
> and/or
> > > > brokers.  __invoke(), with or without proxying, *always* was around
> 30%
> > > > *faster* than using an explicit array($obj, $method) callback.
> > > >
> > > > So, what does this tell me?
> > > >
> > > >  * AVOID using __call(), particularly for often-used method calls.
> For
> > > >   helper systems, it will always be better to use a helper broker and
> > > >   command pattern.
> > > >
> > > >  * For classes meant to be used primarily with filter chains or
> brokers,
> > > >   DO use __invoke(), even if it simply proxies to another interface
> > > >   method.
> > > >
> > > > So, based on the design goals and the performance benchmarking, I'm
> > > > going to recommend that Filter and Validator (we renamed Validate to
> > > > Validator) define an __invoke() method in addition to a more explicit
> > > > interface method, and that helpers also follow this pattern.
> > > >
> > > > -- Matthew Weier O'Phinney <[email-masked]> wrote
> > > > (on Wednesday, 31 March 2010, 10:21 AM -0400):
> > > >> Greetings, all --
> > > >>
> > > >> Per the roadmap, one change we're planning on making is making
> plugin
> > > >> usage consistent across components: plugins will implement
> __invoke(),
> > > >> which makes them inherently callable.
> > > >>
> > > >> In our refactoring branch, I've done this now with Zend_Filter.
> However,
> > > >> it required a ton of refactoring on the unit tests (had to either
> call
> > > >> __invoke() directly, or $filter($value)), and it got me to thinking:
> > > >>
> > > >> Would it make sense to keep the original interfaces (filter,
> isValid,
> > > >> render, etc.), but also implement __invoke() -- having it proxy to
> the
> > > >> appropriate interface method?
> > > >>
> > > >> As an example:
> > > >>
> > > >>     interface Filter
> > > >>     {
> > > >>         public function filter($value);
> > > >>         public function __invoke($value);
> > > >>     }
> > > >>
> > > >>     class Digits implements Filter
> > > >>     {
> > > >>         public function filter($value)
> > > >>         {
> > > >>             // ... logic...
> > > >>         }
> > > >>
> > > >>         public function __invoke($value)
> > > >>         {
> > > >>             return $this->filter($value);
> > > >>         }
> > > >>     }
> > > >>
> > > >> The benefits:
> > > >>
> > > >>  * Fewer changes necessary to existing unit tests
> > > >>  * interface method names may be more descriptive of intent
> > > >>
> > > >> Problems:
> > > >>
> > > >>  * Using __invoke() introduces overhead -- 2 method calls instead of
> one
> > > >>  * Redundancy (two methods doing the same thing)
> > > >>  * A few extra tests to write (to ensure __invoke works as expecte)
> > > >>
> > > >> After discussion with Ralph and Alex, I'm leaning towards having
> > > >> __invoke() as an _additional_ method, instead of replacing existing
> > > >> methods.
> > > >>
> > > >> Any thoughts or comments?
> > > >>
> > > >> --
> > > >> Matthew Weier O'Phinney
> > > >> Project Lead            | [email-masked]
> > > >> Zend Framework          | http://framework.zend.com/
> > > >> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> > > >>
> > > >
> > > > --
> > > > Matthew Weier O'Phinney
> > > > Project Lead            | [email-masked]
> > > > Zend Framework          | http://framework.zend.com/
> > > > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> > > >
> > >
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead            | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--00151750e6e0c457a30483308087
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I probably only have about 1/2 cent worth to give - but, I think that is a =
very reasonable solution that should satisfy good programming practices. I =
really like the idea of leaving the interfaces __invoke() free... :-)<div>
<br></div><div>Thanks,</div><div>Tommy Smith<br><br><div class=3D"gmail_quo=
te">On Thu, Apr 1, 2010 at 11:19 AM, Matthew Weier O&#39;Phinney <span dir=
=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Ralph and I were just talking about this, a=
nd had a realization.<br>
<br>
is_callable() returns true for objects that implement __invoke().<br>
<br>
What this means is: even for filter chains and the like, we simply test<br>
to see if what was passed is callable. If not, we throw an exception or<br>
use another strategy. (In Phly_PubSub, if I get a non-callable first<br>
argument, I check for a second argument, which would be the method to<br>
call on the first argument.)<br>
<br>
As such, he and I are leaning towards no definition of __invoke() in the<br=
interface, but defining it in the abstract classes and/or concrete<br>
classes that implement the interface. This solves the issue of ensuring<br>
clear interfaces, while also solving the issue of using __invoke() as a<br>
general-purpose, consistent callback paradigm within the framework.<br>
<br>
Thoughts?<br>
<br>
-- Matthew Weier O&#39;Phinney &lt;<a href=3D"mailto:[email-masked]">matt=
[email-masked]</a>&gt; wrote<br>
(on Thursday, 01 April 2010, 11:43 AM -0400):<br>
&gt; -- Dolf Schimmel &lt;<a href=3D"mailto:[email-masked]">dolfsch=
[email-masked]</a>&gt; wrote<br>
&gt; (on Thursday, 01 April 2010, 04:48 PM +0200):<br>
&gt; &gt; &gt; Now, since the Symfony Live conference, I&#39;ve also been t=
hinking about<br>
&gt; &gt; &gt; something Fabien said about Symfony 2: &quot;less magic.&quo=
t; To clarify, the<br>
&gt; &gt; &gt; idea is to design components so that they are explicit about=
 what they<br>
&gt; &gt; &gt; can do. As an example, instead of using __get() and __set(),=
 using<br>
&gt; &gt; &gt; explicit getters and setters; instead of using __call(), exp=
licitly<br>
&gt; &gt; &gt; defining methods; instead of having __call() proxy to helper=
s, having a<br>
&gt; &gt; &gt; broker from which you pull them as needed.<br>
&gt; &gt;<br>
&gt; &gt; Apparently the rumors on twitter were in place; the conference di=
d<br>
&gt; &gt; have a bad influence on you :D<br>
&gt;<br>
&gt; Umm... there are good ideas everywhere, and bad ones as well. Neither =
ZF<br>
&gt; nor SF have a monopoloy on either.<br>
&gt;<br>
&gt; &gt; More seriously, I think this can in no way be compared with SF&#3=
9;s<br>
&gt; &gt; &quot;magic&quot; (does the fact that our Zend_Magic only is imag=
inative mean ZF<br>
&gt; &gt; does at this moment not contain any magic?).<br>
&gt;<br>
&gt; I wasn&#39;t trying to explicitly link the two. In fact, the examples =
I gave<br>
&gt; were examples of applying Fabien&#39;s ideas to ZF.<br>
&gt;<br>
&gt; &gt; Firstly, if you have a class called foo\Filter which contains an<=
br>
&gt; &gt; __invoke() method,<br>
&gt; &gt; that method should obviously filter. As long as it does that and =
only<br>
&gt; &gt; that, there&#39;s no magic imho involved.<br>
&gt;<br>
&gt; I can see this POV. For somebody who doesn&#39;t know what the interfa=
ce&#39;s<br>
&gt; purpose is, however, it&#39;s less clear. Let me point that out with y=
our<br>
&gt; next examples:<br>
&gt;<br>
&gt; &gt; Same goes for foo\Validator (its<br>
&gt; &gt; __invoke() method is supposed to validate), and foo\Bootstrap (gu=
ess<br>
&gt; &gt; what: __invoke() should bootstrap here).<br>
&gt;<br>
&gt; Validator defines two method types: validation, and error message<br>
&gt; retrieval. In the original interface, this is pretty clear: isValid()<=
br>
&gt; and getMessages(). If we change to __invoke() and getMessages(), the<b=
r>
&gt; latter method is clear, but the former is not -- what exactly is<br>
&gt; happening here?<br>
&gt;<br>
&gt; Looking at the bootstrap, this is also a bit more unclear: right now, =
we<br>
&gt; have a bootstrap() method and a run() method: which one does __invoke(=
)<br>
&gt; define? Resources might be a bit more clear: the init() method might<b=
r>
&gt; make sense to instead map to __invoke() -- but the intent is less clea=
r.<br>
&gt; init() at least implies that we&#39;re initializing something; what do=
es<br>
&gt; __invoke() do?<br>
&gt;<br>
&gt; &gt; If we can get it done consistently I&#39;m pretty sure everybody =
will be<br>
&gt; &gt; used to it within the first 5 seconds they look at a random piece=
 of<br>
&gt; &gt; code.<br>
&gt;<br>
&gt; I *do* want to see consistency. I just don&#39;t want to sacrifice end=
-user<br>
&gt; comprehension of the code. Our current usage of __call(), __get(), and=
<br>
&gt; __set() throughout the framework *does* make the code less easy to<br>
&gt; understand. I&#39;ve had plenty of people indicate that they have had<=
br>
&gt; trouble understanding view helpers because they can&#39;t find the met=
hods<br>
&gt; in the view object; I don&#39;t want the same thing happening with usa=
ge of<br>
&gt; __invoke().<br>
&gt;<br>
&gt; &gt; Secondly Symfony&#39;s magic is on an entirely different scale of=
<br>
&gt; &gt; magnitude than the naming of one type of method. =A0Compare<br>
&gt; &gt; $random-&gt;method() generating an entire application for you wit=
h<br>
&gt; &gt; $object() which exactly does what the name of the object implies.=
<br>
&gt;<br>
&gt; Please see my notes above. I wasn&#39;t talking about this type of mag=
ic.<br>
&gt;<br>
&gt; &gt; Situations in which you have two methods doing exactly the same a=
re<br>
&gt; &gt; often/usually a result of willing to change, but also struggling =
with<br>
&gt; &gt; inability to do so due to backwards compatibility constraints.<br=
&gt; &gt; However, now that we&#39;re busy on something where potentially a=
ll BC may<br>
&gt; &gt; be broken, I really don&#39;t think having two methods doing exac=
tly the<br>
&gt; &gt; same would be beneficial to anybody. In fact, it would increase t=
he<br>
&gt; &gt; amount of options to do something with (give or take) N! which is=
 an<br>
&gt; &gt; awful lot, without any added value.<br>
&gt;<br>
&gt; This is the primary argument I can see against having both an explicit=
<br>
&gt; method name defined and __invoke(), and it hits home with other<br>
&gt; complaints about the current state of ZF: understanding how ZF is<br>
&gt; difficult when there&#39;s more than one way to do things.<br>
&gt;<br>
&gt; I want to be clear that the primary reason for using __invoke() in the=
<br>
&gt; first place is for dynamic calls using call_user_func() and<br>
&gt; call_user_func_array(). While using __invoke() with these is faster th=
an<br>
&gt; a traditional callback, it&#39;s still way slower than calling the met=
hod<br>
&gt; directly -- around 3 times slower. __invoke() simply provides a slight=
<br>
&gt; optimization in a pattern that we&#39;re likely to use many, many time=
s<br>
&gt; throughout a given request.<br>
&gt;<br>
&gt; For single usage, though, would you rather do this:<br>
&gt;<br>
&gt; =A0 =A0 $value =3D $plugin($data);<br>
&gt;<br>
&gt; =A0 =A0 or:<br>
&gt;<br>
&gt; =A0 =A0 $value =3D $plugin-&gt;filter($data);<br>
&gt;<br>
&gt; I realize it&#39;s a bit contrived -- you might name the object to bet=
ter<br>
&gt; describe its purpose. However, the latter more clearly explains what<b=
r>
&gt; you&#39;re doing to the data: you&#39;re filtering it. Let&#39;s look =
at a<br>
&gt; validator:<br>
&gt;<br>
&gt; =A0 =A0 $test =3D $plugin($value);<br>
&gt;<br>
&gt; =A0 =A0 or:<br>
&gt;<br>
&gt; =A0 =A0 $test =3D $plugin-&gt;isValid($value);<br>
&gt;<br>
&gt; I actually think this one benefits a ton -- even with a well-named<br>
&gt; variable:<br>
&gt;<br>
&gt; =A0 =A0 $test =3D $validator($value);<br>
&gt;<br>
&gt; What is &quot;$validator&quot;? and what is it doing here? When we cal=
l the<br>
&gt; method, we know we&#39;re checking for validity; when we call it via<b=
r>
&gt; __invoke(), we could be filtering it, validating it, pushing in a<br>
&gt; value... who knows?<br>
&gt;<br>
&gt; In my earlier post, I probably should have made it more clear: I see<b=
r>
&gt; __invoke() as a way to more easily and efficiently define and execute<=
br>
&gt; *callbacks*, and hence my rationale that it makes sense to define both=
<br>
&gt; an explicit method as well as __invoke() for those class types that wi=
ll<br>
&gt; be used with filter chains and/or brokers.<br>
&gt;<br>
&gt;<br>
&gt; &gt; On Thu, Apr 1, 2010 at 3:07 PM, Matthew Weier O&#39;Phinney<br>
&gt; &gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br>
&gt; &gt; &gt; I&#39;ve been following this thread as well as discussions o=
n IRC with<br>
&gt; &gt; &gt; interest, as, honestly, I can completely buy into all argume=
nts, which<br>
&gt; &gt; &gt; are, to sum things up:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0* Use only __invoke()<br>
&gt; &gt; &gt; =A0* Use a method name specific to the interface<br>
&gt; &gt; &gt; =A0* Use a standardized method name, such as &quot;run&quot;=
 or &quot;execute&quot;<br>
&gt; &gt; &gt; =A0* Use a combination of __invoke() and either a meaningful=
 or<br>
&gt; &gt; &gt; =A0 standardized method name.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I got to thinking about why I suggested &quot;__invoke()&quo=
t; in the first place,<br>
&gt; &gt; &gt; and went back to the plugin architecture page:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0* <a href=3D"http://framework.zend.com/wiki/display/ZFDEV=
2/Plugin+Architectures" target=3D"_blank">http://framework.zend.com/wiki/di=
splay/ZFDEV2/Plugin+Architectures</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The original rationale was for using pubsub/filter chain sys=
tems. In<br>
&gt; &gt; &gt; such systems, you attach callbacks:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0 =A0$chain-&gt;attach($callback);<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If your objects implement __invoke(), $callback can simply b=
e your<br>
&gt; &gt; &gt; object -- you&#39;re done. Otherwise, you also have to provi=
de the method:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0 =A0$chain-&gt;attach($object, $method);<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Interestingly, in this document, I also recommended that for=
 existing<br>
&gt; &gt; &gt; interfaces, __invoke() be added as an _additional_ method, a=
nd that it<br>
&gt; &gt; &gt; should proxy to the appropriate interface method. In this ca=
se, we&#39;d<br>
&gt; &gt; &gt; simply be taking advantage of a language feature in places i=
t makes<br>
&gt; &gt; &gt; sense.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Now, since the Symfony Live conference, I&#39;ve also been t=
hinking about<br>
&gt; &gt; &gt; something Fabien said about Symfony 2: &quot;less magic.&quo=
t; To clarify, the<br>
&gt; &gt; &gt; idea is to design components so that they are explicit about=
 what they<br>
&gt; &gt; &gt; can do. As an example, instead of using __get() and __set(),=
 using<br>
&gt; &gt; &gt; explicit getters and setters; instead of using __call(), exp=
licitly<br>
&gt; &gt; &gt; defining methods; instead of having __call() proxy to helper=
s, having a<br>
&gt; &gt; &gt; broker from which you pull them as needed.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This has several implications:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0* Less need for explicit documentation. If you have behav=
iors relying<br>
&gt; &gt; &gt; =A0 on the magic methods, developers *must* read the the doc=
umentation in<br>
&gt; &gt; &gt; =A0 order to know how a class/component works. If everything=
 is explicit,<br>
&gt; &gt; &gt; =A0 the class is self-documenting, and you can get the infor=
mation you<br>
&gt; &gt; &gt; =A0 need from API docs, your IDE, etc.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0* Performance. Magic methods are reportedly less performa=
nt than using<br>
&gt; &gt; &gt; =A0 straight method calls (more on this later).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; These are important factors, and the test-driven developer i=
n me<br>
&gt; &gt; &gt; particularly likes less magic; it&#39;s much easier to test =
when you have<br>
&gt; &gt; &gt; explicit behaviors.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; That said, I decided to run some tests. These were the scena=
rios:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0* No Proxying:<br>
&gt; &gt; &gt; =A0 * Defined &quot;filter&quot; method returns value<br>
&gt; &gt; &gt; =A0 * Defined &quot;__call&quot; method returns value<br>
&gt; &gt; &gt; =A0 * Defined &quot;__invoke&quot; method returns value<br>
&gt; &gt; &gt; =A0* Proxying:<br>
&gt; &gt; &gt; =A0 * Defined &quot;filter&quot; method returns value<br>
&gt; &gt; &gt; =A0 * Defined &quot;__call&quot; method proxies to &quot;fil=
ter&quot;<br>
&gt; &gt; &gt; =A0 * Defined &quot;__invoke&quot; method proxies to &quot;f=
ilter&quot;<br>
&gt; &gt; &gt; =A0* Inverse proxying<br>
&gt; &gt; &gt; =A0 * Defined &quot;filter&quot; method calls invoke (as &qu=
ot;$this();&quot;)<br>
&gt; &gt; &gt; =A0 * Defined &quot;__invoke&quot; method returns value<br>
&gt; &gt; &gt; =A0* call_user_func_array()<br>
&gt; &gt; &gt; =A0 * Using array($obj, &#39;filter&#39;) callback<br>
&gt; &gt; &gt; =A0 * Using __invoke() with no proxying<br>
&gt; &gt; &gt; =A0 * Using __invoke() with proxying<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The results were quite interesting. Across the board, using =
__call() is<br>
&gt; &gt; &gt; awful -- even if you simply return a value, it&#39;s on aver=
age 6x slower<br>
&gt; &gt; &gt; than a straight method call; proxying to another method, how=
ever,<br>
&gt; &gt; &gt; doesn&#39;t take significantly longer (so long as you&#39;re=
 not using<br>
&gt; &gt; &gt; call_user_func_array() internally, that is).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; __invoke(), however, turns out to be quite different. When n=
ot proxying,<br>
&gt; &gt; &gt; it&#39;s actually *faster* than a method call (about 25% on =
average).<br>
&gt; &gt; &gt; Proxing __invoke() to a method call or doing the inverse are=
 roughly the<br>
&gt; &gt; &gt; same speed -- about 2.5x slower than a straight method call =
(which, as<br>
&gt; &gt; &gt; you&#39;ll note, is still over twice as fast as using __call=
()).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; What was *really* interesting, however, was using<br>
&gt; &gt; &gt; call_user_func_array(), which is commonly used in filter cha=
ins and/or<br>
&gt; &gt; &gt; brokers. =A0__invoke(), with or without proxying, *always* w=
as around 30%<br>
&gt; &gt; &gt; *faster* than using an explicit array($obj, $method) callbac=
k.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So, what does this tell me?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0* AVOID using __call(), particularly for often-used metho=
d calls. For<br>
&gt; &gt; &gt; =A0 helper systems, it will always be better to use a helper=
 broker and<br>
&gt; &gt; &gt; =A0 command pattern.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; =A0* For classes meant to be used primarily with filter chai=
ns or brokers,<br>
&gt; &gt; &gt; =A0 DO use __invoke(), even if it simply proxies to another =
interface<br>
&gt; &gt; &gt; =A0 method.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So, based on the design goals and the performance benchmarki=
ng, I&#39;m<br>
&gt; &gt; &gt; going to recommend that Filter and Validator (we renamed Val=
idate to<br>
&gt; &gt; &gt; Validator) define an __invoke() method in addition to a more=
 explicit<br>
&gt; &gt; &gt; interface method, and that helpers also follow this pattern.=
<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -- Matthew Weier O&#39;Phinney &lt;<a href=3D"mailto:matthew=
@zend.com">[email-masked]</a>&gt; wrote<br>
&gt; &gt; &gt; (on Wednesday, 31 March 2010, 10:21 AM -0400):<br>
&gt; &gt; &gt;&gt; Greetings, all --<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Per the roadmap, one change we&#39;re planning on making=
 is making plugin<br>
&gt; &gt; &gt;&gt; usage consistent across components: plugins will impleme=
nt __invoke(),<br>
&gt; &gt; &gt;&gt; which makes them inherently callable.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; In our refactoring branch, I&#39;ve done this now with Z=
end_Filter. However,<br>
&gt; &gt; &gt;&gt; it required a ton of refactoring on the unit tests (had =
to either call<br>
&gt; &gt; &gt;&gt; __invoke() directly, or $filter($value)), and it got me =
to thinking:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Would it make sense to keep the original interfaces (fil=
ter, isValid,<br>
&gt; &gt; &gt;&gt; render, etc.), but also implement __invoke() -- having i=
t proxy to the<br>
&gt; &gt; &gt;&gt; appropriate interface method?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; As an example:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =A0 =A0 interface Filter<br>
&gt; &gt; &gt;&gt; =A0 =A0 {<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 public function filter($value);<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 public function __invoke($value);<br>
&gt; &gt; &gt;&gt; =A0 =A0 }<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =A0 =A0 class Digits implements Filter<br>
&gt; &gt; &gt;&gt; =A0 =A0 {<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 public function filter($value)<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 {<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 // ... logic...<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 }<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 public function __invoke($value)<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 {<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 return $this-&gt;filter($value);=
<br>
&gt; &gt; &gt;&gt; =A0 =A0 =A0 =A0 }<br>
&gt; &gt; &gt;&gt; =A0 =A0 }<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; The benefits:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =A0* Fewer changes necessary to existing unit tests<br>
&gt; &gt; &gt;&gt; =A0* interface method names may be more descriptive of i=
ntent<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Problems:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; =A0* Using __invoke() introduces overhead -- 2 method ca=
lls instead of one<br>
&gt; &gt; &gt;&gt; =A0* Redundancy (two methods doing the same thing)<br>
&gt; &gt; &gt;&gt; =A0* A few extra tests to write (to ensure __invoke work=
s as expecte)<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; After discussion with Ralph and Alex, I&#39;m leaning to=
wards having<br>
&gt; &gt; &gt;&gt; __invoke() as an _additional_ method, instead of replaci=
ng existing<br>
&gt; &gt; &gt;&gt; methods.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Any thoughts or comments?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; --<br>
&gt; &gt; &gt;&gt; Matthew Weier O&#39;Phinney<br>
&gt; &gt; &gt;&gt; Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:=
[email-masked]">[email-masked]</a><br>
&gt; &gt; &gt;&gt; Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://fr=
amework.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt; &gt; &gt;&gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew=
-pgp-key.asc" target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-ke=
y.asc</a><br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; --<br>
&gt; &gt; &gt; Matthew Weier O&#39;Phinney<br>
&gt; &gt; &gt; Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:matt=
[email-masked]">[email-masked]</a><br>
&gt; &gt; &gt; Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt; &gt; &gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp=
-key.asc" target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.as=
c</a><br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Matthew Weier O&#39;Phinney<br>
&gt; Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]=
om">[email-masked]</a><br>
&gt; Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.c=
om/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt; PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" =
target=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
&gt;<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</font></blockquote></div><br></div>

--00151750e6e0c457a30483308087--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 21 Oct 2009 00:54:40 +0400
From: Victor Farazdagi <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] oDesk API

Hi!
I want to create ZF proposal for recently released oDesk APIs 
(http://developers.odesk.com/).
Wanted to check out if that proposal would be interesting to anyone 
else? Is there actual need for such a proposal?

Thanks,
Victor

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 21 Mar 2010 15:15:00 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

>From the wiki guidelines I thought the direct() method would be
enforced in the Zend_View_Helper_Interface.
Anyway, the workaround I use in the meantime is defining __call() to
catch the helperBaseName() method call.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 17 Apr 2009 20:13:58 +0100
From: [email-masked]
To: [email-masked]
Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*

My contribution to 1.8 has been
Zend_Validate_Db_RecordExists & Zend_Validate_Db_NoRecordExists, =20
contributed by Ryan Mauger

Regards
Ryan Mauger
Quoting Thomas Weidner <[email-masked]>:

> * Zend_Filter_LocalizedToNormalized, contributed by Thomas Weidner
> * Zend_Filter_NormalizedToLocalized, contributed by Thomas Weidner
>
> ----- Original Message ----- From: "Benjamin Eberlei" <[email-masked]=
>
> To: <[email-masked]>
> Sent: Tuesday, April 07, 2009 8:51 AM
> Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*
>
>
>> * Added  Zend_Json Expression support, contributed by Benjamin Eberlei
>> * Added Zend_Http_Client_Adapter_Curl, contributed by Benjamin Eberlei
>>
>> On Monday 06 April 2009 22:07:01 Thomas Weidner wrote:
>>> My most important additions for 1.8 are:
>>>
>>> * several improvements to Zend_File_Transfer and Zend_Form_Element_File,
>>> contributed by Thomas Weidner
>>> * added file upload progress to Zend_File_Transfer, contributed by Thoma=
s
>>> Weidner
>>> * added 84 new IDN's and completly reworked Zend_Validate_Hostname,
>>> contributed by Thomas Weidner
>>> * added locale support to Zend_Validate_Int and Zend_Validate_Float,
>>> contributed by Thomas Weidner
>>> * added phonecode support to Zend_Locale, contributed by Thomas Weidner
>>> * Zend_Validate_Iban, contributed by Thomas Weidner
>>> * Zend_Validate_File_WordCount, contributed by Thomas Weidner
>>> * Zend_Filter_Encrypt, contributed by Thomas Weidner
>>> * Zend_Filter_Decrypt, contributed by Thomas Weidner
>>> * added logging support to Zend_Translate, contributed by Thomas Weidner
>>> * added documentation of all Zend_Validate messages, contributed by Thom=
as
>>> Weidner
>>>
>>> Greetings
>>> Thomas Weidner, I18N Team Leader, Zend Framework
>>> http://www.thomasweidner.com
>>>
>>> ----- Original Message -----
>>> From: "Wil Sinclair" <[email-masked]>
>>> To: "Robin Skoglund" <[email-masked]>
>>> Cc: <[email-masked]>
>>> Sent: Monday, April 06, 2009 8:02 PM
>>> Subject: RE: [zf-contributors] 1.8 PR feature list and *acknowledgements=
*
>>>
>>>
>>> I believe Zend_Navigation is in if the minor changes that we have
>>> recommended are made. Matthew can tell you more. It is a really sweet
>>> component, BTW. J
>>>
>>>
>>>
>>> ,Wil
>>>
>>>
>>>
>>> From: Robin Skoglund [mailto:[email-masked]]
>>> Sent: Monday, April 06, 2009 11:02 AM
>>> To: Wil Sinclair
>>> Cc: [email-masked]
>>> Subject: Re: [zf-contributors] 1.8 PR feature list and
>>> *acknowledgements*
>>>
>>>
>>>
>>> On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <[email-masked]> wrote:
>>>
>>> NOTE: For this release, we'd like to try something new in the feature
>>> list- actually acknowledging the significant contributions that y' all
>>> have made. J The format would be like this:
>>>
>>>
>>>
>>> * Zend_Application, contributed by Matthew Weier O'Phinney and Ben
>>> Scholzen
>>>
>>>
>>>
>>> ,Wil
>>>
>>> Hi, I haven't gotten any answer on whether Zend_Navigation will be
>>> included in the PR, but here goes:
>>>
>>> * Zend_Navigation, contributed by Robin Skoglund
>>>
>>>        robinsk
>>
>> --=20
>> Benjamin Eberlei
>> http://www.beberlei.de
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 20 Mar 2009 13:31:33 -0700
From: "Wil Sinclair" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>, <[email-masked]>
Subject: RE: [zf-contributors] Release Policies and Conventions

Hey Thomas, I'm not quite sure what you are referring to. Your
understanding is correct, and the wiki page seems to reflect it
perfectly. Can you tell me exactly what needs to be updated? Maybe with
the string that you're referring to?

Thanks.
,Wil

-----Original Message-----
From: Thomas Weidner [mailto:[email-masked]]=20
Sent: Friday, March 20, 2009 12:57 PM
To: Wil Sinclair; [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

Hy Wil,

In my understanding also "feature enhancements" are actually not allowed
to=20
be integrated within mini-releases.
Only "Bug fixes" which do not add additional API are allowed.

Maybe you should also add a definition for what's a bug fix, a
improvement=20
and a new feature to get that also defined, and we can all speak of the
same=20
in future.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 20, 2009 8:47 PM
Subject: [zf-contributors] Release Policies and Conventions

Over the 2 years that I've been involved with the project, there have
been many questions about what can go in to a given release and if there
are any guidelines for the release schedules. While many of you have
pieced the picture together from different mails, IRC chats, etc. I've
owed you a document for a long time now. Here it is:

http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
tions

I ask all contributors to review this and reply with any question or
edits- especially if I missed something- in this forum.

As always, thanks for all the time and effort. Also, go 1.8!

,Wil

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Giuseppe Roberti <[email-masked]>
To: [email-masked]
Date: Mon, 17 Aug 2009 03:25:44 +0200
Subject: [zf-contributors] Duplicated find() on
	Zend_Session_SaveHandler_DbTable

--=-y2QJqsbkvH41TezsBDon
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi list.

Walking thought the Zend Framework i have found that the
Zend_Session_SaveHandler_DbTable do twice the find() over the associated
DbTable; one in read() and another one in write().

Why ?
Maybe there's some reason that i don't know.
If not, here is a simple patch that erase this behavior.

Hope this is useful, thanks to all for the great job.

-- 
Giuseppe Roberti <[email-masked]>

--=-y2QJqsbkvH41TezsBDon
Content-Disposition: attachment;
	filename="zf-session-savehandler-dbtable-no-duplicate-find.patch"
Content-Type: text/x-patch;
	name="zf-session-savehandler-dbtable-no-duplicate-find.patch";
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

Index: DbTable.php
===================================================================
--- DbTable.php	(revision 17638)
+++ DbTable.php	(working copy)
@@ -127,6 +127,11 @@
     protected $_sessionName;
 
     /**
+     * Session rows from find()
+     */
+    protected $_rows = array();
+
+    /**
      * Constructor
      *
      * $config is an instance of Zend_Config or an array of key/value pairs containing configuration options for
@@ -324,6 +329,7 @@
                 $this->destroy($id);
             }
         }
+        $this->_rows = $rows;
 
         return $return;
     }
@@ -342,7 +348,7 @@
         $data = array($this->_modifiedColumn => time(),
                       $this->_dataColumn     => (string) $data);
 
-        $rows = call_user_func_array(array(&$this, 'find'), $this->_getPrimary($id));
+        $rows = $this->_rows;
 
         if (count($rows)) {
             $data[$this->_lifetimeColumn] = $this->_getLifetime($rows->current());

--=-y2QJqsbkvH41TezsBDon--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 18 Mar 2010 14:49:49 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

-- Ralf Eggert <[email-masked]> wrote
(on Monday, 15 March 2010, 10:34 PM +0100):
> Could you feed this discussion with some real world examples? For
> example "Foobarable" and "Foobarist" sound a little weird to me.
> 
> Please name some interfaces with their current name and the future
> variations for the options 1 to 8. Maybe this could help a little more
> in the discussion. For example how should Zend_Acl_Role_Interface oder
> Zend_Captcha_Adapter or Zend_Pdf_ElementFactory_Interface be renamed?

Example 1: Zend_Captcha_Adapter_Abstract

    namespace Zend\Captcha\Adapter;

    interface Adapter {}
    abstract class AbstractAdapter {}

Example 2: Zend_Acl_Role_Interace, Zend_Acl_Resource_Interface

    namespace Zend\Acl;

    interface Role;
    class GenericRole implements Role;
    class User implements Role;

    interface Resource;
    class GenericResource implements Resource;
    class Calendar implements Resource;

    namespace My\Acl\Resource;
    use Zend\Acl\Resource as AclResource;
    class Calendar implements AclResource {}

Example 3: Zend_Pdf_ElementFactory_Interface
    
    namespace Zend\Pdf;

    interface ElementLoader;
    class ElementFactory implements ElementLoader;

Those are just some ideas, but should show a variety of permutations
that would work.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 22 Nov 2009 17:05:07 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

-- Vincent de Lau <[email-masked]> wrote
(on Sunday, 22 November 2009, 05:55 PM +0100):
> Shoot, just remembered one of my observations. Always happens right after
> hitting submit...
> 
> Something I am wondering about, is how to integrate Zend_Server into the
> MVC. I could imagine that in the front controller, requests are not always
> dispatched to action controllers but could also be 'dispatched' to a
> Zend_Server. Maybe selecting a different dispatch process to use based on
> the (routed) request? This would also allow different dispatch/controller
> methods to be introduced.

This should actually be pretty easy to do if we adopt the solution I've
been prototyping and proposing. You could have an mvc.routing.post or
mvc.dispatching.pre plugin that checks to see if a "server" was
selected, and, if so, replace the dispatcher with a callback that
executes the given server.

> Related to this are request based levels of configuration. Acknowledging the
> overhead we introduced into our MVC stack, we had to create a separate entry
> point for AJAX calls. Using rewrite rules, we are now forwarding request
> that contain the string 'ajax' to a seperate 'index.php' (called ajax.php)
> that will only do a minimal bootstrap. I suppose Zend_Application might help
> here, together with improving our plug-in.

I blogged on this recently. With the current MVC, it's definitely
cheaper to handle AJAX requests on a separate endpoint. You can then
simply re-use your bootstrap to initialize the resources necessary for
the Ajax handlers.

With the current vision for ZF 2.0, you should be able to replace the
dispatch chain and/or response object on-the-fly, much as I describe
with servers above.

> One of the main issues is the loading of the routes, which is one of the
> things we removed from the AJAX bootstrap so that we will always use the
> default route. I've seen some mentioning of improving the routing process
> might solve this issue. 

Routing is actually not much of a bottleneck currently, actually.
Dispatching is. There's actually a test in the suite that loads and
processes 1000 routes, and does so in under a second.

> The other things that we have to do for AJAX calls are disabling
> layout and debug/profiling output (although they are being
> bootstrapped). Similar thing are being done for our webservices, which
> at the moment use the standard MVC architecture.

Right -- and this is where the new prototype shines, as you can replace
the response renderer on the fly -- which means you can inject a
renderer that simply serializes to JSON, or another renderer that
applies layouts, all depending on your needs.

> > -----Original Message-----
> > From: Vincent de Lau [mailto:[email-masked]]
> > Sent: Sunday, November 22, 2009 5:33 PM
> > To: [email-masked]
> > Subject: RE: [zf-contributors] Zend Framework 2.0 Roadmap
> > 
> > Hi all,
> > 
> > Although I'm not very involved in actual ZF development, I'd like to
> > let my
> > voice heard in the hope that it might inspire the people designing the
> > new
> > components. I'm working as lead developer at an Internet publisher,
> > where we
> > mainly develop comparison sites. I'll first describe how we are using
> > Zend
> > Framework, then I'll point out some things that we ran into and finally
> > I'll
> > have some general observations.
> > 
> > First some history: In the past, several developers before me developed
> > their own libraries and 'frameworks'. They where however flawed,
> > inconsistent and 'using classes' instead of doing object oriented
> > programming. A year and a half ago, I proposed to either rebuild the
> > existing framework from the ground up or start using a pre-existing
> > framework. The final choice was made to start using Zend Framework. The
> > reasons why we chose Zend is because it provided a good object oriented
> > base, while not tying us down. Using an open source solution over an
> > in-house solution also meant that documentation and support being
> > available,
> > while ensuring that there will always be people working on improving
> > the
> > framework.
> > 
> > Our first projects used ZF basically how it came out of the box. Off
> > course
> > we had to write some glue (mainly bootstrap) to put everything
> > together. In
> > the old framework, the 'controllers' where very fat, and our first ZF
> > application was to. Also, almost everything in the site (menu's, texts,
> > secondary content) was hard coded. Before starting out on our next big
> > project, I decided that it was necessary to make more stuff easily
> > configurable by non technical people and let the framework solve some
> > of our
> > problems to make our site more consistent.
> > 
> > We have developed a system where:
> > - page meta information including routing and layout is stored in a
> > database
> > - pages can contain multiple components which they can also inherit
> > from the
> > layout
> > - site structure (page hierarchy) is stored in the database
> > - ACL information is stored in the database and linked to pages and
> > page
> > components
> > - Non critical options are stored in the database (options not related
> > with
> > database access, error handling, logging and caching)
> > 
> > Our bootstrap takes care of setting up a database connection, error
> > handling, logging (two stage, first to mail, later to database),
> > profiling,
> > caching (APC), Zend_Session (DB storage), Zend_Mail (encoding, default
> > transport), Zend_View (XHTML, encoding), Zend_Layout and finally
> > dispatching
> > the request. We also created a small ORM that is also initialized in
> > the
> > bootstrap.
> > 
> > For our database driven stuff to work, we've created a plug-in that
> > handles
> > route loading from the database (cached), loading the ACL (cached),
> > applying
> > the ACL, injecting database parameters into the request, selecting the
> > appropriate layout, setting the meta information on the layout (title,
> > description, keywords) and dispatching additional components for
> > inclusion
> > in the layout.
> > 
> > This last task is controversial, because it uses
> > Zend_View_Helper_Action.
> > Components are considered to be individual actions on an action
> > controller.
> > The request parameters usually come from the database although they can
> > use
> > parameters from the original request. I've been looking for an
> > alternative
> > in the past, but the answer 'use view helpers' wasn't enough to solve
> > all my
> > issues.
> > 
> > 
> > With Zend 2.0, I want to refactor large parts of what we have done. For
> > instance, our site structure components where written before
> > Zend_Navigation
> > was complete. Our bootstrap process should be moved to use
> > Zend_Application
> > and we should cut down on the amount of singletons. These are pretty
> > trivial
> > tasks I suppose.
> > 
> > An area I'm not sure of yet is the Model or Domain part of the
> > application.
> > As said before, we used to have fat controllers that directly accessed
> > the
> > database. Currently we are using a custom ORM like solution that suits
> > our
> > needs; together with service type classes that either use the ORM or
> > access
> > the data source directly (we are also using web services). The ORM can
> > handle both generic objects, provided a custom mapper class has been
> > written, and ORM aware objects implementing an interface that allows
> > the ORM
> > layer to discover changed data and primary keys. I've been looking at
> > Zend_Entity before building our custom solution, but the time didn't
> > allow
> > to wait for it to become ready. We will be looking at Doctrine, but
> > might
> > favour and improve our custom solution.
> > 
> > Another area of improvement I'm looking out for is a better way to
> > control
> > and standardize form HTML. For straight forward forms, the standard way
> > forms are rendered is sufficient. However, designers and marketeers
> > have the
> > habit of having non standard requests. For some of our current forms,
> > this
> > required a lot a tweaking to get it right (before designers and
> > marketeers
> > change their mind off course...). A lot of the code I see is removing,
> > reordering or otherwise trying to undo stuff that is added by (default)
> > decorators. I suppose this is in part because our team hasn't got
> > enough
> > understanding how forms, form view helpers and decorators do their
> > work.
> > Honestly, I think that custom view helpers instead of the decorators
> > might
> > improve speed a lot.
> > 
> > Finally I'd also like to improve our page composition process. I'm not
> > sure
> > how Zend_Controller 2.0 will perform while executing multiple actions
> > in a
> > single request. I hope that it will improve or that we can more easily
> > reuse
> > the Dispatcher to perform a more lightweight secondary dispatch
> > process. I
> > think the main argument for the 'use view helpers' solution is that
> > reentering the dispatch is expensive. My argument against using view
> > helpers
> > was that I'd need to implement some sort of dispatch process to be able
> > to
> > dynamically perform helpers and put the output at a designated point in
> > the
> > layout. For our situation I've decided that the gained flexibility is
> > worth
> > the performance hit. We also reduced a lot of this overhead by
> > integrating
> > caching for components. To put this whole story in better perspective:
> > a non
> > programmer can create a (simple) new page, add content, set meta
> > information
> > and put it in the navigation in minutes, where in the past it would
> > cost a
> > programmer half an hour to develop, integrate and test.
> > 
> > 
> > Let's move on to the more general observations, not only based on my
> > experience at work, but also with some personal projects I'm working
> > on.
> > 
> > First of all, one of the things I love about ZF is the loose coupling.
> > However, this loose coupling also has its downsides since it requires
> > an
> > initial set of glue code to make it all work. Zend_Tool reduces some of
> > these requirements I suppose. I could imagine that it might be helpful
> > to
> > develop a example base application that contains a lot of the glue for
> > a new
> > developer to start with and customize as required. This might be in the
> > scope of Zend_Tool, but could also be part of a separate initiative
> > (Zendi,
> > Zend Integrated) to complement Zend_Tool, quick start and tutorials.
> > 
> > Secondly... well actually I thought I had a list when starting this
> > mail,
> > but I either forgot or already mentioned them above...
> > 
> > 
> > I hope that ZF 2.0 will mean a big improvement. I wouldn't mind if it
> > broke
> > major things if it results in a better, cleaner, leaner and more
> > consistent
> > framework. For me, ZF 2.0 will also be an opportunity to learn and
> > improve.
> > I hope that my mail provides some real world examples of how ZF is
> > being
> > used. I'll be available for questions and elaborations.
> > 
> > 
> > Well, let's close off by thanking all contributors for their efforts
> > and all
> > readers for sticking with me. I'm a ZF fan and am sure ZF 2.0 will only
> > increase my dedication.
> > 
> > Kind regards,
> > 
> > Vincent de Lau
> >  [email-masked]
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 22 Jan 2010 19:21:54 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Doctrine 1 Integration Ideas

> ah default module seems to be a problem, or not?. When should the defau=
lt
> prefix be added, when not? Is there a way to use the same names as alre=
ady
> used for controllers ?
Is there a way to use the same names as already used for controllers ?

Example 1: module =3D user | controller & model =3D User
modules/user/controllers/UserController.php   :   User_UserController
modules/user/models/UserModel.php   :   User_UserModel

Example 2: module =3D default | controller & model =3D User
modules/default/controllers/UserController.php   :  UserController
modules/default/models/UserModel.php   :   UserModel

Am 22.01.2010 14:36, schrieb Benjamin Eberlei:
> Hey Paddy,
>
> ah default module seems to be a problem, or not?. When should the defau=
lt
> prefix
> be added, when not? How does the resource autoloader work in this conte=
xt?
>
> Questions:
>
> 1. How does the resource loader look like if default module is "default=
"?
> 2. How does the resource loader look like if default module is "blog"?
>
> greetings,
> Benjamin
>
> On Fri, 22 Jan 2010 04:40:12 -0800 (PST), P=C3=A1draic Brady
> <[email-masked]> wrote:
>  =20
>> Replies inline.
>>
>>    =20
>>> Hello everyone,
>>>
>>> there hasn't been much news on this front lately, me was kinda busy w=
ith
>>> work and such.
>>>
>>> Yesterday I reviewed all the stuff i found on ZF and Doctrine 1
>>> integration and came to
>>> the conclusion that while single modular generation is supported by
>>> Doctrine 1.2's new
>>> PEAR style model generation you still have to hack lots around.
>>>
>>> Therefore my idea is, two-fold:
>>>
>>> I. Single ZF Module (Default)
>>>
>>> Support Single-Default-Module Scenario more easily by providing a
>>> config-option
>>> that automatically sets all the model-generation options correctly. T=
his
>>> would
>>> be something along the lines of:
>>>
>>> $import->setOptions(array(
>>>    'pearStyle' =3D> true,
>>>    'baseClassesDirectory' =3D> null,
>>>    'baseClassPrefix' =3D> 'Base_',
>>>    'classPrefix' =3D> 'Model_',
>>>    'classPrefixFiles' =3D> true
>>> ));
>>>
>>> This allows for models of the Style "Model_User", "Model_Foo",
>>> "Model_Bar".
>>>
>>> HOWEVER: Can someone explain to me how that relates to the class name
>>>      =20
> that
>  =20
>>> you can
>>> specifiy in the YAML config file?
>>>      =20
>> As in a schema config? Schema would just use Model_User/Model_Foo in
>>    =20
> this
>  =20
>> case. Not sure if that's what you meant though. The main settings abov=
e
>>    =20
> of
>  =20
>> interest are classPrefix and classPrefixFiles. classPrefix would simpl=
y
>> prepend the Module name for module autoloading, though I think
>> classPrefixFiles would be false to omit the Module name from the actua=
l
>> files, so we just have, for example, /application/models/User.php and
>> /application/models/Foo.php.
>>
>> Main thing I'd be interested in is of this option would support the mo=
re
>> complex scenario of having a named default module, e.g.
>> /application/modules/default (giving Default_Model_User at
>> /application/modules/default/models/User.php). I use a named default a=
ll
>> the time, though of course the ZF CLI tool isn't exactly cooperative
>>    =20
> with
>  =20
>> that ;).
>>
>>    =20
>>> No upgrade mechanism from single module to multiple module will be
>>> provided.
>>>
>>> II. Doctrine + Multiple ZF MOdules:
>>>
>>> Circumvent Doctrine_Core::loadModels() completely by introducing a ne=
w
>>> auto-loading
>>> mechanism and slightly modifying the Doctrine_Import_Schema class.
>>>      =20
>> I'd circumvent it anyway, isn't there anyway to leverage off our alrea=
dy
>> built in resource autoloading? That's already set up to handle all
>>    =20
> module
>  =20
>> contingencies for models, forms, etc. assigned to directories with tho=
se
>> names.
>>
>>    =20
>>> This style would do no magic, it would require you to use class names=
 of
>>> the kind:
>>>
>>> <ModuleName>_Model_<ModelName>
>>>
>>> Doctrine would auto-load all the classes of the kind in all
>>> <moduleName>/models through
>>> a Module Resource Loader.
>>>      =20
>> Spoke too soon - yeah, that's the way it probably should work by
>>    =20
> default.
>  =20
>> It's a current convention and if someone want's to start changing it
>> around, they can do their thing with the local include_path by
>>    =20
> themselves.
>  =20
>>    =20
>>> For the CLI tasks in Zend Tool there would be a dection of all models=
 by
>>> the mechanism.
>>>
>>> 1. Get Front Controller module/controller directory
>>> 2. Iteratore over them and find all models directories.
>>> 3. Recursively scan all models directories for
>>> <ModuleName>_Model_<ModelName> classes.
>>>
>>> For the YAML to Model Generation task the mechanism would be.
>>>
>>> 1. Detect Module name by checking the first result of explode("_",
>>> $className)
>>> 2. If the first is "Model", grab default module from Front-Controller=
,
>>> otherwise Check that second result is "Model"
>>> 3. Write record, base-record and optionally table classes into the
>>>      =20
> modules
>  =20
>>> model directory.
>>>      =20
>> Bear in mind that any module name can be the default. Not sure if that
>> makes any different if picked up as a distinct modules anyway.
>>
>>    =20
>>> This requires a Doctrine + Zend Modular Application to follow strict
>>>      =20
> class
>  =20
>>> naming standards,
>>> but makes the implementation very robust in terms of both frameworks =
and
>>> avoids any
>>> additional magic (Looking at the Doctrine 1 code, there is already to=
o
>>> much magic!)
>>>
>>> Any ideas?
>>>
>>> My plan is to get this into 1.11, I'll colaborate with Matthew Lurz a=
lso
>>> to get the
>>> Doctrine application resource ready for this then.
>>>
>>> Also my plan is that this integration will require Doctrine 1.2
>>>      =20
>> Doctrine 1.2 is fine. Little point supporting an older version whose u=
se
>> in new applications should be declining.
>>
>> greetings,
>> Benjamin
>>    =20
>  =20

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 13 Apr 2009 23:58:07 -0500
From: Ralph Schindler <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

>> - PEAR standards also stipulate capitalized abbreviations in mixed-case class
>> names, e.g., zend\controller\request\HTTP.  Do we adhere to that as well? 
>> $httpRequest = new request\HTTP()?
> 
> No, we can differentiate there. I think having the MixedCaseNames for
> protocols is easier to read and provides a nice visual cue that this is
> a class and not a constant.
> 

Actually, I find that to be a pretty arbitrary rule as well.  I think we 
should think about allowing acronyms to maintain their upper case-ness 
for a couple of reasons:  generally you dont mistake a class constant 
for a class name... But also, and more importantly, I go back to my 
original naming rule of being as concise as possible-

"Names should be as short as possible while concisely conveying the 
maximum amount of meaning they can."

In that case, I personally think it makes more sense give the class name 
a more accurate name:

Zend\Controller\Request\AbstractRequest
Zend\Controller\Request\HTTPRequest
Zend\Controller\Request\ConsoleRequest (or) CLIRequest

keep in mind, the namespace is not part of the class name, so it still 
makes sense to give the objects a concise naming.  It is possible for 
users to do this:

use Zend\Controller\Request as ZCR;

$r = new ZCR\HTTPRequest();

-ralph

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Thu, 14 May 2009 14:40:37 +0100
From: Ryan Mauger <[email-masked]>
Reply-To: [email-masked]
Organization: Lupimedia
To: [email-masked]
Subject: [zf-contributors] Zend_Service_Linkback proposal ready for review.

Good day to everyone!

Ben and myself have put together a proposal for Zend_Service_Linkback, 
to add Client and Server components to easily allow Pingback, Trackback 
and Refback services to be performed by ZF based applications.

We would appreciate any feedback on the proposal, and look forward to 
hearing from you all.

http://framework.zend.com/wiki/pages/viewpage.action?pageId=13107298

Kind Regards

Ryan Mauger

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 12:13:07 +0100
From: drm <[email-masked]>
To: Giorgio Sironi <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Hi Giorgio,

>  Currently there is an unofficial packageizer which works with 
> require_once() stetements:
> http://epic.codeutopia.net/pack/
> It is very useful since for instance if you want to use Zend_Form 
> there are a lot of classes from different components to check out, 
> from Zend_View in primis.

I have seen this one, and it is indeed very useful. Quite creative 
solution too, but e.g. pluginloaders would break.

> Since 2.0 will be autoloading base, we must have another mechanism to 
> define dependencies (php brutal code parsing or 'use' statements) if 
> we want to generate packages.

Maybe simply a @uses doccomment would suffice, so a tool could generate 
dependency graphs based on this. The @uses could be a very useful 
addition to the code standard as well.

Gerard

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 20 May 2009 00:48:24 +0200
From: till <[email-masked]>
To: Ralph Schindler <[email-masked]>
Cc: Vincent de Lau <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Zend_Session

On Tue, May 19, 2009 at 7:47 PM, Ralph Schindler
<[email-masked]> wrote:
>
>
>> Can register_shutdown_function()[1] be savely used to do this kind of
>> stuff?
>> In other words, does a function registered with
>> register_shutdown_function()
>> run before shutdown cleanup? Reading this[2] comment, I suppose it does.
>>
>
> No, even with register_shutdown_function(), you still cannot throw
> exceptions when there is exceptional behavior. =A0And this makes sense, b=
/c if
> PHP is in its shutdown mode, there is no way to execute your "exception
> catching" code anyway as it already might have been destroyed in the stac=
k.
>
> You get this error anytime you throw an exception at PHP Shutdown time:
>
> Fatal error: Exception thrown without a stack frame in Unknown on line 0
>
> -ralph
>

I've been thinking about this rewrite a lot and it seems like there's
a reason to avoid exceptions in Zend_Session. ;-) I've personally run
into the 'Exception thrown without a stack frame in Unknown on line 0'
error and it's pretty much a dead end and I always end up rewriting
the error handler etc..

So question is, do we really need exceptions here at all costs or
could we utilize PHP's error handler (e.g. E_NOTICE, E_USER_WARNING)
etc.. Point taken, it may be harder to grasp for the novice developer
but display_errors, log_errors etc. are all sort of no-brainers and I
see them as beginners stuff when it comes to developing PHP. I'd be
very much in favor of ditching exceptions all together in this
package.

(This is more or less a RFC, of course.)

Till

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: "Zend Framework Contributors" <[email-masked]>
Date: Sat, 14 Nov 2009 17:59:26 +0100
Subject: Re: [zf-contributors] I18N Webinar

Non of your points target translation.
They will be talked about when we given an Localization talk (Zend_Locale=
).

For this webinar it would take too much time to focus also on this points=
.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "P=E1draic Brady" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>
Cc: "Zend Framework Contributors" <[email-masked]>
Sent: Saturday, November 14, 2009 5:24 PM
Subject: Re: [zf-contributors] I18N Webinar

Just a few suggestions based on common problems:

1. UTF8 conversion (still lots of people without a clue - judging by how =
my=20
name is still not presented accurately on many sites).
2. Integer and Float normalisation across locales - particularly when=20
commas/periods are both accepted through forms.
3. Basics of designing a multi-lingual site (language detection, routing=20
solutions, IP region location).

Paddy

 P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

________________________________
From: Thomas Weidner <[email-masked]>
To: [email-masked]
Cc: [email-masked]; [email-masked]
Sent: Sat, November 14, 2009 12:53:46 PM
Subject: [zf-contributors] I18N Webinar

Hy ZF interested community,

I am preparing an webinar about I18N.
This one will be a speak about Translation and all what's related to this=
=20
task.

So here comes your part:
Which things do you want to know ?
Which informations do you miss from manual or other sources ?
What do you want to hear in this webinar ?

Don't be shy and just reply :-)

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 19 Jun 2009 10:43:14 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.8.4 code freeze

Greetings!

We plan to release ZF 1.8.4 this coming Tuesday, 23 June 2009. Code
freeze begins Sunday evening, 21 June 2009, at 23:59 UTC-0800.

Please contact myself or Alex if you have any additional 1.8.4 updates
to merge after that point.

Alex will send an email when sanity check packages are ready to review.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 16:13:37 -0800
From: Stanislav Malyshev <[email-masked]>
Organization: Zend Technologies
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

Hi!

> One consideration I have for 2.0 is to do a YAML backend for
> Zend_Config, which would consume sfYaml. This would allow you to do what

We have code for Zend_Config yaml backend sitting in the lab right now. 
It doesn't use sfYaml but that'd be a trivial change to add.

-- 
Stanislav Malyshev, Zend Software Architect
[email-masked]   http://www.zend.com/
(408)253-8829   MSN: [email-masked]

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Fri, 31 Jul 2009 11:52:54 +0200
Subject: Re: [zf-contributors] ZF 1.9.0 sanity check tarballs uploaded

I get a fatal error when running the whole testsuite:

Fatal error: Class 'Zend_Db_Skip_SqlsrvTest' not found in 
/tmp/ZendFramework-1.9.0/tests/Zend/Db/AllTests.php on line 186

On Friday 31 July 2009 02:36:33 am Matthew Weier O'Phinney wrote:
> Greetings!
>
> Packaging is complete for release 1.9.0 of Zend Framework. Until the
> release tomorrow, you can find packages at:
>
>   * Full packages:
>    
> http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramewor
>k-1.9.0.tar.gz
> http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramewor
>k-1.9.0.zip * Minimal packages:
>    
> http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramewor
>k-1.9.0-minimal.tar.gz
> http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramewor
>k-1.9.0-minimal.zip
>
> We also have packages up for AMF, Gdata, and InfoCard, and I can provide
> you those URLs if you need them.
>
> We will be releasing to the general public tomorrow morning, EDT, and I
> will be sending out announcements to the mailing lists and posting on
> DevZone once we have.

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Andy Fowler <[email-masked]>
Date: Mon, 22 Mar 2010 11:38:54 -0400
Cc: Eric Clemmons <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

Eric, that sounds right to me -- it's how most Github workflows operate, =
and it'd be terrific if we could use Github to submit pull requests to =
Matthew, even though he'll be merging them into the Zend-hosted repo.

A quick note on "atomic commits" in git. One of the things I had to =
learn when moving to Git was to get away from huge end-of-feature =
commits, like one would make in SVN. Eventually, it becomes easier to =
commit, revert, commit, revert many times during the course of a =
feature. At the end of the feature branch you can squash those many =
commits into a single atomic commit that contains all unit tests and =
docs:

http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

As a CLA'd but rare contributor, I'm really looking forward to the move =
to Git. In the past few months, I had given up on submitting patches. =
Nagging the IRC channel to pull something from JIRA was terribly =
inefficient -- hopefully this can smooth things along!

Andy

On Mar 22, 2010, at 11:21 AM, Eric Clemmons wrote:

> So, would a hypothetical (Github) workflow be as follows?
> ...
> 3.  Make atomic commits for unit tests, code changes, and new =
documentation
> ...
> On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:
>=20
>> ...
>>  Now, for an explanation of the "whys" behind this. As contributors,
>>  it's important to make atomic commits: your code fix should also
>>  include a corresponding unit test, and potentially a documentation
>>  commit as well. If we split the library and tests directories out
>>  into their own submodules, we cannot do so; the code and test must =
be
>>  committed separately, which is (a) more work, and (b) unintuitive.
>>  The same goes for related documentation commits.

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Mihai Bojin <[email-masked]>
Date: Wed, 20 Jan 2010 18:25:37 +0200
Cc: [email-masked]
To: Giorgio Sironi <[email-masked]>
Subject: Re: [zf-contributors] Zend_Grid component proposal

--Apple-Mail-48-82212710
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

That's subject to a different proposal
=
http://framework.zend.com/wiki/display/ZFPROP/Zend_Dojo+-+dojox.grid.DataG=
rid+Support+-+Matthew+Weier+O%27Phinney

that will actually be a View Helper.

My proposal intends to be a Zend Framework component that will be able =
to generate grids of data rendered in HTML. The target is mainly admin =
panels, but I will probably provide a way to render a grid using a =
partial.
That will mean that Zend_Grid will be able to be used for rendering any =
type of two-dimensional data (mostly SQL table data and arrays).

Mihai Bojin
PHP Web Developer

On Jan 20, 2010, at 6:02 PM, Giorgio Sironi wrote:

> On Wed, Jan 20, 2010 at 2:55 PM, Mihai Bojin <[email-masked]> =
wrote:
> Hello Everyone,
>=20
> I submitted a proposal for review and right now I'm waiting for any =
suggestions, advice, opinions and so on :)
>=20
> You can check out the proposal here:
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin
>=20
> Any feedback will be greatly appreciated !
>=20
>=20
> Do you intend to take advantage of Zend_Dojo? There is a dojo =
component named Datagrid which takes a lot of work to integrate =
currently, and that would be a nice feature.
>=20
> --=20
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi

--Apple-Mail-48-82212710
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">That's subject to a different proposal<div><a =
href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Dojo+-+dojox.gr=
id.DataGrid+Support+-+Matthew+Weier+O%27Phinney">http://framework.zend.com=
/wiki/display/ZFPROP/Zend_Dojo+-+dojox.grid.DataGrid+Support+-+Matthew+Wei=
er+O%27Phinney</a></div><div><br></div><div>that will actually be a View =
Helper.</div><div><br></div><div><br></div><div>My proposal intends to =
be a Zend Framework component that will be able to generate grids of =
data rendered in HTML. The target is mainly admin panels, but I will =
probably provide a way to render a grid using a partial.</div><div>That =
will mean that Zend_Grid will be able to be used for rendering any type =
of two-dimensional data (mostly SQL table data and =
arrays).</div><div><br></div><div>Mihai Bojin</div><div>PHP Web =
Developer</div><div><br></div><div><br></div><div><br><div><div>On Jan =
20, 2010, at 6:02 PM, Giorgio Sironi wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
class=3D"gmail_quote">On Wed, Jan 20, 2010 at 2:55 PM, Mihai Bojin <span =
dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px =
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: =
1ex;">
Hello Everyone,<br>
<br>
I submitted a proposal for review and right now I'm waiting for any =
suggestions, advice, opinions and so on :)<br>
<br>
You can check out the proposal here:<br>
<a =
href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bo=
jin" =
target=3D"_blank">http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+=
-+Mihai+Bojin</a><br>
<br>
Any feedback will be greatly appreciated !<br>
<br></blockquote><br>Do you intend to take advantage of Zend_Dojo? There =
is a dojo component named Datagrid which takes a lot of work to =
integrate currently, and that would be a nice feature.<br></div><br>-- =
<br>Giorgio Sironi<br>
Piccolo Principe &amp; Web Engineer<br><a =
href=3D"http://giorgiosironi.blogspot.com/">http://giorgiosironi.blogspot.=
com</a><br><a =
href=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgiosironi=
</a><br>
</blockquote></div><br></div></body></html>=

--Apple-Mail-48-82212710--

nFrom nobody Wed Apr  7 08:46:12 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Mon, 7 Dec 2009 17:11:52 +0100
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

I think it was created as extension to PHP's striptags allowing comments =
and=20
attributes to be whitelisted.

Still, as also PHP's own striptags method, it does not prevent on XSS or=20
other attacks. PHP mentions this within it's manual.

The ONLY secure way to use the striptags filter is to strip ALL=20
tags/attributes/comments.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Giorgio Sironi" <[email-masked]>
To: "P=E1draic Brady" <[email-masked]>
Cc: "Zend Framework Contributors" <[email-masked]>
Sent: Monday, December 07, 2009 4:02 PM
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In=20
Zend_Filter_StripTags

> But why it has been created at all?
>
> --=20
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
>=20

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Andy Fowler <[email-masked]>
Date: Thu, 28 Jan 2010 17:52:30 -0500
To: [email-masked]
Subject: [zf-contributors] ZF-8938

Hello,

I created http://framework.zend.com/issues/browse/ZF-8938 and added a =
patch (including unit tests), fixing instances where Zend_Form would =
corrupt values and validation messages when a form had a numeric name. =
Thomas mentioned that I should post a note here to get things rolling.

Also wanted to see what was required for commit access. I've got a CLA =
on file, and have submitted several other patches during bug hunt days. =
I'm the lead developer on a team developing a rather large project based =
on ZF. We're trying to be good open-source neighbors, and have submitted =
patches to other projects like Phing and Redmine. We are using a large =
swath of the framework -- probably 80% of the components.

Thanks for the great framework -- I'll be on this list and `afowler` on =
IRC.

Andy Fowler
Lead Developer, www.nutshell.com=

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 13:10:43 -0700
From: Matthew Ratzloff <[email-masked]>
To: Robin Skoglund <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming 
	Conventions

--001636c5b3f69a9e92046738f538
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

"I also notice that namespaces are written in Uppercase\Notation --
Zend\Controller\Request. Will this be the standard? Another alternative is
zend\controller\Request, which clearly distinguishes what's the namespace
and what's the class/interface."
Agreed.

-Matt

On Fri, Apr 10, 2009 at 12:42 PM, Robin Skoglund <[email-masked]> wrote:

> On Fri, Apr 10, 2009 at 20:24, Matthew Weier O'Phinney <[email-masked]>wrote:
>>
>>
>>  * Use generic, descriptive names indicative of functionality or behavior.
>> As
>>   examples from the SPL, "Countable", "Iterator", "ArrayObject".
>>
>
> I agree that this is the best approach.
>
> Will there be any guidelines on how to name classes which have all three
> (interface, abstract, concrete) in the same namespace? Example: Zend_View::
> * Zend_View_Interface ==> Zend\View\View? or Zend\View\IView?
> * Zend_View_Abstract ==> Zend\View\ViewObject? or Zend\View\BasicView?
> * Zend_View ==> Zend\View\View? or Zend\View\RunnableView?
>
> I also notice that namespaces are written in Uppercase\Notation --
> Zend\Controller\Request. Will this be the standard? Another alternative is
> zend\controller\Request, which clearly distinguishes what's the namespace
> and what's the class/interface.
>
>         robinsk
>

--001636c5b3f69a9e92046738f538
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

&quot;I also notice that namespaces are written in Uppercase\Notation -- Ze=
nd\Controller\Request. Will this be the standard? Another alternative is ze=
nd\controller\Request, which clearly distinguishes what&#39;s the namespace=
 and what&#39;s the class/interface.&quot;<div>
<br></div><div>Agreed.</div><div><br></div><div>-Matt<br><br><div class=3D"=
gmail_quote">On Fri, Apr 10, 2009 at 12:42 PM, Robin Skoglund <span dir=3D"=
ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im"><div class=3D"gmail_quote=
">On Fri, Apr 10, 2009 at 20:24, Matthew Weier O&#39;Phinney <span dir=3D"l=
tr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">matthew@zend.=
com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"border-=
left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex=
">

<br>
=C2=A0* Use generic, descriptive names indicative of functionality or behav=
ior. As<br>
 =C2=A0 examples from the SPL, &quot;Countable&quot;, &quot;Iterator&quot;,=
 &quot;ArrayObject&quot;.<font color=3D"#888888"><br>
</font></blockquote></div><br></div>I agree that this is the best approach.=
<br><br>Will there be any guidelines on how to name classes which have all =
three (interface, abstract, concrete) in the same namespace? Example: Zend_=
View::<br>

* Zend_View_Interface =3D=3D&gt; Zend\View\View? or Zend\View\IView?<br>* Z=
end_View_Abstract =3D=3D&gt; Zend\View\ViewObject? or Zend\View\BasicView?<=
br>* Zend_View =3D=3D&gt; Zend\View\View? or Zend\View\RunnableView?<br><br=
>I also notice that namespaces are written in Uppercase\Notation -- Zend\Co=
ntroller\Request. Will this be the standard? Another alternative is zend\co=
ntroller\Request, which clearly distinguishes what&#39;s the namespace and =
what&#39;s the class/interface.<br>

<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 robinsk<br>
</blockquote></div><br></div>

--001636c5b3f69a9e92046738f538--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
Date: Tue, 16 Mar 2010 09:35:28 +0000
Cc: "Zend Framework Contributors" <[email-masked]>
To: Ralph Schindler <[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

On 16 Mar 2010, at 06:26, Ralph Schindler wrote:
>=20
>=20
> Should library/framework specific code be more expressive using fully =
qualified names in method signatures and consequently in docblocks? Or =
is using unqualified names just as easy to understand and/or more =
readable?

I think that within a component, aliasing to the component should be =
used as you know where you are. If other components are used, then fully =
qualified names should be used for clarity.

Regards,

Rob...=

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Tue, 11 Aug 2009 00:33:18 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.9.1 sanity check packages.

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA1A56.2D22CFD8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all!

=20

The sanity check packages for ZF 1.9.1 are now available here:

http://framework.zend.com/releases/preview/ZendFramework-1.9.1.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1.zip

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-apidoc.ta
r.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-apidoc.zi
p

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-de
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-de
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-en
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-en
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-fr
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-fr
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-ja
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-ja
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-ru
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-ru
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-zh
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.9.1-manual-zh
.zip

=20

=20

Note that this is *NOT* the official release of 1.9.1. If we find no
major issues with these builds, we will issue official 1.9.1 release
from this tag soon.=20

Please do *NOT* log any issues found in these archives in the issue
tracker; instead post any major functional or packaging issues to this
list or mail them to me directly ([email-masked]).

=20

=20

With best regards,

   Alexander Veremyev.

=20

------_=_NextPart_001_01CA1A56.2D22CFD8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@SimSun";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:2.0cm 69.6pt 2.0cm 69.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Hi all!</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>The sanity check packages for ZF 1.9.1 are =
now
available here:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1.ta=
r.gz">http://framework.zend.com/releases/preview/ZendFramework-1.9.1.tar.=
gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1.zi=
p">http://framework.zend.com/releases/preview/ZendFramework-1.9.1.zip</a>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ap=
idoc.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-1.9=
.1-apidoc.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ap=
idoc.zip">http://framework.zend.com/releases/preview/ZendFramework-1.9.1-=
apidoc.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-de.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.9.1-manual-de.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-de.zip">http://framework.zend.com/releases/preview/ZendFramework-1.9=
.1-manual-de.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-en.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.9.1-manual-en.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-en.zip">http://framework.zend.com/releases/preview/ZendFramework-1.9=
.1-manual-en.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-fr.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.9.1-manual-fr.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-fr.zip">http://framework.zend.com/releases/preview/ZendFramework-1.9=
.1-manual-fr.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-ja.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.9.1-manual-ja.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-ja.zip">http://framework.zend.com/releases/preview/ZendFramework-1.9=
.1-manual-ja.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-ru.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.9.1-manual-ru.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-ru.zip">http://framework.zend.com/releases/preview/ZendFramework-1.9=
.1-manual-ru.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-zh.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.9.1-manual-zh.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.9.1-ma=
nual-zh.zip">http://framework.zend.com/releases/preview/ZendFramework-1.9=
.1-manual-zh.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Note that this is *NOT* the official release =
of 1.9.1.
If we find no major issues with these builds, we will issue official =
1.9.1
release from this tag soon. </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Please do *NOT* log any issues found in these =
archives
in the issue tracker; instead post any major functional or packaging =
issues to
this list or mail them to me directly =
([email-masked]).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>With best regards,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Alexander =
Veremyev.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01CA1A56.2D22CFD8--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 8 Apr 2009 10:35:05 +0300
From: Vadim Gabriel <[email-masked]>
To: Thomas Weidner <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] New Component proposal

--00504502b19490884a0467062b77
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Thanks Thomas, This sounds like a great approach. I assume using the same
method for all other providers such as moneybookers, 2checkout etc. To be
able to process credit cards there will be a need to use some sort of
provider, For example here in Israel we use Tranzilla as our credit card
processing provider, I don't think that processing a credit card can be done
without using one of the commonly used providers, So what would be the point
in creating the adapter class per credit card type, Instead of creating it
per payment provider?

I am eager to write down the proposal already, I just can't seem to enter
the JIRA since i don't remember my password (and waiting for Matthew to take
a look at my email).

Anyhow the information is much apprecited and helpful. Thanks.

On Wed, Apr 8, 2009 at 10:29 AM, Thomas Weidner <[email-masked]>wrote:

> Vadim,
>
> I would go for a adapter plugin.
> This OOP approach is used very commonly through the complete framework.
>
> So all base functions are defined in the base class and it handles how this
> calls are delegated to the set adapter.
>
> And you only have to create one adapter per each provider
> (Zend_Payment_Adapter_Visa / Zend_Payment_Adapter_Mastercard /
> Zend_Payment_Adapter_PayPal and so on). Your use will still only have to
> handle only the base class without to know about the adapter details.
>
> For example:
> $pay = new Zend_Payment($myOptions);
> $pay->checkPayment($data);
> $pay->transferMoney();
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "Vadim Gabriel" <[email-masked]>
> To: "Ben Scholzen 'DASPRiD'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 08, 2009 7:30 AM
> Subject: Re: [zf-contributors] New Component proposal
>
>
>
>  Hey,
>>
>> Thanks, For the help with the password thing, I will email Matthew.
>>
>> About the component, I have no problem in writing a unified API, My full
>> time job is building Ecommerce stores, So i have quite a log of code
>> already
>> written that utilize all sort of payment providers, I could probably write
>> down the ones i have worked with and completely sure that i will be able
>> to
>> include them in the unifed API component. The thing is i don't know where
>> to
>> start really, Where do i open a proposal? What do i need to write down in
>> there?
>>
>> For the unified thing, I was thinking on creating a seperate class for
>> every
>> payment provider, Like Zend_Payment_Paypal, Zend_Payment_2Checkout etc,
>> Would that work? or does it have to be just one class and using a
>> constructor method to initialize the required payment provider class? Such
>> as
>>
>> $paypal = new Zend_Payment('paypal');
>> $2checkout = new Zend_Payment('2checkout');
>>
>> I can do either, Which ever sounds better is fine with me.
>>
>> Thanks again for the help.
>>
>> Vince.
>>
>> On Tue, Apr 7, 2009 at 11:57 PM, Ben Scholzen 'DASPRiD' <[email-masked]
>> >wrote:
>>
>>  -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> You may probably ask Matthew or Wil about the password thingy.
>>>
>>> Then, to your proposal:
>>> There were some proposals for payment components, but mostly the just
>>> included single payment methods, and did not cover multiple ones. We
>>> discussed that a few times, and what we need is a component which offers
>>> (if possible) a unified API for all payment providers. When you are
>>> willing to do so, feel free to get on with your proposal, I will follow
>>> it with interest.
>>>
>>> Regards,
>>> Ben
>>> ...................................
>>> :  ___   _   ___ ___ ___ _ ___    :
>>> : |   \ /_\ / __| _ \ _ (_)   \   :
>>> : | |) / _ \\__ \  _/   / | |) |  :
>>> : |___/_/:\_\___/_| |_|_\_|___/   :
>>> :........:........................:
>>> : Web    : http://www.dasprids.de :
>>> : E-mail : [email-masked]       :
>>> : Jabber : [email-masked]     :
>>> : ICQ    : 105677955              :
>>> :........:........................:
>>>
>>>
>>> Vadim Gabriel schrieb:
>>> > Hey,
>>> >
>>> > I have never added a new proposal and searched the wiki about how to
>>> > make those. I found this "Image" that displays the work flow of adding
>>> > a
>>> > new component, From opening a new proposal in the wiki upto getting it
>>> > approved by the Zend Team.
>>> > I have a few problems tough.
>>> >
>>> > First i have lost my password, And now i can't access JIRA. I already
>>> > signed the CLA, And would have reset my password, I just couldn't find
>>> > the lost password feature anywhere. Do i need to ask someone to reset >
>>> it
>>> > for me?
>>> > Second, Where and how do i start a new Wiki page about the component i
>>> > would like to contribute. Do i need to add anything special like >
>>> special
>>> > information about it, Besides the usual description and technical
>>> > specifications?
>>> > Third, My component that i would like to share is Zend_Payments_Paypal
>>> > class that allows to use paypal. This is the only thing i made so far >
>>> by
>>> > myself for Zend Framework but since i am working a lot with Ecommerce i
>>> > will probably be writting more payment transfer options such as Google
>>> > checkout, Moneybookers, 2checkout and more. I would like to know if >
>>> this
>>> > is something that might interest people and actually make it's way to
>>> > the library rather then the archive?
>>> >
>>> > Thanks, Vince.
>>> >
>>> > --
>>> > Vincent Gabriel.
>>> > Lead Developer, Senior Support.
>>> > Zend Certified Engineer.
>>> > Zend Framework Certified Engineer.
>>> >
>>> >
>>> >
>>> >
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>
>>> iEYEARECAAYFAknbvj4ACgkQ0HfT5Ws789AIsQCffrVw9VETkPXTCgn/i9yD9XHh
>>> FwoAnRZ2/VyJngOvolSD2Vg7ww7OLgLe
>>> =Qkwd
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>
>>
>> --
>> Vincent Gabriel.
>> Lead Developer, Senior Support.
>> Zend Certified Engineer.
>> Zend Framework Certified Engineer.
>>
>>
>

-- 
Vincent Gabriel.
Lead Developer, Senior Support.
Zend Certified Engineer.
Zend Framework Certified Engineer.

--00504502b19490884a0467062b77
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks Thomas, This sounds like a great approach. I assume=
 using the same method for all other providers such as moneybookers, 2check=
out etc. To be able to process credit cards there will be a need to use som=
e sort of provider, For example here in Israel we use Tranzilla as our cred=
it card processing provider, I don&#39;t think that processing a credit car=
d can be done without using one of the commonly used providers, So what wou=
ld be the point in creating the adapter class per credit card type, Instead=
 of creating it per payment provider?<br>
<br>I am eager to write down the proposal already, I just can&#39;t seem to=
 enter the JIRA since i don&#39;t remember my password (and waiting for Mat=
thew to take a look at my email).<br><br>Anyhow the information is much app=
recited and helpful. Thanks.<br>
<br><div class=3D"gmail_quote">On Wed, Apr 8, 2009 at 10:29 AM, Thomas Weid=
ner <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">thomas.w=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex=
; padding-left: 1ex;">
Vadim,<br>
<br>
I would go for a adapter plugin.<br>
This OOP approach is used very commonly through the complete framework.<br>
<br>
So all base functions are defined in the base class and it handles how this=
 calls are delegated to the set adapter.<br>
<br>
And you only have to create one adapter per each provider (Zend_Payment_Ada=
pter_Visa / Zend_Payment_Adapter_Mastercard / Zend_Payment_Adapter_PayPal a=
nd so on). Your use will still only have to handle only the base class with=
out to know about the adapter details.<br>

<br>
For example:<br>
$pay =3D new Zend_Payment($myOptions);<br>
$pay-&gt;checkPayment($data);<br>
$pay-&gt;transferMoney();<br>
<br>
Greetings<br>
Thomas Weidner, I18N Team Leader, Zend Framework<br>
<a href=3D"http://www.thomasweidner.com" target=3D"_blank">http://www.thoma=
sweidner.com</a><br>
<br>
----- Original Message ----- From: &quot;Vadim Gabriel&quot; &lt;<a href=3D=
"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br=
To: &quot;Ben Scholzen &#39;DASPRiD&#39;&quot; &lt;<a href=3D"mailto:mail@d=
asprids.de" target=3D"_blank">[email-masked]</a>&gt;<br>
Cc: &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank"=
>[email-masked]</a>&gt;<br>
Sent: Wednesday, April 08, 2009 7:30 AM<br>
Subject: Re: [zf-contributors] New Component proposal<div><div></div><div c=
lass=3D"h5"><br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey,<br>
<br>
Thanks, For the help with the password thing, I will email Matthew.<br>
<br>
About the component, I have no problem in writing a unified API, My full<br=
time job is building Ecommerce stores, So i have quite a log of code alread=
y<br>
written that utilize all sort of payment providers, I could probably write<=
br>
down the ones i have worked with and completely sure that i will be able to=
<br>
include them in the unifed API component. The thing is i don&#39;t know whe=
re to<br>
start really, Where do i open a proposal? What do i need to write down in<b=
r>
there?<br>
<br>
For the unified thing, I was thinking on creating a seperate class for ever=
y<br>
payment provider, Like Zend_Payment_Paypal, Zend_Payment_2Checkout etc,<br>
Would that work? or does it have to be just one class and using a<br>
constructor method to initialize the required payment provider class? Such<=
br>
as<br>
<br>
$paypal =3D new Zend_Payment(&#39;paypal&#39;);<br>
$2checkout =3D new Zend_Payment(&#39;2checkout&#39;);<br>
<br>
I can do either, Which ever sounds better is fine with me.<br>
<br>
Thanks again for the help.<br>
<br>
Vince.<br>
<br>
On Tue, Apr 7, 2009 at 11:57 PM, Ben Scholzen &#39;DASPRiD&#39; &lt;<a href=
=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;wrot=
e:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
You may probably ask Matthew or Wil about the password thingy.<br>
<br>
Then, to your proposal:<br>
There were some proposals for payment components, but mostly the just<br>
included single payment methods, and did not cover multiple ones. We<br>
discussed that a few times, and what we need is a component which offers<br=
(if possible) a unified API for all payment providers. When you are<br>
willing to do so, feel free to get on with your proposal, I will follow<br>
it with interest.<br>
<br>
Regards,<br>
Ben<br>
...................................<br>
: =A0___ =A0 _ =A0 ___ ___ ___ _ ___ =A0 =A0:<br>
: | =A0 \ /_\ / __| _ \ _ (_) =A0 \ =A0 :<br>
: | |) / _ \\__ \ =A0_/ =A0 / | |) | =A0:<br>
: |___/_/:\_\___/_| |_|_\_|___/ =A0 :<br>
:........:........................:<br>
: Web =A0 =A0: <a href=3D"http://www.dasprids.de" target=3D"_blank">http://=
www.dasprids.de</a> :<br>
: E-mail : <a href=3D"mailto:[email-masked]" target=3D"_blank">mail@daspr=
ids.de</a> =A0 =A0 =A0 :<br>
: Jabber : <a href=3D"mailto:[email-masked]" target=3D"_blank">jabber@d=
asprids.de</a> =A0 =A0 :<br>
: ICQ =A0 =A0: 105677955 =A0 =A0 =A0 =A0 =A0 =A0 =A0:<br>
:........:........................:<br>
<br>
<br>
Vadim Gabriel schrieb:<br>
&gt; Hey,<br>
&gt;<br>
&gt; I have never added a new proposal and searched the wiki about how to<b=
r>
&gt; make those. I found this &quot;Image&quot; that displays the work flow=
 of adding &gt; a<br>
&gt; new component, From opening a new proposal in the wiki upto getting it=
<br>
&gt; approved by the Zend Team.<br>
&gt; I have a few problems tough.<br>
&gt;<br>
&gt; First i have lost my password, And now i can&#39;t access JIRA. I alre=
ady<br>
&gt; signed the CLA, And would have reset my password, I just couldn&#39;t =
find<br>
&gt; the lost password feature anywhere. Do i need to ask someone to reset =
&gt; it<br>
&gt; for me?<br>
&gt; Second, Where and how do i start a new Wiki page about the component i=
<br>
&gt; would like to contribute. Do i need to add anything special like &gt; =
special<br>
&gt; information about it, Besides the usual description and technical<br>
&gt; specifications?<br>
&gt; Third, My component that i would like to share is Zend_Payments_Paypal=
<br>
&gt; class that allows to use paypal. This is the only thing i made so far =
&gt; by<br>
&gt; myself for Zend Framework but since i am working a lot with Ecommerce =
i<br>
&gt; will probably be writting more payment transfer options such as Google=
<br>
&gt; checkout, Moneybookers, 2checkout and more. I would like to know if &g=
t; this<br>
&gt; is something that might interest people and actually make it&#39;s way=
 to<br>
&gt; the library rather then the archive?<br>
&gt;<br>
&gt; Thanks, Vince.<br>
&gt;<br>
&gt; --<br>
&gt; Vincent Gabriel.<br>
&gt; Lead Developer, Senior Support.<br>
&gt; Zend Certified Engineer.<br>
&gt; Zend Framework Certified Engineer.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href=3D"http://enigmail.mozdev.org" =
target=3D"_blank">http://enigmail.mozdev.org</a><br>
<br>
iEYEARECAAYFAknbvj4ACgkQ0HfT5Ws789AIsQCffrVw9VETkPXTCgn/i9yD9XHh<br>
FwoAnRZ2/VyJngOvolSD2Vg7ww7OLgLe<br>
=3DQkwd<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Vincent Gabriel.<br>
Lead Developer, Senior Support.<br>
Zend Certified Engineer.<br>
Zend Framework Certified Engineer.<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Vincent Gab=
riel.<br>Lead Developer, Senior Support.<br>Zend Certified Engineer.<br>Zen=
d Framework Certified Engineer.<br><br><br><br><br>
</div>

--00504502b19490884a0467062b77--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 18:17:27 +0100
From: Sascha-Oliver Prolic <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

Hi all,

As view helpers are neither strategy nor command, I prefer the use of
the "__invoke" method, instead of "execute" or "direct". This will
also give a much smoother interface.

-- 
Sascha-Oliver Prolic
Intelligent Web Services Ltd.

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 4 Jan 2010 14:43:55 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Schedule for 1.10, 1.9.7

Greetings, all --

We've had to do some shuffling about with the 1.10 and 1.9.7 schedules,
and I'd like to share them with you today.

First, due to some last minute issues that have come in, we're pushing
the 1.9.7 release to this Thursday; freeze will happen Wednesday
evening.

Second, this means pushing back the beta for 1.10.0; we'll target next
Tuesday, the 12th of January, for the beta release. If all goes well,
then we'll do an initial RC on the 19th, and the final release on the
26th.

As such, feature freeze for 1.10.0 will be Sunday night; if you have
code in for completed proposals, and it's not yet in trunk, please
contact me ASAP so I can schedule a review.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Cc: [email-masked]
From: Jon Whitcraft <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Date: Sat, 11 Apr 2009 14:11:04 -0400
Subject: Re: [zf-contributors] [[email-masked]: Re: [zf-contributors]
	Proposal to update Abstract/Interface Naming Conventions]

--Boundary_(ID_UWFLBsceq5dFqYR5ru1coQ)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT

I too like Matt's idea of having standard names for abstract and  
interface.

	Jon Whitcraft
Zend Certified Engineer
[email-masked]
On Apr 11, 2009, at 12:07 PM, Benjamin Eberlei wrote:

> i fully agree with matt on this issue :-)
>
> it should be obvious for a user by looking at the classes, free- 
> style naming
> isn't really obvious
>
> regards,
> Benjamin
>
> On Saturday 11 April 2009 17:57:16 Matthew Ratzloff wrote:
>> "There have been a TON of debates amongst ZF contributors about  
>> naming,
>> and making the names meaningful. I would expect that this proposal  
>> would
>> probably be very welcome to those individuals. (Matt R., I'm  
>> looking at
>> you...)"
>> Meaningful names are great!  It just depends on what you mean by
>> "meaningful".  For me, it mean clearly communicating the role of a  
>> class,
>> so that users can instantly determine how classes are interrelated,  
>> even if
>> they're navigating the code online.  Right now we have that: it is  
>> clear
>> that Zend_Controller_Request_Http extends  
>> Zend_Controller_Request_Abstract,
>> even before you open either, and even if you aren't using an IDE.
>> Zend_Controller_Request_Http extending Zend_Controller_Request  
>> would also
>> communicate that.  I would like to retain that quality of the file
>> organization.
>>
>> With the following names...
>>
>> * Zend\Controller\Request\RequestEnvironment, RequestObject
>>   (interface, abstract)
>> * Zend\Controller\Response\ResponsePayload, ResponseObject
>>   (interface, abstract)
>> * Zend\Controller\Dispatcher\DispatchMapper (interface)
>>
>> ...excepting this one...
>>
>> * Zend\Validate\Validatible, Validator (interface, abstract)
>>
>> ...it is not really apparent what relates to what.   
>> RequestEnvironment does
>> not communicate Interface to me, and RequestObject does not  
>> communicate
>> abstract.  While you may say that that's irrelevant because we have  
>> IDEs, I
>> would say that these names have the potential to be more confusing,  
>> because
>> there are no rules for how environments and objects and payloads and
>> mappers are related.  If I'm looking to extend one of these classes  
>> (which
>> happens frequently), I have to study a few classes to figure out how
>> everything interacts.  Today I can open the abstract or interface  
>> and get
>> right to work.
>>
>> One other thing.  There are going to be cases where these names are  
>> going
>> to be really awkward.  One of the great things about frameworks in  
>> general
>> is that they remove choices so that you can focus on getting the  
>> job done.
>> IRequest, IResponse--there is no thought required for these names.   
>> But in
>> the other scenario contributors must determine whether  
>> RequestEnvironment,
>> RequestObject, Requestable, or whatever most effectively  
>> communicates its
>> role.
>>
>> If we go this route, I also think we're going to end up  
>> standardizing on
>> some things simply in an effort to avoid the above.  I think Object  
>> will
>> become a stand-in for Abstract, for example (RequestObject).  I think
>> standardization of this kind results in a clear API, but in effect,  
>> it is a
>> form of limited Hungarian notation through the back door.  If we are
>> ultimately going to go that route, we should just do it up front.
>> Honestly, I would even be OK with AbstractRequest and  
>> RequestInterface,
>> although I know you would hate that idea.  :-)
>>
>> -Matt
>>
>> On Fri, Apr 10, 2009 at 4:13 PM, Matthew Weier O'Phinney
>>
>> <[email-masked]>wrote:
>>> -- Matthew Weier O'Phinney <[email-masked]> wrote
>>>
>>> (on Friday, 10 April 2009, 04:39 PM -0400):
>>>> Forwarding from Ben, who intended to copy the list...
>>>>
>>>> ----- Forwarded message from Benjamin Eberlei <[email-masked]>
>>>
>>> -----
>>>
>>>> From: Benjamin Eberlei <[email-masked]>
>>>> To: Matthew Weier O'Phinney <[email-masked]>
>>>> Date: Fri, 10 Apr 2009 18:58:02 +0000
>>>> Subject: Re: [zf-contributors] Proposal to update Abstract/ 
>>>> Interface
>>>
>>> Naming
>>>
>>>>      Conventions
>>>>
>>>>
>>>> moving to this new namespace implementation and breaking all old  
>>>> ones
>>>> is
>>>
>>> a
>>>
>>>> serious BC,
>>>> so why do we only allow slight changes for everything else? I  
>>>> thought
>>>> we would just go to "change the serious technical debt, but as BC  
>>>> as
>>>> possible", changing the name of an interface is the exact  
>>>> difference of
>>>> that.
>>>
>>> It is, but we're going to need to do it once we move to namespaces
>>> anyways -- because our CS were written before namespaces were even
>>> proposed for inclusion in PHP.
>>>
>>> This is also why I propose the gradual changes over a series of
>>> versions. This allows us to provide migration instructions that  
>>> users
>>> can gradually implement, making their code more future-proof. If the
>>> new versions of the interfaces and abstract classes extend the
>>> originals, there is no BC break until we finally drop the old  
>>> classes --
>>> which, as I mentioned, will not happen until 2.0.
>>>
>>>> additionally, the generic name one seems strange in my eyes. How  
>>>> would
>>>
>>> you
>>>
>>>> do that for
>>>> the example of request, response, dispatcher? Validation interface?
>>>
>>> First off, the request and response objects need interfaces, and  
>>> then
>>> potentially abstract implementations. Either way, this is easy:
>>>
>>> * Zend\Controller\Request\RequestEnvironment, RequestObject
>>>   (interface, abstract)
>>> * Zend\Controller\Response\ResponsePayload, ResponseObject
>>>   (interface, abstract)
>>> * Zend\Controller\Dispatcher\DispatchMapper (interface)
>>> * Zend\Validate\Validatible, Validator (interface, abstract)
>>>
>>> The names take a little creativity, but they also make it clearer in
>>> your code what you're doing:
>>>
>>>   namespace Zend\Controller\Request;
>>>
>>>   class HttpEnvironment implements RequestEnvironment
>>>   {
>>>   }
>>>
>>>   // or
>>>   namespace Zend\Validate;
>>>
>>>   class Alpha extends Validator
>>>   {
>>>    }
>>>
>>>> i don't seem to find good ones. ResponseObject, RequestObject,
>>>> Validatable are ok, but from the typehints its very hard to suggest
>>>> that these are interfaces in contrast to concrete implementation.
>>>
>>> Typehints should typically be to interfaces anyways...
>>>
>>>> furthermore, why break with the ways of java, python, and .net?  
>>>> this is
>>>> what many programmers are used to.
>>>
>>> Because Java and .Net are strongly typed languages, and PHP isn't.
>>> Because just because a convention worked for one language doesn't  
>>> mean
>>> it's appropriate for another. Because PHP is not Java, is not  
>>> Python, is
>>> not .NET.
>>>
>>> There have been a TON of debates amongst ZF contributors about  
>>> naming,
>>> and making the names meaningful. I would expect that this proposal  
>>> would
>>> probably be very welcome to those individuals. (Matt R., I'm  
>>> looking at
>>> you...)
>>>
>>>> As a last point, having implementation and interface in different
>>>> packages is actually the single most important issue about having  
>>>> an
>>>> interface anyways and a huge benefit for object oriented design.   
>>>> this
>>>> separates the concerns and reduces dependencies, so I would love to
>>>> see this in a 2.0 version.
>>>
>>> There's a difference between using an interface in userland code,  
>>> and
>>> using one within a framework or library. In your userland code, you
>>> *will* have the interface in a different package:
>>>
>>>   namespace Foo\Controller\Request;
>>>   import Zend\Controller\Request as ZfRequest;
>>>
>>>   CustomHttpRequest extends ZfRequest\HttpEnvironment
>>>   {
>>>   }
>>>
>>> *Within* the framework, it's better for them to be in the same
>>> namespace, to allow selectively packaging components for  
>>> distribution or
>>> deployment.
>>>
>>>> That is what i am greatly missing in ZF, that for example the
>>>> controller is implemented with several very large abstract classes
>>>> only and the dependencies are so hard-wired that its impossible to
>>>> exchange just one part of the controller to add specific  
>>>> functionality
>>>> without having to change considerable other parts also.
>>>
>>> This has nothing to do with naming conventions, and is a topic we
>>> already plan to address for (or before) 2.0. (Please search for
>>> "Zend_Controller 2.0" on the wiki for some of the plans.)
>>>
>>>> On Fri, 10 Apr 2009 14:24:34 -0400, Matthew Weier O'Phinney
>>>>
>>>> <[email-masked]> wrote:
>>>>> Greetings, all --
>>>>>
>>>>> Below is a proposal I am making to modify the Zend Framework  
>>>>> Coding
>>>>> Standards conventions for the naming of Interfaces and Abstract
>>>
>>> classes.
>>>
>>>>> This decision is basically already made, but I'd appreciate any
>>>
>>> feedback
>>>
>>>>> that you may have on the matter.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> The problem
>>>>> ===========
>>>>> PHP 5.3 introduces namespaces to the PHP language. While this  
>>>>> won't
>>>
>>> have
>>>
>>>>> an
>>>>> impact much on userland code, it will have an impact on library  
>>>>> and
>>>>> framework
>>>>> code, as it provides a useful paradigm for organizing components  
>>>>> as
>>>
>>> well
>>>
>>>>> as
>>>>> simplifying syntax. Instead of having to say things like:
>>>>>
>>>>>    $analyzer = new
>>>>
>>>> Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
>>>>
>>>>> we can instead do something like this:
>>>>>
>>>>>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>>>>>
>>>>>    $analyzer = new Common_TextNum();
>>>>>
>>>>> or even:
>>>>>
>>>>>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>>>>>
>>>>>    class Common_TextNum extends Common
>>>>>    {
>>>>>    }
>>>>>
>>>>> The problem that arises for Zend Framework has to do with how we  
>>>>> name
>>>>> abstract
>>>>> classes and interfaces. Currently, the final segment of such  
>>>>> classes
>>>
>>> are
>>>
>>>>> expected to end with _Abstract and _Interface, respectively. This
>>>>> will
>>>>
>>>> not
>>>>
>>>>> work
>>>>> when we migrate to utilize namespaces, for two reasons.
>>>>>
>>>>> First, and most obviously, 'abstract' and 'interface' are reserved
>>>>> PHP keywords.
>>>>> As such, in situations such as the following:
>>>>>
>>>>>    namespace Zend\Controller\Request;
>>>>>
>>>>>    class Abstract
>>>>>    {
>>>>>    }
>>>>>
>>>>>    // or:
>>>>>
>>>>>    namespace Zend\Controller\Dispatcher;
>>>>>
>>>>>    interface Interface
>>>>>    {
>>>>>    }
>>>>>
>>>>> we'll run into issues.
>>>>>
>>>>> Second, and less obvious, is that perhaps the easiest solution  
>>>>> breaks
>>>
>>> one
>>>
>>>>> of the
>>>>> key principles of namespaces (which are designed to help  
>>>>> encapsulate
>>>>> components). This one's harder to explain, so let's look at  
>>>>> examples.
>>>>> Consider a
>>>>> component such as Zend_Controller_Request. The simplest solution
>>>>> would
>>>
>>> be
>>>
>>>>> to
>>>>> name the abstract class or interface Zend\Controller\Request, and
>>>>> then have the
>>>>> various concrete implementations under that namespace:
>>>>>
>>>>>    namespace Zend\Controller;
>>>>>
>>>>>    interface Request
>>>>>    {
>>>>>    }
>>>>>
>>>>>    // and concrete ones:
>>>>>
>>>>>    namespace Zend\Controller\Request;
>>>>>
>>>>>    class Http
>>>>>    {
>>>>>    }
>>>>>
>>>>> What's the problem here? The interface is not in the same  
>>>>> namespace
>>>>> as
>>>>
>>>> the
>>>>
>>>>> concrete implementations.
>>>>>
>>>>> Potential solutions and recommendation
>>>>> ======================================
>>>>> So, how should Zend Framework "solve" these issues? A number of
>>>
>>> proposals
>>>
>>>>> and
>>>>> recommendations have been floated around, both within ZF circles  
>>>>> and
>>>>> in the
>>>>> greater PHP community.
>>>>>
>>>>> Considerations include:
>>>>>
>>>>> * Avoiding the use of PHP reserved keywords (already noted).
>>>>> * Avoiding Hungarian Notation (i.e., having the name or a  
>>>>> portion of
>>>
>>> the
>>>
>>>>> name
>>>>>   describe its type -- which, to a degree, the current naming
>>>>
>>>> conventions
>>>>
>>>>>   already violate). (See
>>>>
>>>> http://en.wikipedia.org/wiki/Hungarian_Notation,
>>>>
>>>>> the
>>>>>   sections "Disadvantages of Systems Hungarian" and "Notable
>>>>> Opinions" for some
>>>>>   of the arguments against using Hungarian Notation.)
>>>>>
>>>>> Approaches that have been considered include:
>>>>>
>>>>> * Using 'I' to prefix interfaces. This derives from standards in
>>>>> other programming languages (.Net and python, in particular).  
>>>>> This is
>>>>> just another
>>>>>   form of Hungarian Notation, however.
>>>>>
>>>>> * Using "Interface" or "Abstract" as a class name suffix:
>>>>> RequestInterface,
>>>>>   RequestAbstract. Again, however this is Hungarian Notation.
>>>>>
>>>>> * Using the term "Base" for abstract classes: BaseRequest,
>>>
>>> RequestBase,
>>>
>>>>> Base.
>>>>>   This is just substituting the word Base for Abstract, however,  
>>>>> and
>>>
>>> is
>>>
>>>>> really
>>>>>   not much different than the above.
>>>>>
>>>>> * Use generic, descriptive names indicative of functionality or
>>>>
>>>> behavior.
>>>>
>>>>> As
>>>>>   examples from the SPL, "Countable", "Iterator", "ArrayObject".
>>>>>
>>>>> My recommendation is to use the latter, as it solves all
>>>
>>> considerations.
>>>
>>>>> It will
>>>>> take more thought when naming, but will ensure that components can
>>>>> live
>>>>
>>>> in
>>>>
>>>>> a
>>>>> self-contained namespace, do not use reserved keywords, and avoid
>>>>> Hungarian
>>>>> Notation.
>>>>>
>>>>> Plan for implementation
>>>>> =======================
>>>>> I recommend that the Coding Standards documentation be updated to
>>>
>>> reflect
>>>
>>>>> this
>>>>> approach.
>>>>>
>>>>> All new components going into 1.8 and onwards should adopt these
>>>>> standards. In
>>>>> releases 1.9 and forward, we will begin migrating existing
>>>>> interfaces/abstract
>>>>> classe. First, new classes/interfaces will be created that follow
>>>>> these conventions and which extend the originals; later, any
>>>>> type-hinting
>>>
>>> based
>>>
>>>>> on the
>>>>> original class/interface names will be updated to point to the new
>>>
>>> names;
>>>
>>>>> and
>>>>> finally, in 2.0, we will remove the old interfaces/abstract  
>>>>> classes
>>>>> entirely.
>>>>>
>>>>> --
>>>>> Matthew Weier O'Phinney
>>>>> Software Architect      | [email-masked]
>>>>> Zend Framework          | http://framework.zend.com/
>>>>
>>>> ----- End forwarded message -----
>>>>
>>>> --
>>>> Matthew Weier O'Phinney
>>>> Software Architect      | [email-masked]
>>>> Zend Framework          | http://framework.zend.com/
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> Software Architect      | [email-masked]
>>> Zend Framework          | http://framework.zend.com/
>
> -- 
> Benjamin Eberlei
> http://www.beberlei.de

--Boundary_(ID_UWFLBsceq5dFqYR5ru1coQ)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I too like Matt's idea of =
having standard names for abstract and interface.<div><br><div>  <div> =
<table cellpadding=3D"2" cellspacing=3D"0" border=3D"0" =
style=3D"font-size: 13px;"> 	<tbody> 		<tr> 			=
<td rowspan=3D"3" valign=3D"top"><a =
href=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><img =
src=3D"http://www.whitcraftconsulting.com/images/php5_zce_logo_new.gif" =
width=3D"73" height=3D"68"></a></td> 			<td =
style=3D"font-size: 16px; font-weight: bold;">Jon Whitcraft</td> 		=
</tr> 		<tr> 			<td>Zend Certified Engineer</td> =
		</tr> 		<tr> 			<td =
valign=3D"top"><a =
href=3D"mailto:[email-masked]">[email-masked]</a></td> 		=
</tr> 	</tbody> </table> </div> </div><br><div><div>On Apr 11, 2009, at =
12:07 PM, Benjamin Eberlei wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>i =
fully agree with matt on this issue :-)<br><br>it should be obvious for =
a user by looking at the classes, free-style naming <br>isn't really =
obvious<br><br>regards,<br>Benjamin<br><br>On Saturday 11 April 2009 =
17:57:16 Matthew Ratzloff wrote:<br><blockquote type=3D"cite">"There =
have been a TON of debates amongst ZF contributors about =
naming,<br></blockquote><blockquote type=3D"cite">and making the names =
meaningful. I would expect that this proposal =
would<br></blockquote><blockquote type=3D"cite">probably be very welcome =
to those individuals. (Matt R., I'm looking =
at<br></blockquote><blockquote =
type=3D"cite">you...)"<br></blockquote><blockquote =
type=3D"cite">Meaningful names are great! &nbsp;It just depends on what =
you mean by<br></blockquote><blockquote type=3D"cite">"meaningful". =
&nbsp;For me, it mean clearly communicating the role of a =
class,<br></blockquote><blockquote type=3D"cite">so that users can =
instantly determine how classes are interrelated, even =
if<br></blockquote><blockquote type=3D"cite">they're navigating the code =
online. &nbsp;Right now we have that: it is =
clear<br></blockquote><blockquote type=3D"cite">that =
Zend_Controller_Request_Http extends =
Zend_Controller_Request_Abstract,<br></blockquote><blockquote =
type=3D"cite">even before you open either, and even if you aren't using =
an IDE.<br></blockquote><blockquote type=3D"cite"> =
Zend_Controller_Request_Http extending Zend_Controller_Request would =
also<br></blockquote><blockquote type=3D"cite">communicate that. &nbsp;I =
would like to retain that quality of the =
file<br></blockquote><blockquote =
type=3D"cite">organization.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">With the =
following names...<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"> * =
Zend\Controller\Request\RequestEnvironment, =
RequestObject<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;(interface, abstract)<br></blockquote><blockquote =
type=3D"cite"> * Zend\Controller\Response\ResponsePayload, =
ResponseObject<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;(interface, abstract)<br></blockquote><blockquote =
type=3D"cite"> * Zend\Controller\Dispatcher\DispatchMapper =
(interface)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">...excepting =
this one...<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"> * =
Zend\Validate\Validatible, Validator (interface, =
abstract)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">...it is not =
really apparent what relates to what. &nbsp;RequestEnvironment =
does<br></blockquote><blockquote type=3D"cite">not communicate Interface =
to me, and RequestObject does not =
communicate<br></blockquote><blockquote type=3D"cite">abstract. =
&nbsp;While you may say that that's irrelevant because we have IDEs, =
I<br></blockquote><blockquote type=3D"cite">would say that these names =
have the potential to be more confusing, =
because<br></blockquote><blockquote type=3D"cite">there are no rules for =
how environments and objects and payloads =
and<br></blockquote><blockquote type=3D"cite">mappers are related. =
&nbsp;If I'm looking to extend one of these classes =
(which<br></blockquote><blockquote type=3D"cite">happens frequently), I =
have to study a few classes to figure out =
how<br></blockquote><blockquote type=3D"cite">everything interacts. =
&nbsp;Today I can open the abstract or interface and =
get<br></blockquote><blockquote type=3D"cite">right to =
work.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">One other =
thing. &nbsp;There are going to be cases where these names are =
going<br></blockquote><blockquote type=3D"cite">to be really awkward. =
&nbsp;One of the great things about frameworks in =
general<br></blockquote><blockquote type=3D"cite">is that they remove =
choices so that you can focus on getting the job =
done.<br></blockquote><blockquote type=3D"cite">IRequest, =
IResponse--there is no thought required for these names. &nbsp;But =
in<br></blockquote><blockquote type=3D"cite">the other scenario =
contributors must determine whether =
RequestEnvironment,<br></blockquote><blockquote =
type=3D"cite">RequestObject, Requestable, or whatever most effectively =
communicates its<br></blockquote><blockquote =
type=3D"cite">role.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">If we go this =
route, I also think we're going to end up standardizing =
on<br></blockquote><blockquote type=3D"cite">some things simply in an =
effort to avoid the above. &nbsp;I think Object =
will<br></blockquote><blockquote type=3D"cite">become a stand-in for =
Abstract, for example (RequestObject). &nbsp;I =
think<br></blockquote><blockquote type=3D"cite">standardization of this =
kind results in a clear API, but in effect, it is =
a<br></blockquote><blockquote type=3D"cite">form of limited Hungarian =
notation through the back door. &nbsp;If we =
are<br></blockquote><blockquote type=3D"cite">ultimately going to go =
that route, we should just do it up front. <br></blockquote><blockquote =
type=3D"cite">Honestly, I would even be OK with AbstractRequest and =
RequestInterface,<br></blockquote><blockquote type=3D"cite">although I =
know you would hate that idea. &nbsp;:-)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">-Matt<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">On Fri, Apr 10, =
2009 at 4:13 PM, Matthew Weier O'Phinney<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>>wrote:<br></blockquo=
te><blockquote type=3D"cite"><blockquote type=3D"cite">-- Matthew Weier =
O'Phinney &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>> =
wrote<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">(on Friday, 10 April 2009, 04:39 =
PM -0400):<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Forwarding from Ben, who intended to copy the =
list...<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">----- =
Forwarded message from Benjamin Eberlei &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>><br></blockquo=
te></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">-----<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">From: =
Benjamin Eberlei &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>><br></blockquo=
te></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">To: Matthew Weier O'Phinney =
&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>><br></blockquote></b=
lockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Date: Fri, 10 Apr 2009 18:58:02 =
+0000<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Subject:=
 Re: [zf-contributors] Proposal to update =
Abstract/Interface<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Naming<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Conventions<br></blockquote></blockquote></b=
lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">moving =
to this new namespace implementation and breaking all old =
ones<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">is<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">a<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">serious =
BC,<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">so why =
do we only allow slight changes for everything else? I =
thought<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">we =
would just go to "change the serious technical debt, but as BC =
as<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">possible", changing the name of an interface is the exact =
difference of<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">that.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">It is, but we're going to need =
to do it once we move to =
namespaces<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">anyways -- because our CS were =
written before namespaces were =
even<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">proposed for inclusion in =
PHP.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">This is also why I propose the =
gradual changes over a series =
of<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">versions. This allows us to provide migration instructions =
that users<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">can gradually implement, making =
their code more future-proof. If =
the<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">new versions of the interfaces and abstract classes extend =
the<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">originals, there is no BC break until we finally drop the =
old classes --<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">which, as I mentioned, will not =
happen until 2.0.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">additionally, the generic name one seems strange in my =
eyes. How would<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">you<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">do =
that for<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
example of request, response, dispatcher? Validation =
interface?<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">First off, the request and =
response objects need interfaces, and =
then<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">potentially abstract implementations. Either way, this is =
easy:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * =
Zend\Controller\Request\RequestEnvironment, =
RequestObject<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;(interface, =
abstract)<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * =
Zend\Controller\Response\ResponsePayload, =
ResponseObject<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;(interface, =
abstract)<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * =
Zend\Controller\Dispatcher\DispatchMapper =
(interface)<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * Zend\Validate\Validatible, =
Validator (interface, abstract)<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">The names take a little =
creativity, but they also make it clearer =
in<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">your code what you're =
doing:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;namespace =
Zend\Controller\Request;<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;class =
HttpEnvironment implements =
RequestEnvironment<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;{<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;}<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;// =
or<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"> &nbsp;&nbsp;namespace =
Zend\Validate;<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;class Alpha extends =
Validator<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;{<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;}<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">i =
don't seem to find good ones. ResponseObject, =
RequestObject,<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Validatable are ok, but from the typehints its very hard =
to suggest<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">that =
these are interfaces in contrast to concrete =
implementation.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Typehints should typically be to =
interfaces anyways...<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">furthermore, why break with the ways of java, python, and =
.net? this is<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">what =
many programmers are used =
to.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Because Java and .Net are =
strongly typed languages, and PHP =
isn't.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Because just because a convention worked for one language =
doesn't mean<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">it's appropriate for another. =
Because PHP is not Java, is not Python, =
is<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">not .NET.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">There have been a TON of debates =
amongst ZF contributors about =
naming,<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite">and making the names meaningful. I would expect that this =
proposal would<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">probably be very welcome to =
those individuals. (Matt R., I'm looking =
at<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">you...)<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">As a =
last point, having implementation and interface in =
different<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">packages=
 is actually the single most important issue about having =
an<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">interface anyways and a huge benefit for object oriented =
design. &nbsp;this<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">separates the concerns and reduces dependencies, so I =
would love to<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">see =
this in a 2.0 =
version.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">There's a difference between =
using an interface in userland code, =
and<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">using one within a framework or library. In your userland =
code, you<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">*will* have the interface in a =
different package:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;namespace =
Foo\Controller\Request;<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;import =
Zend\Controller\Request as =
ZfRequest;<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;CustomHttpRequest =
extends =
ZfRequest\HttpEnvironment<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;{<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;}<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">*Within* the framework, it's =
better for them to be in the =
same<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">namespace, to allow selectively packaging components for =
distribution or<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">deployment.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">That =
is what i am greatly missing in ZF, that for example =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">controller is implemented with several very large abstract =
classes<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">only =
and the dependencies are so hard-wired that its impossible =
to<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">exchange=
 just one part of the controller to add specific =
functionality<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">without =
having to change considerable other parts =
also.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">This has nothing to do with =
naming conventions, and is a topic =
we<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">already plan to address for (or before) 2.0. (Please =
search for<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">"Zend_Controller 2.0" on the =
wiki for some of the plans.)<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">On =
Fri, 10 Apr 2009 14:24:34 -0400, Matthew Weier =
O'Phinney<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>> =
wrote:<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Greetings, all =
--<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Below is a proposal I am making =
to modify the Zend Framework =
Coding<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Standards conventions for the =
naming of Interfaces and =
Abstract<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">classes.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">This decision is basically =
already made, but I'd appreciate =
any<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">feedback<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">that you may have on the =
matter.<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Thanks!<br></blockquote></blockquote></blockquote></blockquo=
te><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">The =
problem<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></blockquote></blockquo=
te></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">PHP =
5.3 introduces namespaces to the PHP language. While this =
won't<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">have<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">an<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">impact much on userland code, it =
will have an impact on library =
and<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">framework<br></blockquote></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">code, as it provides a useful =
paradigm for organizing components =
as<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">well<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">as<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">simplifying syntax. Instead of =
having to say things =
like:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;$analyzer =3D =
new<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();<br></=
blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">we can instead do something like =
this:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;namespace =
Zend\Search\Lucene\Analysis\Analyzer;<br></blockquote></blockquote></block=
quote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;$analyzer =3D =
new =
Common_TextNum();<br></blockquote></blockquote></blockquote></blockquote><=
blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">or =
even:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;namespace =
Zend\Search\Lucene\Analysis\Analyzer;<br></blockquote></blockquote></block=
quote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;class =
Common_TextNum extends =
Common<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;{<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;}<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">The problem that arises for Zend =
Framework has to do with how we =
name<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">abstract<br></blockquote></blockquote></blockquote></blockqu=
ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">classes and interfaces. =
Currently, the final segment of such =
classes<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">are<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">expected to end with _Abstract =
and _Interface, respectively. =
This<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">will<br></blockquote></blockquote></blockquote></blockquote>=
<blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">not<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">work<br></blockquote></blockquote></blockquote></blockquote>=
<blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">when we migrate to utilize =
namespaces, for two =
reasons.<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">First, and most obviously, =
'abstract' and 'interface' are =
reserved<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">PHP =
keywords.<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">As such, in situations such as =
the =
following:<br></blockquote></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;namespace =
Zend\Controller\Request;<br></blockquote></blockquote></blockquote></block=
quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;class =
Abstract<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;{<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;}<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;// =
or:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;namespace =
Zend\Controller\Dispatcher;<br></blockquote></blockquote></blockquote></bl=
ockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;interface =
Interface<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;{<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;}<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">we'll run into =
issues.<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Second, and less obvious, is =
that perhaps the easiest solution =
breaks<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">one<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">of =
the<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">key principles of namespaces =
(which are designed to help =
encapsulate<br></blockquote></blockquote></blockquote></blockquote><blockq=
uote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">components). This one's harder =
to explain, so let's look at =
examples.<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Consider =
a<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">component such as =
Zend_Controller_Request. The simplest =
solution<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">would<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">be<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">to<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">name the abstract class or =
interface Zend\Controller\Request, =
and<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">then have =
the<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">various concrete implementations =
under that =
namespace:<br></blockquote></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;namespace =
Zend\Controller;<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;interface =
Request<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;{<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;}<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;// and =
concrete =
ones:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;namespace =
Zend\Controller\Request;<br></blockquote></blockquote></blockquote></block=
quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;&nbsp;class =
Http<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;{<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;&nbsp;}<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">What's the problem here? The =
interface is not in the same =
namespace<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">as<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">concrete =
implementations.<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Potential solutions and =
recommendation<br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></blockquote></b=
lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">So, =
how should Zend Framework "solve" these issues? A number =
of<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">proposals<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">and<br></blockquote></blockquote></blockquote></blockquote><=
blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">recommendations have been =
floated around, both within ZF circles =
and<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">in =
the<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">greater PHP =
community.<br></blockquote></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Considerations =
include:<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * Avoiding the use of PHP =
reserved keywords (already =
noted).<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * Avoiding Hungarian Notation =
(i.e., having the name or a portion =
of<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">the<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">name<br></blockquote></blockquote></blockquote></blockquote>=
<blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;describe its type =
-- which, to a degree, the current =
naming<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">conventions<br></blockquote></blockquote></blockquote><block=
quote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;already violate). =
(See<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"http://en.wikipedia.org/wiki/Hungarian_Notation">http://en.wikiped=
ia.org/wiki/Hungarian_Notation</a>,<br></blockquote></blockquote></blockqu=
ote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">the<br></blockquote></blockquote></blockquote></blockquote><=
blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;sections =
"Disadvantages of Systems Hungarian" and =
"Notable<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Opinions" for =
some<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;of the arguments =
against using Hungarian =
Notation.)<br></blockquote></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Approaches that have been =
considered =
include:<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * Using 'I' to prefix =
interfaces. This derives from standards =
in<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">other programming languages =
(.Net and python, in particular). This =
is<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">just =
another<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;form of Hungarian =
Notation, =
however.<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * Using "Interface" or =
"Abstract" as a class name =
suffix:<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">RequestInterface,<br></blockquote></blockquote></blockquote>=
</blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;&nbsp;RequestAbstract. Again, however this is Hungarian =
Notation.<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * Using the term "Base" for =
abstract classes: =
BaseRequest,<br></blockquote></blockquote></blockquote></blockquote><block=
quote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">RequestBase,<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Base.<br></blockquote></blockquote></blockquote></blockquote=
><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;This is just =
substituting the word Base for Abstract, however, =
and<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">is<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">really<br></blockquote></blockquote></blockquote></blockquot=
e><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;not much different =
than the =
above.<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> * Use generic, descriptive =
names indicative of functionality =
or<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">behavior.<br></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">As<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"> &nbsp;&nbsp;examples from the =
SPL, "Countable", "Iterator", =
"ArrayObject".<br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">My recommendation is to use the =
latter, as it solves =
all<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">considerations.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">It =
will<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">take more thought when naming, =
but will ensure that components =
can<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">live<br></blockquote></blockquote></blockquote></blockquote>=
<blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">in<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">a<br></blockquote></blockquote></blockquote></blockquote><bl=
ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">self-contained namespace, do not =
use reserved keywords, and =
avoid<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Hungarian<br></blockquote></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Notation.<br></blockquote></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Plan for =
implementation<br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">I recommend that the Coding =
Standards documentation be updated =
to<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">reflect<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">this<br></blockquote></blockquote></blockquote></blockquote>=
<blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">approach.<br></blockquote></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">All new components going into =
1.8 and onwards should adopt =
these<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">standards. =
In<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">releases 1.9 and forward, we =
will begin migrating =
existing<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">interfaces/abstract<br></blockquote></blockquote></blockquot=
e></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">classe. =
First, new classes/interfaces will be created that =
follow<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">these conventions and which =
extend the originals; later, =
any<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">type-hinting<br></blockquote></blockquote></blockquote></blo=
ckquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">based<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">on =
the<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">original class/interface names =
will be updated to point to the =
new<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">names;<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">and<br></blockquote></blockquote></blockquote></blockquote><=
blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">finally, in 2.0, we will remove =
the old interfaces/abstract =
classes<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">entirely.<br></blockquote></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">--<br></blockquote></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Matthew Weier =
O'Phinney<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Software Architect =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquote></bl=
ockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Zend =
Framework &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"http://framework.zend.com/">http://framework.zend.com/</a><br></bl=
ockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">----- =
End forwarded message =
-----<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">--<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Matthew =
Weier O'Phinney<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Software=
 Architect &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquote></bl=
ockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">Zend Framework =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"http://framework.zend.com/">http://framework.zend.com/</a><br></bl=
ockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">--<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Matthew Weier =
O'Phinney<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Software Architect =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquote></bl=
ockquote><blockquote type=3D"cite"><blockquote type=3D"cite">Zend =
Framework &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"http://framework.zend.com/">http://framework.zend.com/</a><br></bl=
ockquote></blockquote><br>-- <br>Benjamin Eberlei<br><a =
href=3D"http://www.beberlei.de">http://www.beberlei.de</a><br></div></bloc=
kquote></div><br></div></body></html>=

--Boundary_(ID_UWFLBsceq5dFqYR5ru1coQ)--

nFrom nobody Wed Apr  7 08:46:13 2010
Date: Sun, 26 Jul 2009 11:13:52 -0700 (PDT)
From: =?utf-8?B?UMOhZHJhaWMgQnJhZHk=?= <[email-masked]>
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
	ZendX Proposal
To: Matthew Weier O'Phinney <[email-masked]>, [email-masked]
Cc: Zend Framework Contributors <[email-masked]>

--0-1785226245-1248632032=:90029
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

>Paddy, to be honest, this feels like a really daft criticism. Dmitry did=
=0A>do the original Zend_OpenId component, but we have blocked on YOU to do=
=0A>the 2.0 support. When Dmitry started the OpenId component, I had Andi=
=0A>put him in touch with you so that the two of you could collaborate. At=
=0A>that time, you indicated that you would assist as you could, but that=
=0A>you would spend your efforts on OAuth and Yadis support, and then help=
=0A>with shaping our 2.0 support. These components have remained in=0A>basi=
cally proposal stage since spring 2008.=0A>=0A>So, bad example; if you want=
 to see further support for the 2.0 Draft 11=0A>specs, then please help us =
by completing what you started -- or indicate=0A>you won't do it, so that s=
omebody else can potentially step in and=0A>complete this effort.=0A=0AMath=
ew, to clarify, I have zero involvement in Zend_OpenId and I've never commi=
tted to any such involvement. I've never committed so much as a line of cod=
e for it. My work on Zend_Service_Yadis and Zend_Crypt were a byproduct of =
my own intentions in February 2007 to bring an OpenId proposal to the table=
. Once that was overtaken in June 2007 by Dmitry's proposal (it's no secret=
 how I reacted to that), we had some informal discussions on collaborating =
but it remained an insurmountable problem that my own library was already i=
n place after months of work - I simply did not have the time or the motiva=
tion to work on what amounted to a second OpenId library from scratch when =
I already had a perfectly operational one underway that I had already inten=
ded making a ZF contribution. As I said at the time (and wrote about on the=
 blog in September 07), the then ZF proposal process was a thoroughly disco=
uraging one that made no effort to engage with proposers in a
 constructive manner.=0A=0AThough I certainly would have expressed a willin=
gness to assist with OpenID (by email if I remember?) it would not have bee=
n an immediate project and I would not have committed to it on the spot wit=
hout submitting a formal proposal for discussion. This is neither the time =
or place to discuss what my involvement or the direction of Zend_OpenId cou=
ld be, but the component needs more than a few patches and it's more a task=
 for ZF 2.0 I think.=0A=0AAs for Zend_Crypt and Zend_Service_Yadis, these d=
ate back to 2007. I don't know how long they have been in the Incubator - b=
ut aside from a few minor issues in Yadis they've been sitting there waitin=
g for whatever the next step is. I don't have any immediate need for them -=
 they were intended for use in Zend_OpenId whenever Dmitry needed them. Yad=
is has been up on PEAR as a release for almost as long. OAuth dates from mi=
d-2008 - completely my fault it's not quite finished but I have told a few =
people since last December that they should not hesitate to work on it in m=
y absence. I just couldn't get to it at the time. In any case, it's on my c=
ard right after ZFR finishes up with the final testing.=0A=0AAnyway, this i=
s way way off topic.=0A=0AMy point in using that example is that it's anoth=
er component that is not actively maintained. I am definitely not its maint=
ainer - and I don't even use it. Just backing up Benjamin's observation. I =
know it's an unrealistic pain in the butt that Zend are expected to maintai=
n these, but at some point either maintenance needs to be enforced (demotio=
n was a bad word, but moving to ZendX risks other problems with confusing c=
ompatibility breaks) or illustrated in some way to ways that it's lacking o=
r increases a components risk of not working as expected. The sad fact is t=
hat few people will bother to create issues for these - and not everyone ev=
en has a CLA in place to create an issue.=0A=0APaddy=0A=0A=0A P=C3=A1draic =
Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=
=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=0A=0A=0A_________=
_______________________=0AFrom: Matthew Weier O'Phinney <[email-masked]>=
=0ATo: [email-masked]=0ASent: Sunday, July 26, 2009 4:29:41=
 PM=0ASubject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Serv=
ices to ZendX Proposal=0A=0A-- P=C3=A1draic Brady <[email-masked]>=
 wrote=0A(on Sunday, 26 July 2009, 06:48 AM -0700):=0A> The problem isn't j=
ust restricted to those mentioned either. Other components=0A> have been de=
veloped, tested, released - and then maintenance simple ceases or=0A> conti=
nues in a minimalistic way - the issue tracker turnover rate is horrendous=
=0A> at times. One of the less obvious problems is that the lack of active=
=0A> development (i.e. accounting for API/protocol changes and featuresets)=
 makes=0A> these difficult to rely on in practice since you can make a goog=
le search and=0A> find something more up to the minute boasting new feature=
s, extensions or=0A> protocol support not offered by the Zend versions. Thi=
s also does not bode well=0A> for security/usability - it is not very cool =
to have users reporting problems=0A> in the issue tracker than any decently=
 designed test suite should pick up=0A> instantly.=0A=0AI completely unders=
tand what you're saying, but I also need to step in=0Aand say: if you are w=
riting a component, you should be maintaining it.=0AWe at Zend are a *VERY*=
 small team (currently myself and two engineers),=0Aand we simply do not ha=
ve the manpower or expertise to maintain all=0Acomponents -- and yet, for s=
ome reason, there is an expectation in the=0Acommunity that we do, and that=
 it *is* our job.=0A=0AWe need more community help in maintaining the frame=
work. I have some=0Aideas on how to achieve this, but I need *your* ideas a=
s well, as=0Acontributors.=0A=0A> Just to offer another example outside the=
 services API area, since I'm the=0A> Irish rep sitting on its Europe Found=
ation, Zend_Openid persists in a state of=0A> limbo offering OpenID 2.0 Dra=
ft 11 compliance. OpenID 2.0 Final was released=0A> back in December 2007..=
. It has continually presented problems maintaining=0A> compliance with Ope=
nID servers from the likes of Google and Yahoo - it still=0A> doesn't. It s=
till can't handle discovery. It also still can't operate with=0A> servers o=
ffering any popular extension outside of the Simple Registration=0A> module=
 (which is steadily in decline as Attribute Exchange is adopted). In=0A> sh=
ort, it's rarely, if ever, been all that reliable.=0A=0APaddy, to be honest=
, this feels like a really daft criticism. Dmitry did=0Ado the original Zen=
d_OpenId component, but we have blocked on YOU to do=0Athe 2.0 support. Whe=
n Dmitry started the OpenId component, I had Andi=0Aput him in touch with y=
ou so that the two of you could collaborate. At=0Athat time, you indicated =
that you would assist as you could, but that=0Ayou would spend your efforts=
 on OAuth and Yadis support, and then help=0Awith shaping our 2.0 support. =
These components have remained in=0Abasically proposal stage since spring 2=
008. =0A=0ASo, bad example; if you want to see further support for the 2.0 =
Draft 11=0Aspecs, then please help us by completing what you started -- or =
indicate=0Ayou won't do it, so that somebody else can potentially step in a=
nd=0Acomplete this effort.=0A=0A> What's really needed is some form of main=
tainance oversight - if we=0A> can get a handle on what these components do=
, what standard/spec they=0A> should adhere to, and whether they are doing =
that, we can pinpoint the=0A> failing components. A maintenance log (svn lo=
g works at a pinch) and=0A> JIRA can pinpoint slack maintainance or a lack =
of active development.=0A> From there it should be easy to assess what comp=
onents represent the=0A> greatest risk - then demote them as needed if work=
 is not forthcoming. =0A=0AI don't think demotion is an option. Even with t=
he bugs, developers come=0Ato rely on the components, and if they suddenly =
disappear in a given=0Arelease, this will cause some very real consternatio=
n -- much worse than=0Aif they remained as-is.=0A=0AWhat *is* needed is a w=
ay to hand off maintenance to new contributors=0Ainterested in the componen=
t.=0A=0A> Same could be said of the Incubator (where I can be pretty guilty=
 I=0A> know ;)). =0A=0ASee my notes above.=0A=0AThat said, I'm working on a=
 process for better managing the proposal=0Aprocess -- which should better =
be titled the "contribution process", as=0Ait should include not only the p=
roposal itself, but the process for=0Adevelopment, inclusion in the trunk, =
and long-term maintenance. I'd=0Awelcome your ideas -- and those of anybody=
 else on this list -- in how=0Ayou would envision this should work.=0A=0A> =
The other perceivable problem is testing quality - some issues on Jira=0A> =
show a terrible record for problems arising which should be easily=0A> dete=
cted. The lack of actual testing against services (while=0A> understandable=
 where support for developer testing accounts/IDs is not=0A> forthcoming) w=
ill always be problematic though.=0A=0AServices are always difficult. There=
 are some good approaches that can=0Abe used, but the difficulty will alway=
s be present as APIs evolve.=0A=0A=0A> =E2=94=81=E2=94=81=E2=94=81=E2=94=81=
=0A> From: Benjamin Eberlei <[email-masked]>=0A> To: zf-contributors@l=
ists.zend.com=0A> Sent: Sunday, July 26, 2009 10:35:36 AM=0A> Subject: [zf-=
contributors] Zend_Service_Amazon API Upgrade + Services to ZendX=0A> Propo=
sal=0A> =0A> Hello Everyone,=0A> =0A> i took the time today to look at the =
Problem of Zend_Service_Amazon. Due to an=0A> API upgrade the ZF component =
won't work anymore come August 15th. I just saw=0A> that the component uses=
 the API from 2005, so its hopelessly out of date. I'll=0A> look into a pos=
sible fix, but i can't guarantee for this to work with the 2005=0A> API and=
 i dont know how complex a migration to the latest 2009 API is.=0A> =0A> Th=
is out of date problem is the case with most of the other Service component=
s=0A> besides Twitter, S3 and EC2. Their code-base is mostly crap and they =
are all=0A> unmaintained.=0A> =0A> I want to propose a change to ZFs handli=
ng of Service components. Since they=0A> all rely on third party API (throu=
gh them having to rely on the stability of=0A> external webservices) they s=
hould all be moved into ZendX for 2.0. Also every=0A> new service component=
 from now on should only be included in ZendX, with the=0A> exception of se=
rvice integration being programmed from companies that have an=0A> agreemen=
t with Zend, such as the Infocard, Google and AMF components, where=0A> the=
 stability and up-to-date API can be somewhat guaranteed.=0A> =0A> greeting=
s,=0A> Benjamin=0A> =0A> --=0A> Benjamin Eberlei=0A> http://www.beberlei.de=
=0A=0A-- =0AMatthew Weier O'Phinney=0AProject Lead            | matthew@zen=
d.com=0AZend Framework          | http://framework.zend.com/=0A
--0-1785226245-1248632032=:90029
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">&gt;Paddy, to be honest, this feels like a really daft critici=
sm. Dmitry did<br>&gt;do the original Zend_OpenId component, but we have bl=
ocked on YOU to do<br>&gt;the 2.0 support. When Dmitry started the OpenId c=
omponent, I had Andi<br>&gt;put him in touch with you so that the two of yo=
u could collaborate. At<br>&gt;that time, you indicated that you would assi=
st as you could, but that<br>&gt;you would spend your efforts on OAuth and =
Yadis support, and then help<br>&gt;with shaping our 2.0 support. These com=
ponents have remained in<br>&gt;basically proposal stage since spring 2008.=
<br>&gt;<br>&gt;So, bad example; if you want to see further support for the=
 2.0 Draft 11<br>=0A&gt;specs, then please help us by completing what you s=
tarted -- or indicate<br>=0A&gt;you won't do it, so that somebody else can =
potentially step in and<br>=0A&gt;complete this effort.<br><br>Mathew, to c=
larify, I have zero involvement in Zend_OpenId and I've never committed to =
any such involvement. I've never committed so much as a line of code for it=
. My work on Zend_Service_Yadis and Zend_Crypt were a byproduct of my own i=
ntentions in February 2007 to bring an OpenId proposal to the table. Once t=
hat was overtaken in June 2007 by Dmitry's proposal (it's no secret how I r=
eacted to that), we had some informal discussions on collaborating but it r=
emained an insurmountable problem that my own library was already in place =
after months of work - I simply did not have the time or the motivation to =
work on what amounted to a second OpenId library from scratch when I alread=
y had a perfectly operational one underway that I had already intended maki=
ng a ZF contribution. As I said at the time (and wrote about on the blog in=
 September 07), the then ZF proposal process was a thoroughly discouraging =
one that made no effort
 to engage with proposers in a constructive manner.<br><br>Though I certain=
ly would have expressed a willingness to assist with OpenID (by email if I =
remember?) it would not have been an immediate project and I would not have=
 committed to it on the spot without submitting a formal proposal for discu=
ssion. This is neither the time or place to discuss what my involvement or =
the direction of Zend_OpenId could be, but the component needs more than a =
few patches and it's more a task for ZF 2.0 I think.<br><br>As for Zend_Cry=
pt and Zend_Service_Yadis, these date back to 2007. I don't know how long t=
hey have been in the Incubator - but aside from a few minor issues in Yadis=
 they've been sitting there waiting for whatever the next step is. I don't =
have any immediate need for them - they were intended for use in Zend_OpenI=
d whenever Dmitry needed them. Yadis has been up on PEAR as a release for a=
lmost as long. OAuth dates from mid-2008 - completely my fault it's
 not quite finished but I have told a few people since last December that t=
hey should not hesitate to work on it in my absence. I just couldn't get to=
 it at the time. In any case, it's on my card right after ZFR finishes up w=
ith the final testing.<br><br>Anyway, this is way way off topic.<br><br>My =
point in using that example is that it's another component that is not acti=
vely maintained. I am definitely not its maintainer - and I don't even use =
it. Just backing up Benjamin's observation. I know it's an unrealistic pain=
 in the butt that Zend are expected to maintain these, but at some point ei=
ther maintenance needs to be enforced (demotion was a bad word, but moving =
to ZendX risks other problems with confusing compatibility breaks) or illus=
trated in some way to ways that it's lacking or increases a components risk=
 of not working as expected. The sad fact is that few people will bother to=
 create issues for these - and not everyone even has a CLA in place
 to create an issue.<br><br>Paddy<br><br><div>&nbsp;</div><span style=3D"co=
lor: rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new york,=
times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=C3=A1draic Br=
ady<br><br></span></font><span style=3D"font-style: italic;"><font style=3D=
"font-family: times new roman,new york,times,serif;" size=3D"3"><a rel=3D"n=
ofollow" target=3D"_blank" href=3D"http://blog.astrumfutura.com">http://blo=
g.astrumfutura.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"htt=
p://www.survivethedeepend.com">http://www.survivethedeepend.com</a><br><a r=
el=3D"nofollow" target=3D"_blank" href=3D"http://www.openideurope.eu/">Open=
ID Europe Foundation Irish Representative</a><br></font></span></span><div>=
<br></div><div style=3D"font-family: times new roman,new york,times,serif; =
font-size: 12pt;"><br><div style=3D"font-family: arial,helvetica,sans-serif=
; font-size: 10pt;"><font size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><spa=
n style=3D"font-weight:
 bold;">From:</span></b> Matthew Weier O'Phinney &lt;[email-masked]&gt;<b=
r><b><span style=3D"font-weight: bold;">To:</span></b> zf-contributors@list=
s.zend.com<br><b><span style=3D"font-weight: bold;">Sent:</span></b> Sunday=
, July 26, 2009 4:29:41 PM<br><b><span style=3D"font-weight: bold;">Subject=
:</span></b> Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Servic=
es to ZendX Proposal<br></font><br>=0A-- P=C3=A1draic Brady &lt;<a ymailto=
=3D"mailto:[email-masked]" href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt; wrote<br>(on Sunday, 26 July 2009, 06:48 A=
M -0700):<br>&gt; The problem isn't just restricted to those mentioned eith=
er. Other components<br>&gt; have been developed, tested, released - and th=
en maintenance simple ceases or<br>&gt; continues in a minimalistic way - t=
he issue tracker turnover rate is horrendous<br>&gt; at times. One of the l=
ess obvious problems is that the lack of active<br>&gt; development (i.e. a=
ccounting for API/protocol changes and featuresets) makes<br>&gt; these dif=
ficult to rely on in practice since you can make a google search and<br>&gt=
; find something more up to the minute boasting new features, extensions or=
<br>&gt; protocol support not offered by the Zend versions. This also does =
not bode well<br>&gt; for security/usability - it is not very cool to have =
users reporting problems<br>&gt; in the
 issue tracker than any decently designed test suite should pick up<br>&gt;=
 instantly.<br><br>I completely understand what you're saying, but I also n=
eed to step in<br>and say: if you are writing a component, you should be ma=
intaining it.<br>We at Zend are a *VERY* small team (currently myself and t=
wo engineers),<br>and we simply do not have the manpower or expertise to ma=
intain all<br>components -- and yet, for some reason, there is an expectati=
on in the<br>community that we do, and that it *is* our job.<br><br>We need=
 more community help in maintaining the framework. I have some<br>ideas on =
how to achieve this, but I need *your* ideas as well, as<br>contributors.<b=
r><br>&gt; Just to offer another example outside the services API area, sin=
ce I'm the<br>&gt; Irish rep sitting on its Europe Foundation, Zend_Openid =
persists in a state of<br>&gt; limbo offering OpenID 2.0 Draft 11 complianc=
e. OpenID 2.0 Final was released<br>&gt; back in December 2007... It
 has continually presented problems maintaining<br>&gt; compliance with Ope=
nID servers from the likes of Google and Yahoo - it still<br>&gt; doesn't. =
It still can't handle discovery. It also still can't operate with<br>&gt; s=
ervers offering any popular extension outside of the Simple Registration<br=
>&gt; module (which is steadily in decline as Attribute Exchange is adopted=
). In<br>&gt; short, it's rarely, if ever, been all that reliable.<br><br>P=
addy, to be honest, this feels like a really daft criticism. Dmitry did<br>=
do the original Zend_OpenId component, but we have blocked on YOU to do<br>=
the 2.0 support. When Dmitry started the OpenId component, I had Andi<br>pu=
t him in touch with you so that the two of you could collaborate. At<br>tha=
t time, you indicated that you would assist as you could, but that<br>you w=
ould spend your efforts on OAuth and Yadis support, and then help<br>with s=
haping our 2.0 support. These components have remained
 in<br>basically proposal stage since spring 2008. <br><br>So, bad example;=
 if you want to see further support for the 2.0 Draft 11<br>specs, then ple=
ase help us by completing what you started -- or indicate<br>you won't do i=
t, so that somebody else can potentially step in and<br>complete this effor=
t.<br><br>&gt; What's really needed is some form of maintainance oversight =
- if we<br>&gt; can get a handle on what these components do, what standard=
/spec they<br>&gt; should adhere to, and whether they are doing that, we ca=
n pinpoint the<br>&gt; failing components. A maintenance log (svn log works=
 at a pinch) and<br>&gt; JIRA can pinpoint slack maintainance or a lack of =
active development.<br>&gt; From there it should be easy to assess what com=
ponents represent the<br>&gt; greatest risk - then demote them as needed if=
 work is not forthcoming. <br><br>I don't think demotion is an option. Even=
 with the bugs, developers come<br>to rely on the components, and if
 they suddenly disappear in a given<br>release, this will cause some very r=
eal consternation -- much worse than<br>if they remained as-is.<br><br>What=
 *is* needed is a way to hand off maintenance to new contributors<br>intere=
sted in the component.<br><br>&gt; Same could be said of the Incubator (whe=
re I can be pretty guilty I<br>&gt; know ;)). <br><br>See my notes above.<b=
r><br>That said, I'm working on a process for better managing the proposal<=
br>process -- which should better be titled the "contribution process", as<=
br>it should include not only the proposal itself, but the process for<br>d=
evelopment, inclusion in the trunk, and long-term maintenance. I'd<br>welco=
me your ideas -- and those of anybody else on this list -- in how<br>you wo=
uld envision this should work.<br><br>&gt; The other perceivable problem is=
 testing quality - some issues on Jira<br>&gt; show a terrible record for p=
roblems arising which should be easily<br>&gt; detected. The lack of
 actual testing against services (while<br>&gt; understandable where suppor=
t for developer testing accounts/IDs is not<br>&gt; forthcoming) will alway=
s be problematic though.<br><br>Services are always difficult. There are so=
me good approaches that can<br>be used, but the difficulty will always be p=
resent as APIs evolve.<br><br><br>&gt; =E2=94=81=E2=94=81=E2=94=81=E2=94=81=
<br>&gt; From: Benjamin Eberlei &lt;<a ymailto=3D"mailto:[email-masked]=
e" href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; =
To: <a ymailto=3D"mailto:[email-masked]" href=3D"mailto:zf-=
[email-masked]">[email-masked]</a><br>&gt; Sen=
t: Sunday, July 26, 2009 10:35:36 AM<br>&gt; Subject: [zf-contributors] Zen=
d_Service_Amazon API
 Upgrade + Services to ZendX<br>&gt; Proposal<br>&gt; <br>&gt; Hello Everyo=
ne,<br>&gt; <br>&gt; i took the time today to look at the Problem of Zend_S=
ervice_Amazon. Due to an<br>&gt; API upgrade the ZF component won't work an=
ymore come August 15th. I just saw<br>&gt; that the component uses the API =
from 2005, so its hopelessly out of date. I'll<br>&gt; look into a possible=
 fix, but i can't guarantee for this to work with the 2005<br>&gt; API and =
i dont know how complex a migration to the latest 2009 API is.<br>&gt; <br>=
&gt; This out of date problem is the case with most of the other Service co=
mponents<br>&gt; besides Twitter, S3 and EC2. Their code-base is mostly cra=
p and they are all<br>&gt; unmaintained.<br>&gt; <br>&gt; I want to propose=
 a change to ZFs handling of Service components. Since they<br>&gt; all rel=
y on third party API (through them having to rely on the stability of<br>&g=
t; external webservices) they should all be moved into ZendX for
 2.0. Also every<br>&gt; new service component from now on should only be i=
ncluded in ZendX, with the<br>&gt; exception of service integration being p=
rogrammed from companies that have an<br>&gt; agreement with Zend, such as =
the Infocard, Google and AMF components, where<br>&gt; the stability and up=
-to-date API can be somewhat guaranteed.<br>&gt; <br>&gt; greetings,<br>&gt=
; Benjamin<br>&gt; <br>&gt; --<br>&gt; Benjamin Eberlei<br><span>&gt; <a ta=
rget=3D"_blank" href=3D"http://www.beberlei.de">http://www.beberlei.de</a><=
/span><br><br>-- <br>Matthew Weier O'Phinney<br>Project Lead&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; | <a ymailto=3D"mailto:[email-masked]" href=3D=
"mailto:[email-masked]">[email-masked]</a><br><span>Zend Framework&nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; | <a target=3D"_blank" href=3D"http://framewo=
rk.zend.com/">http://framework.zend.com/</a></span><br></div></div></div></=
body></html>
--0-1785226245-1248632032=:90029--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 08:24:14 -0800
From: Anthony Shireman <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--001485f86274b9716a04806f3604
Content-Type: text/plain; charset=ISO-8859-1

Moving from SVN to Git seems like quite a major switch. But, with the step
from 1.X to 2.0 it seems like a good time to do it. I like the idea (as
David Caunt mentioned) of releasing a 1.X branch with Doctrine 1 to test the
waters and judging by the amount of work required decide to go with Doc2+ZF2
when the time comes. It's an exciting time to work with ZF and I'm looking
forward to a time when ZF2 uses Git and Doctrine 2.

On Thu, Feb 25, 2010 at 5:20 AM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> -- David Caunt <[email-masked]> wrote
> (on Thursday, 25 February 2010, 11:13 AM +0000):
> > Integration of Doctrine 1 with ZF 1.11 might be a good way to test the
> > water and then community feedback may inform ZF2's integration with
> > Doctrine 2.
> >
> > As keen as I am for ZF2, I think the amount of work to be done on the
> > core is substantial and probably leaves enough time for a 1.11
> > release.
>
> Well, that's what we're trying to gauge at this point. It seems like a
> substantial amount of work, but if the initial development I outlined
> goes quickly, we may find ourselves working on the various
> rewrites/refactors much sooner, which could lead to an earlier release.
> Then again, it may take much longer, meaning a delay. I don't want to
> make a call either way yet, and thus the uncertainty about a 1.11
> release.
>
> If we end up deciding to do a 1.11 branch, we'll very likely look at
> doing integration with Doctrine 1.2 for the very reasons you describe,
> but also to serve as an upgrade path for ZF users.
>
> > Are there any plans to maintain the 1.x series once 2.0 is released?
>
> This is another area we're trying to gauge -- whether to continue
> maintenance on the 1.X branch following a 2.0 release.
>
> My personal feeling is that if we do, any future releases would address
> only critical bugs or security issues, and no new features. As long as
> we develop new features on the 1.X series, we'll hamper adoption of 2.0.
> In this vein, we'd likely do like the PHP project did, and do a new
> minor release on the version 1 branch simultaneous to 2.0 that would be
> for tracking those issues.
>
> If we do, I'll likely look for a small team from the community to assist
> as release masters for that branch.
>
>
> > On 25 February 2010 10:46, Giorgio Sironi <
> [email-masked]>
> > wrote:
> >
> >     On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley <
> [email-masked]>
> >     wrote:
> >
> >         In my opinion if Doctrine integration is to be left until ZF 2.0,
> then
> >         the integrated version of Doctrine should be the 2.0 version.
> Since
> >         both 2.0 versions will require PHP 5.3.
> >
> >
> >     I agree. Doctrine 2 will fill the lack of model infrastructure in
> Zend
> >     Framework.
> >     Anyway, the set of changes listed by Matthew is already a big step
> towards
> >     simpler development (exploiting phpunit new features for example.)
> >
> >     Regards,
> >     --
> >     Giorgio Sironi
> >     Piccolo Principe & Web Engineer
> >     http://giorgiosironi.blogspot.com
> >     http://twitter.com/giorgiosironi
> >
> >
> >
> >
> > --
> > Save Water...Drink Ouzo !
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--001485f86274b9716a04806f3604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Moving from SVN to Git seems like quite a major switch. But, with the step =
from 1.X to 2.0 it seems like a good time to do it. I like the idea (as Dav=
id Caunt mentioned) of releasing a 1.X branch with Doctrine 1 to test the w=
aters and judging by the amount of work required decide to go with Doc2+ZF2=
 when the time comes. It&#39;s an exciting time to work with ZF and I&#39;m=
 looking forward to a time when ZF2 uses Git and Doctrine 2. <br>
<br><br><div class=3D"gmail_quote">On Thu, Feb 25, 2010 at 5:20 AM, Matthew=
 Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
om">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p=
t 0.8ex; padding-left: 1ex;">
-- David Caunt &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>=
&gt; wrote<br>
(on Thursday, 25 February 2010, 11:13 AM +0000):<br>
<div class=3D"im">&gt; Integration of Doctrine 1 with ZF 1.11 might be a go=
od way to test the<br>
&gt; water and then community feedback may inform ZF2&#39;s integration wit=
h<br>
&gt; Doctrine 2.<br>
&gt;<br>
&gt; As keen as I am for ZF2, I think the amount of work to be done on the<=
br>
&gt; core is substantial and probably leaves enough time for a 1.11<br>
&gt; release.<br>
<br>
</div>Well, that&#39;s what we&#39;re trying to gauge at this point. It see=
ms like a<br>
substantial amount of work, but if the initial development I outlined<br>
goes quickly, we may find ourselves working on the various<br>
rewrites/refactors much sooner, which could lead to an earlier release.<br>
Then again, it may take much longer, meaning a delay. I don&#39;t want to<b=
r>
make a call either way yet, and thus the uncertainty about a 1.11<br>
release.<br>
<br>
If we end up deciding to do a 1.11 branch, we&#39;ll very likely look at<br=
doing integration with Doctrine 1.2 for the very reasons you describe,<br>
but also to serve as an upgrade path for ZF users.<br>
<div class=3D"im"><br>
&gt; Are there any plans to maintain the 1.x series once 2.0 is released?<b=
r>
<br>
</div>This is another area we&#39;re trying to gauge -- whether to continue=
<br>
maintenance on the 1.X branch following a 2.0 release.<br>
<br>
My personal feeling is that if we do, any future releases would address<br>
only critical bugs or security issues, and no new features. As long as<br>
we develop new features on the 1.X series, we&#39;ll hamper adoption of 2.0=
.<br>
In this vein, we&#39;d likely do like the PHP project did, and do a new<br>
minor release on the version 1 branch simultaneous to 2.0 that would be<br>
for tracking those issues.<br>
<br>
If we do, I&#39;ll likely look for a small team from the community to assis=
t<br>
as release masters for that branch.<br>
<div class=3D"im"><br>
<br>
&gt; On 25 February 2010 10:46, Giorgio Sironi &lt;<a href=3D"mailto:piccol=
[email-masked]">[email-masked]</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt; =A0 =A0 On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt; =A0 =A0 wrote:<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 In my opinion if Doctrine integration is to be left un=
til ZF 2.0, then<br>
&gt; =A0 =A0 =A0 =A0 the integrated version of Doctrine should be the 2.0 v=
ersion. Since<br>
&gt; =A0 =A0 =A0 =A0 both 2.0 versions will require PHP 5.3.<br>
&gt;<br>
&gt;<br>
&gt; =A0 =A0 I agree. Doctrine 2 will fill the lack of model infrastructure=
 in Zend<br>
&gt; =A0 =A0 Framework.<br>
&gt; =A0 =A0 Anyway, the set of changes listed by Matthew is already a big =
step towards<br>
&gt; =A0 =A0 simpler development (exploiting phpunit new features for examp=
le.)<br>
&gt;<br>
&gt; =A0 =A0 Regards,<br>
&gt; =A0 =A0 --<br>
&gt; =A0 =A0 Giorgio Sironi<br>
&gt; =A0 =A0 Piccolo Principe &amp; Web Engineer<br>
&gt; =A0 =A0 <a href=3D"http://giorgiosironi.blogspot.com" target=3D"_blank=
">http://giorgiosironi.blogspot.com</a><br>
&gt; =A0 =A0 <a href=3D"http://twitter.com/giorgiosironi" target=3D"_blank"=
>http://twitter.com/giorgiosironi</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Save Water...Drink Ouzo !<br>
<br>
</div><div><div></div><div class=3D"h5">--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</div></div></blockquote></div><br>

--001485f86274b9716a04806f3604--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 13:06:32 -0700
From: Stanislav Malyshev <[email-masked]>
Organization: Zend Technologies
To: Ralph Schindler <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

Hi!

> How is a developer suppose to know what the QGBar alias is short for?
> Moreover, if we are to use alias in method signatures, what kind of
> naming convention should be in play?

I guess it has to be either descriptive or generic enough, depending on 
what developer actually has to know. E.g., if you are working with 
Zend_Service_Goohoo_AwesomeService, than Request is probably 
Zend_Service_Goohoo_AwesomeService_Request, and Response is the 
respective response (I'm using current 1.x class name notation for 
clarity here). Usually if you know what class you need, you'll find good 
name for it.

> Additionally, do we restrict it to importing full namespaces? Or would
> we allow importing of single classes? Do we allow importing an aliased
> class into a File and use that inside a method signature?
>
> Imagine this:
>
> <?php
> namespace Zend\Some\NS;
> use \ArrayObject as Container;
>
> class Foo
> {
> public function doSomething(Container $c);
> }

I would avoid this in framework code, though in user code it's maybe 
legitimate, and you can play with what Container actually is. Since in 
ZF code there's no way to play with it, I'd probably leave \ArrayObject 
alone. If you have some long and foreign object, like using 
Zend\Http\Client\Adapter\Socket in some other class, you could call it 
Socket or HttpSocket or even Connection. Since the name is local, you 
don't have to bother to find a name that is good for everywhere - it can 
be read in the context of the local code.

>> I have faith that Framework developers actually can remember inside
>> which class and namespace they are :)
>
> By "Framework developers" do you mean people writing ZF code? or people
> consuming ZF code? I actually dont care about the burdon put on people
> writing code for ZF, b/c you only need to write it once. It's the burden
> put on the consumers of the library that I feel is more important.

I mean the people that read/write ZF code. If you just consume the API 
and look in the manual, the manual probably would explain to you what 
you need to do and what to pass. We may have to find a way to document 
it properly - i.e. in the manual when we refer to some class will we 
always use full name or sometimes we can say "AwesomeService::execute() 
accepts Request object and returns Response object" and have link or 
floating text or something like that which would actually have full 
names of Request and Response? It's a good topic to explore.

> I am guessing that docblock class names should probably be using the
> same namespace and use rule resolution that classes use.

The problem is that right now the docblocks are opaque to the engine and 
namespace/use info is not kept anywhere in the docblock, so if some code 
parses it it might need some additional help there.
-- 
Stanislav Malyshev, Zend Software Architect
[email-masked]   http://www.zend.com/
(408)253-8829   MSN: [email-masked]

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
Date: Tue, 23 Mar 2010 15:51:49 +0000
Cc: Sascha-Oliver Prolic <[email-masked]>,
	[email-masked]
To: Matthew Ratzloff <[email-masked]>
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

On 23 Mar 2010, at 13:46, Matthew Ratzloff wrote:

> Oh, that's a good point.  I forgot about that new magic method.  +1
> 

me too :)  __invoke() is the obvious solution.

Regards,

Rob...

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Vincent de Lau" <[email-masked]>
To: <[email-masked]>
Date: Sun, 22 Nov 2009 17:32:49 +0100
Subject: RE: [zf-contributors] Zend Framework 2.0 Roadmap

Hi all,

Although I'm not very involved in actual ZF development, I'd like to let my
voice heard in the hope that it might inspire the people designing the new
components. I'm working as lead developer at an Internet publisher, where we
mainly develop comparison sites. I'll first describe how we are using Zend
Framework, then I'll point out some things that we ran into and finally I'll
have some general observations.

First some history: In the past, several developers before me developed
their own libraries and 'frameworks'. They where however flawed,
inconsistent and 'using classes' instead of doing object oriented
programming. A year and a half ago, I proposed to either rebuild the
existing framework from the ground up or start using a pre-existing
framework. The final choice was made to start using Zend Framework. The
reasons why we chose Zend is because it provided a good object oriented
base, while not tying us down. Using an open source solution over an
in-house solution also meant that documentation and support being available,
while ensuring that there will always be people working on improving the
framework.

Our first projects used ZF basically how it came out of the box. Off course
we had to write some glue (mainly bootstrap) to put everything together. In
the old framework, the 'controllers' where very fat, and our first ZF
application was to. Also, almost everything in the site (menu's, texts,
secondary content) was hard coded. Before starting out on our next big
project, I decided that it was necessary to make more stuff easily
configurable by non technical people and let the framework solve some of our
problems to make our site more consistent.

We have developed a system where:
- page meta information including routing and layout is stored in a database
- pages can contain multiple components which they can also inherit from the
layout
- site structure (page hierarchy) is stored in the database
- ACL information is stored in the database and linked to pages and page
components
- Non critical options are stored in the database (options not related with
database access, error handling, logging and caching)

Our bootstrap takes care of setting up a database connection, error
handling, logging (two stage, first to mail, later to database), profiling,
caching (APC), Zend_Session (DB storage), Zend_Mail (encoding, default
transport), Zend_View (XHTML, encoding), Zend_Layout and finally dispatching
the request. We also created a small ORM that is also initialized in the
bootstrap.

For our database driven stuff to work, we've created a plug-in that handles
route loading from the database (cached), loading the ACL (cached), applying
the ACL, injecting database parameters into the request, selecting the
appropriate layout, setting the meta information on the layout (title,
description, keywords) and dispatching additional components for inclusion
in the layout.

This last task is controversial, because it uses Zend_View_Helper_Action.
Components are considered to be individual actions on an action controller.
The request parameters usually come from the database although they can use
parameters from the original request. I've been looking for an alternative
in the past, but the answer 'use view helpers' wasn't enough to solve all my
issues.

With Zend 2.0, I want to refactor large parts of what we have done. For
instance, our site structure components where written before Zend_Navigation
was complete. Our bootstrap process should be moved to use Zend_Application
and we should cut down on the amount of singletons. These are pretty trivial
tasks I suppose.

An area I'm not sure of yet is the Model or Domain part of the application.
As said before, we used to have fat controllers that directly accessed the
database. Currently we are using a custom ORM like solution that suits our
needs; together with service type classes that either use the ORM or access
the data source directly (we are also using web services). The ORM can
handle both generic objects, provided a custom mapper class has been
written, and ORM aware objects implementing an interface that allows the ORM
layer to discover changed data and primary keys. I've been looking at
Zend_Entity before building our custom solution, but the time didn't allow
to wait for it to become ready. We will be looking at Doctrine, but might
favour and improve our custom solution.

Another area of improvement I'm looking out for is a better way to control
and standardize form HTML. For straight forward forms, the standard way
forms are rendered is sufficient. However, designers and marketeers have the
habit of having non standard requests. For some of our current forms, this
required a lot a tweaking to get it right (before designers and marketeers
change their mind off course...). A lot of the code I see is removing,
reordering or otherwise trying to undo stuff that is added by (default)
decorators. I suppose this is in part because our team hasn't got enough
understanding how forms, form view helpers and decorators do their work.
Honestly, I think that custom view helpers instead of the decorators might
improve speed a lot. 

Finally I'd also like to improve our page composition process. I'm not sure
how Zend_Controller 2.0 will perform while executing multiple actions in a
single request. I hope that it will improve or that we can more easily reuse
the Dispatcher to perform a more lightweight secondary dispatch process. I
think the main argument for the 'use view helpers' solution is that
reentering the dispatch is expensive. My argument against using view helpers
was that I'd need to implement some sort of dispatch process to be able to
dynamically perform helpers and put the output at a designated point in the
layout. For our situation I've decided that the gained flexibility is worth
the performance hit. We also reduced a lot of this overhead by integrating
caching for components. To put this whole story in better perspective: a non
programmer can create a (simple) new page, add content, set meta information
and put it in the navigation in minutes, where in the past it would cost a
programmer half an hour to develop, integrate and test.

Let's move on to the more general observations, not only based on my
experience at work, but also with some personal projects I'm working on. 

First of all, one of the things I love about ZF is the loose coupling.
However, this loose coupling also has its downsides since it requires an
initial set of glue code to make it all work. Zend_Tool reduces some of
these requirements I suppose. I could imagine that it might be helpful to
develop a example base application that contains a lot of the glue for a new
developer to start with and customize as required. This might be in the
scope of Zend_Tool, but could also be part of a separate initiative (Zendi,
Zend Integrated) to complement Zend_Tool, quick start and tutorials.

Secondly... well actually I thought I had a list when starting this mail,
but I either forgot or already mentioned them above...

I hope that ZF 2.0 will mean a big improvement. I wouldn't mind if it broke
major things if it results in a better, cleaner, leaner and more consistent
framework. For me, ZF 2.0 will also be an opportunity to learn and improve.
I hope that my mail provides some real world examples of how ZF is being
used. I'll be available for questions and elaborations.

Well, let's close off by thanking all contributors for their efforts and all
readers for sticking with me. I'm a ZF fan and am sure ZF 2.0 will only
increase my dedication.

Kind regards,

Vincent de Lau
 [email-masked]

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 16 Oct 2009 16:18:51 -0700
From: "Wil Sinclair" <[email-masked]>
To: "Wil Sinclair" <[email-masked]>,
	<[email-masked]>
Subject: RE: [zf-contributors] Simple Cloud Storage API ready for review. . .

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA4EB7.06275454
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've also updated the proposal:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Cloud_Storage+-+Wil+S
inclair

=20

Version 0.2 isn't much different from 0.1; it has just been prettied up
for public consumption. I'd like to work through the really interesting
changes with the community once we have some code to hang our thoughts
on.

=20

,Wil

=20

From: Wil Sinclair [mailto:[email-masked]]=20
Sent: Friday, October 16, 2009 3:30 PM
To: [email-masked]
Subject: [zf-contributors] Simple Cloud Storage API ready for review. .
.

=20

You can check it out here:
http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/

=20

Keep in mind that it's still under heavy development, and many of the
tests have been marked incomplete or skipped. Also, the API targets
common functionality, so don't expect to find all the bells and whistles
of your favorite cloud service in there. What it does offer, however, is
an API that helps you keep your apps portable in the cloud with
configuration changes alone, calling out any design or development
decisions that break compatibility among cloud application services. As
with all ZF initiatives, we welcome community contributions. Big plus:
if you're implementing an adapter, the unit tests are already written
for you.

=20

Please let me know what you think. It's not ready for tracking issues
yet, so send them to the list or comment here:
http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/

=20

All pot shots at this old Java developer's code will be discussed in my
weekly therapy session with /dev/null. J

=20

Thanks all!

,Wil

------_=_NextPart_001_01CA4EB7.06275454
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I&#8217;ve also =
updated the proposal: <a
href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Cloud_Storage+=
-+Wil+Sinclair">http://framework.zend.com/wiki/display/ZFPROP/Zend_Cloud_=
Storage+-+Wil+Sinclair</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Version 0.2 =
isn&#8217;t much different
from 0.1; it has just been prettied up for public consumption. I&#8217;d =
like to work
through the really interesting changes with the community once we have =
some code
to hang our thoughts on.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>,Wil<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Wil =
Sinclair
[mailto:[email-masked]] <br>
<b>Sent:</b> Friday, October 16, 2009 3:30 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [zf-contributors] Simple Cloud Storage API ready for =
review. .
.<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>You can check it out here: <a
href=3D"http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/tru=
nk/">http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/=
</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Keep in mind that it&#8217;s still under heavy =
development, and
many of the tests have been marked incomplete or skipped. Also, the API =
targets
common functionality, so don&#8217;t expect to find all the bells and =
whistles of
your favorite cloud service in there. What it does offer, however, is an =
API
that helps you keep your apps portable in the cloud with configuration =
changes
alone, calling out any design or development decisions that break =
compatibility
among cloud application services. As with all ZF initiatives, we welcome
community contributions. Big plus: if you&#8217;re implementing an =
adapter, the unit
tests are already written for you.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Please let me know what you think. It&#8217;s not =
ready for
tracking issues yet, so send them to the list or comment here: <a
href=3D"http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/tru=
nk/">http://framework.zend.com/svn/framework/laboratory/Zend_Cloud/trunk/=
</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>All pot shots at this old Java developer&#8217;s =
code will be
discussed in my weekly therapy session with /dev/null. <span =
style=3D'font-family:
Wingdings'>J</span><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks all!<o:p></o:p></p>

<p class=3DMsoNormal>,Wil<o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01CA4EB7.06275454--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 17 Apr 2009 10:41:14 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code Freeze starts Monday

Greetings, all!

1.8 is shaping up nicely! We've had a lot of good feedback since the
preview release last week, and a number of other components have become
stable since then and have either been pushed to trunk or are ready to
review for inclusion in trunk.

We are considering doing a beta release mid-week next week. This will
ensure that the API stabilizes, and give developers and reviewers a real
feel for the final 1.8 product. 

As such, I'm announcing a code freeze, effective 14:00 UTC on Monday, 
20 April 2009. (This is when we have our daily internal meeting.)

If you have components that you have completed in incubator and want
reviewed for inclusion, please get them in before then. Please be aware
that if the component test coverage or documentation are deemed
incomplete or unsatisfactory at that time, they will *NOT* be included
in the final 1.8 release. 

If you are working on a new component in the trunk, please have the
public API for those components stable by that time.

Again, code freeze is at 14:00 UTC on Monday, 20 April 2009.

Thanks again, and keep up the great work!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Giuseppe Roberti <[email-masked]>
To: [email-masked]
Date: Mon, 17 Aug 2009 03:58:49 +0200
Subject: Re: [zf-contributors] Duplicated find() on
	Zend_Session_SaveHandler_DbTable

--=-F1LxuPSG0ree4q7XTXaY
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

There was an error, sorry.
Corrected patch attached.

On Mon, 2009-08-17 at 03:25 +0200, Giuseppe Roberti wrote:
> Hi list.
> 
> Walking thought the Zend Framework i have found that the
> Zend_Session_SaveHandler_DbTable do twice the find() over the associated
> DbTable; one in read() and another one in write().
> 
> Why ?
> Maybe there's some reason that i don't know.
> If not, here is a simple patch that erase this behavior.
> 
> Hope this is useful, thanks to all for the great job.
>

-- 
Giuseppe Roberti <[email-masked]>

--=-F1LxuPSG0ree4q7XTXaY
Content-Disposition: attachment;
	filename="zf-session-savehandler-dbtable-no-duplicate-find.patch"
Content-Type: text/x-patch;
	name="zf-session-savehandler-dbtable-no-duplicate-find.patch";
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

Index: DbTable.php
===================================================================
--- DbTable.php	(revision 17638)
+++ DbTable.php	(working copy)
@@ -127,6 +127,11 @@
     protected $_sessionName;
 
     /**
+     * Session rows from find()
+     */
+    protected $_rows = array();
+
+    /**
      * Constructor
      *
      * $config is an instance of Zend_Config or an array of key/value pairs containing configuration options for
@@ -319,6 +324,7 @@
 
         if (count($rows)) {
             if ($this->_getExpirationTime($row = $rows->current()) > time()) {
+                $this->_rows = $rows;
                 $return = $row->{$this->_dataColumn};
             } else {
                 $this->destroy($id);
@@ -342,7 +348,7 @@
         $data = array($this->_modifiedColumn => time(),
                       $this->_dataColumn     => (string) $data);
 
-        $rows = call_user_func_array(array(&$this, 'find'), $this->_getPrimary($id));
+        $rows = $this->_rows;
 
         if (count($rows)) {
             $data[$this->_lifetimeColumn] = $this->_getLifetime($rows->current());

--=-F1LxuPSG0ree4q7XTXaY--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 11 Nov 2009 14:40:35 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

-- Benjamin Eberlei <[email-masked]> wrote
(on Wednesday, 11 November 2009, 08:06 PM +0100):
> looks great!
> 
> how will we conceptionally move from php 5.x to 5.3? might it be a good idea 
> to implement a rough tokenizer => transformer to apply for example the 
> following rules:
> 
> 1. collect all classes and interfaces using Reflection and Zend_Reflection_File.
> 
> Package_Subpackage_Class => Package\Subpackage\Class
> 
> if(Class == Abstract)
> Class = SubpackageAbstract
> 
> if(Class == Interface)
> Class = Subpackage
> 
> if(Class == Exception)
> class = ExceptionImpl implements Exception
> + Interface Exception
> 
> 2. Define all exceptions to this rule in a simple array map (important for most 
> of the interfaces).
> 
> 3. iterate over the code with a tokenizer on a file basis, find all INTERFACE 
> and CLASS tokens and when re-applying them to the file change with the new 
> code.
> 
> Imho this would be better than to ask all the maintainers to make the 
> migration, since that will probably take several months and make it incredible 
> hard to work with the trunk.

My thought is that we can do the first pass using something like this,
and then go through manually to do more targetted changes. Stas has done
something like this already previously, and I hope to get some code from
him so we can work on it.

In looking at your above notes, I realize that there's another change
that needs to be noted in the docs: targetting the PHP Interop Group's
specifications. The Exception usage is in line with our current
discussions, already. The package naming will work -- but the ideal is
to ship package names as all lowercase. Any script for migration will
need to take that into account as well.

> On Wednesday 11 November 2009 07:38:57 pm Matthew Weier O'Phinney wrote:
> > Hey, all --
> >
> > There have been a ton of questions about the ZF 2.0 roadmap, and my
> > answer has been consistently, "I'm working on it; I'll have something to
> > publish soon."
> >
> > "Soon" is now:
> >
> >    
> > http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
> >
> > I'd like you, as contributors, to look over it, and start discussing the
> > various ramifications; we can do that either in comments to the pages or
> > on this list.
> >
> > The roadmap is primarily a conceptual one right now, though a
> > proof-of-concept has been created for the proposed MVC. I'd like to stay
> > fairly high-level for now, and then start getting a flow of proposals
> > into the system for specific migration-related tasks.
> >
> > Thanks everyone who has provided me input over the past many months, and
> > let's get started on the next generation of ZF!
> 
> 
> -- 
> Benjamin Eberlei
> http://www.beberlei.de
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 17 Jan 2010 10:47:10 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend_Serializer work

-- Julien Pauli <[email-masked]> wrote
(on Saturday, 16 January 2010, 11:52 PM +0100):
> I recently commited 20343-20345-20346 for Zend_Serializer.
> See http://framework.zend.com/issues/browse/ZF-8844 - http://framework.zend.com
> /issues/browse/ZF-8842
> 
> I forgot to set the "Fix/Version" to next minor (1.10) , how can I edit that
> later ? Reopening the issue seems the only way right ?

They appear to be correct currently. There's an "Edit" link in the
sidebar you can use to edit those details; if you don't have that, you
can ping myself or anyone else on the Zend team to edit the issue for
you.

> Anyway, tell me if something goes wrong with the patches (shouldn't) ;-)

They look good.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Sat, 23 Jan 2010 11:58:16 +0100
Subject: Re: [zf-contributors] Zend_Date & build-in class Da

You are comparing apples with oranges.
A discussion on such a basis is completly useless.

Actually Zend_Date uses mktime. So when you want to compare one=20
implementation to the other you need to compare mktime to DateTime.

And of course you already did a real comparison as you reworked Zend_Date=
.=20
Did you?

Just for information... the lack of performance is due to the reason how =
I=20
was forced to implement the class. A class which is 4500 lines long and a=
dds=20
about 200 methods will never be as performant as a extension which has ha=
s=20
only 15 methods.

When I am not forced to do the API within a few days as with 0.7 and am=20
allowed to rework it as it should be done then even the existing mktime=20
implementation would be multiple times faster.

PS: Related to mktime DateTime performs also slower. The real benefit is=20
only for calculations beside the 32bit unix timestamp.

PPS: Again... as said in past... as long as we are limited to 5.2.4 there=
=20
will be no rework due to some major problems which has been solved in lat=
er=20
releases.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Benjamin Eberlei" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, January 23, 2010 1:36 AM
Subject: Re: [zf-contributors] Zend_Date & build-in class Da

> =3D?UTF-8?Q?teTime?=3D
>
>
> The only thing DateTime can't handle that Zend_Date can as of 5.3 is
>
> localized output
>
> and maybe some special features.
>
>
>
>>From the performance point of view, i have tested three use-cases again=
st
>
> each
>
> other:
>
>
>
> 1. Printing the same instance 100 times
>
>
>
> $s =3D microtime(true);
>
> $d =3D new DateTime("now");
>
> for($i =3D 0; $i < 100; $i++) {
>
>   $d->format('d.m.Y, H:i');
>
> }
>
>
>
> $date =3D new Zend_Date(1234567890, false);
>
> for($i =3D 0; $i < 100; $i++) {
>
>    $date->toString('d.m.Y, H:i');
>
> }
>
>
>
> Gives:
>
> DateTime 0.0004s
>
> Zend_Date 0.0599s
>
>
>
> 2. Changing the date by Unix-Timestamp on each run for 100 times:
>
>
>
> $d =3D new DateTime("now");
>
> for($i =3D 0; $i < 100; $i++) {
>
>   $d->setTimestamp($now + $i * 7200);
>
>   $d->format('d.m.Y, H:i');
>
> }
>
>
>
> $date =3D new Zend_Date(1234567890, false);
>
> for($i =3D 0; $i < 100; $i++) {
>
>    $date->setTimestamp($now + $i * 7200);
>
>    $date->toString('d.m.Y, H:i');
>
> }
>
>
>
> Gives:
>
> DateTime 0.0010s
>
> Zend_Date 0.0591s
>
>
>
> 3. Changing Date on each call by a defined format (MySQL Database) for =
100
>
> new instances.
>
>
>
> Now this is the most evil performance hit.
>
>
>
> $s =3D microtime(true);
>
> for($i =3D 0; $i < 100; $i++) {
>
>   $d =3D DateTime::createFromFormat('Y-m-d H:i:s', '2009-04-01 12:12:12=
');
>
>   $d->format('d.m.Y, H:i');
>
> }
>
>
>
> for($i =3D 0; $i < 100; $i++) {
>
>    $date =3D new Zend_Date('2009-04-01 12:12:12', Zend_Date::ISO_8601);
>
>    $date->toString('d.m.Y, H:i');
>
> }
>
>
>
> DateTime: 0.0020s
>
> Zend_Date: 0.1982s
>
>
>
> DateTime is faster than Zend_Date by a magnitute of 60-100!!
>
>
>
>
>
> On Fri, 22 Jan 2010 15:59:32 -0800 (PST), P=C3=A1draic Brady
>
> <[email-masked]> wrote:
>
>> Personally I don't see DateTime as massively important to Zend_Date. I=
t
>
>> would be nice to have, but the class itself is pretty basic that I'm n=
ot
>
>> sure what exactly it would add to Zend_Date other than offer a
>
> (measured?)
>
>> performance boost and some import/export functionality for
>
> interoperability
>
>> (would have been nicer to have a DateTime interface).
>
>>
>
>>  P=C3=A1draic Brady
>
>>
>
>> http://blog.astrumfutura.com
>
>> http://www.survivethedeepend.com
>
>> OpenID Europe Foundation Irish Representative
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> ________________________________
>
>> From: Marc Bennewitz <[email-masked]>
>
>> To: [email-masked]
>
>> Sent: Fri, January 22, 2010 10:16:02 PM
>
>> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>
>>
>
>>  Hi all,
>
>>
>
>> Does is matter that Zend_Date doesn't extends the build-in DateTime
>
>> class ?
>
>> -> The DateTime class is available since PHP
>
>> 5.2.0 and ZF require PHP 5.2.4.
>
>>
>
>> It would be very nice because than Zend_Date would be compatible to
>
>> other php libraries using DateTime and within ZF tests like the
>
>> following can simplify:
>
>>
>
>> if ($date instanceof Zend_Date_DateObject) {
>
>>     $timestamp =3D $date->getUnixTimestamp();
>
>> } elseif ($date instanceof DateTime) {
>
>>     $timestamp =3D $date->getTimestamp();
>
>> } else {
>
>>     $timestamp =3D (float)$date;
>
>> }
>
>>
>
>> Greetings,
>
>> Marc=20

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Robin Skoglund <[email-masked]>
Date: Wed, 11 Nov 2009 21:28:51 +0100
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney <[email-masked]> wrote:
>
> In looking at your above notes, I realize that there's another change
> that needs to be noted in the docs: targetting the PHP Interop Group's
> specifications. The Exception usage is in line with our current
> discussions, already. The package naming will work -- but the ideal is
> to ship package names as all lowercase. Any script for migration will
> need to take that into account as well.

Do you have a link for the PHP Interop Group specifications? I was
about to make a comment in the wiki about the Exception usage, but I
guess I should read up on the mentioned docs first.

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 01:26:34 -0500
From: Ralph Schindler <[email-masked]>
To: "Zend Framework Contributors" <[email-masked]>
Subject: [zf-contributors] Poll: Namespace usage in ZF class method signatures

Hey All:

With PHP 5.3, one of the biggest improvements to the language is 
namespaces.  ZF 2.0 intends on taking full advantage of namespaces.  One 
of the issues that has come up is how namespaces affect namespace and 
class naming.  This email is intended to start a discussion on-list of 
some ideas and issues we've seen and would like to discuss with the 
community.

On Method Signatures--

As developers, with or without the help of tools, we look at method 
signatures to fully understand what a method expects.  Many cases in ZF, 
we use type hinting to force a specific type on a method.  With 
namespaces, a potential issue crops up with the clarity of a method 
signature.

Say for example we have a namespace Foo, class Bar, and method baz. Also 
assume there is a namesapce called Qux\Garply involved. Here are a 
number of ways baz might be written.

<?php

namespace Foo;

class Bar
{
     // this method accepts an instance of itself
     public static function baz(Bar $bar) {}
}

---

<?php

namespace Foo;

class Bar
{
     // this method accepts an instance of itself
     public static function baz(\Foo\Bar $bar) {}
}

---

<?php
// this class has a use statement

namespace Foo;
use Qux\Garply as garp;

class Bar
{
     // this method accepts an instance of Qux\Garply\Bar
     public static function baz(garp\Bar $bar) {}
}

---

<?php

namespace Foo;
use Qux\Garply as garp;

class Bar
{
     // this method accepts an instance of Qux\Garply\Bar
     public static function baz(\Qux\Garply\Bar $bar) {}
}

===

One thing to notice is that if method signatures contain a fully 
qualified name (those starting with a \) for type hints, you don't need 
to know anything about what namespaces or aliases are in play; 
everything you need to know is right in front of you. However, on the 
flip side of the coin, fully qualified names are much more verbose, 
somewhat defeating the purpose of namespaces and aliasing in the first 
place.

When using unqualified names (those not starting with a \), you gain 
some readability (names are more brief), but need to know what the 
current namespace is, and what aliases were defined in order to resolve 
the classname.

(Matthew notes that in his days working with Perl, the situation was 
really no different with packages, and the majority of Perl devs used 
aliases when referring to classes. This may or may not be relevant to 
PHP, however.)

The question is, what is the best practice here?  When looking at code 
like this, which do you expect would be easier to understand?

Should library/framework specific code be more expressive using fully 
qualified names in method signatures and consequently in docblocks? Or 
is using unqualified names just as easy to understand and/or more readable?

What do you think?
-Ralph

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 19:45:45 +0100
From: Dolf Schimmel <[email-masked]>
To: =?UTF-8?B?0KHQsNGI0LAg0KHRgtCw0LzQtdC90LrQvtCy0LjRmw==?=
	<[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Zend_Tool is getting more powerful with every sunset, The first
results of this can be seen with 1.10. I propose however against an
'official' Zend_Model. There are zillions (not sure how many that is;
but it's a lot) ways of implementing models. We can impossibly think
of a model/class that supports all of these different methods.

Dolf

On Thu, Nov 12, 2009 at 8:22 AM, =D0=A1=D0=B0=D1=88=D0=B0 =D0=A1=D1=82=D0=
=B0=D0=BC=D0=B5=D0=BD=D0=BA=D0=BE=D0=B2=D0=B8=D1=9B <[email-masked]> wr=
ote:
> Very nice!
> What about Zend_Model? Will we have some official component for M in MVC,=
 or
> we will stay on VC in zf 2.0?
> Will Zend_Tool get more powerful, generating models from db scheme, unit
> tests etc?
>
> Regards,
> Sa=C5=A1a Stamenkovi=C4=87
>
>
> On Wed, Nov 11, 2009 at 9:37 PM, Guilherme Blanco
> <[email-masked]> wrote:
>>
>> http://groups.google.com/group/php-standards/web/final-proposal
>>
>> On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[email-masked]> wrot=
e:
>> > On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney
>> > <[email-masked]> wrote:
>> >>
>> >> In looking at your above notes, I realize that there's another change
>> >> that needs to be noted in the docs: targetting the PHP Interop Group'=
s
>> >> specifications. The Exception usage is in line with our current
>> >> discussions, already. The package naming will work -- but the ideal i=
s
>> >> to ship package names as all lowercase. Any script for migration will
>> >> need to take that into account as well.
>> >
>> > Do you have a link for the PHP Interop Group specifications? I was
>> > about to make a comment in the wiki about the Exception usage, but I
>> > guess I should read up on the mentioned docs first.
>> >
>>
>>
>>
>> --
>> Guilherme Blanco - Web Developer
>> CBC - Certified Bindows Consultant
>> Cell Phone: +55 (16) 9215-8480
>> MSN: [email-masked]
>> URL: http://blog.bisna.com
>> S=C3=A3o Paulo - SP/Brazil
>
>

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Fri, 17 Apr 2009 21:03:28 +0200
Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*

* Zend_Filter_LocalizedToNormalized, contributed by Thomas Weidner
* Zend_Filter_NormalizedToLocalized, contributed by Thomas Weidner

----- Original Message ----- 
From: "Benjamin Eberlei" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 07, 2009 8:51 AM
Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*

>* Added  Zend_Json Expression support, contributed by Benjamin Eberlei
> * Added Zend_Http_Client_Adapter_Curl, contributed by Benjamin Eberlei
>
> On Monday 06 April 2009 22:07:01 Thomas Weidner wrote:
>> My most important additions for 1.8 are:
>>
>> * several improvements to Zend_File_Transfer and Zend_Form_Element_File,
>> contributed by Thomas Weidner
>> * added file upload progress to Zend_File_Transfer, contributed by Thomas
>> Weidner
>> * added 84 new IDN's and completly reworked Zend_Validate_Hostname,
>> contributed by Thomas Weidner
>> * added locale support to Zend_Validate_Int and Zend_Validate_Float,
>> contributed by Thomas Weidner
>> * added phonecode support to Zend_Locale, contributed by Thomas Weidner
>> * Zend_Validate_Iban, contributed by Thomas Weidner
>> * Zend_Validate_File_WordCount, contributed by Thomas Weidner
>> * Zend_Filter_Encrypt, contributed by Thomas Weidner
>> * Zend_Filter_Decrypt, contributed by Thomas Weidner
>> * added logging support to Zend_Translate, contributed by Thomas Weidner
>> * added documentation of all Zend_Validate messages, contributed by 
>> Thomas
>> Weidner
>>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com
>>
>> ----- Original Message -----
>> From: "Wil Sinclair" <[email-masked]>
>> To: "Robin Skoglund" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Monday, April 06, 2009 8:02 PM
>> Subject: RE: [zf-contributors] 1.8 PR feature list and *acknowledgements*
>>
>>
>> I believe Zend_Navigation is in if the minor changes that we have
>> recommended are made. Matthew can tell you more. It is a really sweet
>> component, BTW. J
>>
>>
>>
>> ,Wil
>>
>>
>>
>> From: Robin Skoglund [mailto:[email-masked]]
>> Sent: Monday, April 06, 2009 11:02 AM
>> To: Wil Sinclair
>> Cc: [email-masked]
>> Subject: Re: [zf-contributors] 1.8 PR feature list and
>> *acknowledgements*
>>
>>
>>
>> On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <[email-masked]> wrote:
>>
>> NOTE: For this release, we'd like to try something new in the feature
>> list- actually acknowledging the significant contributions that y' all
>> have made. J The format would be like this:
>>
>>
>>
>> * Zend_Application, contributed by Matthew Weier O'Phinney and Ben
>> Scholzen
>>
>>
>>
>> ,Wil
>>
>> Hi, I haven't gotten any answer on whether Zend_Navigation will be
>> included in the PR, but here goes:
>>
>> * Zend_Navigation, contributed by Robin Skoglund
>>
>>         robinsk
>
> -- 
> Benjamin Eberlei
> http://www.beberlei.de

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com 

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: James Dempster <[email-masked]>
Date: Sun, 4 Oct 2009 23:37:45 +0100
To: Graham Anderson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [zf-contributors] Google Wave - public waves, tagging, contacts

Thanks for the invite. Very much looking forward to try Wave out.
Still waiting to hear anything from Google but once I'm on there I'll
add you :-)

Was wondering if you've looked into any of their APIs?

/James

On 1 Oct 2009, at 20:27, Graham Anderson <[email-masked]>
wrote:

> One you guys get on Wave, at first you=C2=B4ll notice there's nothing muc
> h to do.
> Your contact list may be empty and there may only be the "welcome"
> waves in
> your inbox.
>
> Quick start
> -----------
>
> Waves can be both private and public, to find public waves enter the
> query
> term "with:public" in the search bar at the top of the wave list.
> You can
> further refine the search by adding tags e.g. "with:public tag:help".
>
> There are a few useful waves copied over from the sandbox, probably
> the most
> useful at the moment is the "Wave FAQ", search for "with:public
> tag:faq".
>
>
> Tagging
> -------
>
> It would of course seem sensible to tag anything related to Wave +
> ZF as
> simply "zf" or "ZF", I'm not sure if tags and search by tag is case
> sensitive.
> Multiple tags are of course supported.
>
>
> Making a wave public
> --------------------
>
> At the moment you can participate in a wave by either being added
> manually by
> one of the existing wave participants, or by searching for a wave
> and then
> contributing. If you are not added manually by someone else who may
> think the
> wave will be of interest to you, you can only discover a wave if it
> is made
> public.
>
> To make a wave public for now you need to add the special participant,
> [email-masked]
>
> You may find it convenient to add [email-masked] to your
> contacts, when
> you try to do so the contact applet will tell you this is not a
> valid wave
> address but just hit enter and it will be added anyway.
>
>
> Contacts
> --------
>
> Your Wave address will be the first part of your gmail/google
> account followed
> by googlewave.com, e.g. My gmail address is
> [email-masked] so my
> Wave contact address is [email-masked].
>
> The contact applet within wave has some bugs, profile/avatar pics is
> flaky,
> and contact management redirects you to your main google account
> contacts. It
> doesn't seem possible to manage your wave contacts from here yet.
>
> Searching for contacts is either suffering from the current lag/load
> levels or
> is just broken. To that end I'll create a public wave, tagged with
> "zf" as a
> work-around contact list, edit the blip with known ZF'ers Wave
> contact details
> to add your own once you Wave account is activated.
>
> See you soon on Wave :)
>
>
> --
> =E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=
=9D
> =E2=98=98 Oscar Wilde

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 26 Jul 2009 17:58:28 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: Carlton Gibson <[email-masked]>,
	[email-masked]
Mail-Followup-To: Carlton Gibson <[email-masked]>,
	[email-masked]
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services
	to ZendX Proposal

-- Carlton Gibson <[email-masked]> wrote
(on Sunday, 26 July 2009, 06:59 PM +0100):
> On 26 Jul 2009, at 16:29, Matthew Weier O'Phinney wrote:
>
> > We need more community help in maintaining the framework. I have some
> > ideas on how to achieve this, but I need *your* ideas as well, as
> > contributors.
>
>  From my experience it's really hard to get started helping out, even if 
> you want to.
>
> I don't have (or haven't yet had) the time (or indeed perhaps skill :-) 
> to be taking on the lead on major components, but I have had some time to 
> work on something. What I found though was that it wasn't very clear 
> where or how to start.
>
> I think there needs to be a much clearer and easier to follow route into 
> helping out. (Something like the Post Office "Help Wanted" board in Paper 
> Mario would be great.) 

This is a really cool idea, and something we could probably get into
place pretty quickly. It would, however, require both maintainers
posting and requesting help, as well as somebody periodically going
through the tracker and identifying components that are in need of new
maintainers. I'll brainstorm some ideas around this.

> The issue tracker works but it takes too much time to learn. (95% of
> the time and energy I have had available has been spent on the issue
> tracker rather than actually doing anything. Admittedly I'm slow, but
> I doubt I'm alone.)

The issue tracker has a wealth of information, and that both works in
its favor and against it. I've got an offer of help from Atlassian to
upgrade and optimize our install, and that may make things a better in
this regard.

> I also think the documentation needs to be moved to a wiki format. A lot 
> of the complaints on the mailing list concern the documentation -- so let 
> people fix it themselves. (Again, I've often thought about suggesting a 
> fix to the docs but am put off by the thought of having to take on the 
> issue tracker for the sake of a single sentence or paragraph.)

We will *not* be moving to a wiki format. We actually use DocBook for
its intended purpose: to make it easy to create documentation in a
variety of formats. We create HTML documentation, obviously, but we also
create a PDF version for the zend.com website, and several people have
created CHM versions. Thomas and Mikael have convinced me to have PDF
and CHM targets by default in our Makefile to ensure that these are easy
for developers to produce on-demand.

One way we can easily solicit feedback for improving documentation is to
add comments to the manual. This is something we need to add to the
website, and then we also need to add a process for periodically
reviewing the comments and incorporating feedback into the manual. I'm
hoping we can accomplish this for the 1.10 release.

> Finally, I think there needs to be a place (the contributors list maybe) 
> where people are welcome (encouraged) to come with questions about how to 
> proceed with an issue. Not enough people are subscribed to each issue in 
> the tracker to make this viable there. (Perhaps this is what the 
> contributors list is for but if so that needs to be better advertised.)

This is exactly one purpose of the contributors list, and I encourage
you to steer people here if they want to discuss issues from the
tracker.

> Just ideas.

And some very good ideas are contained in it! Thank you!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 22 Oct 2009 12:35:50 -0400
From: "A.J. Brown" <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Zend_Service_PayPal Project

I've finally created a Google code repo to get some collaborate on
this.  Right now, just the code is up.

http://code.google.com/p/zendservicepaypal/

Please reply with your gmail info if you want to help contribute.  In
addition to the code, I'd like to start working on documentation in
the Wiki as well.  I'll move things over to the proposal in the Zend
Framework wiki as they start to materialize.

I know the code is rather simple for how long it's been pending, but I
have 3 projects which will depend on it in the next couple of months.
Along with everyone's eager support, I think we should be able to
tighten this thing down rather quickly.

When developing, please develop in your own branch.  We'll merge
things down when needed.

Thanks, all.

-- 
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Fri, 22 Jan 2010 20:50:06 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors] Doctrine 1 Integration Ideas

Almost, i settled with how controllers work now:

Example 1: module =3D user (not default) | controller & model =3D User
modules/user/controllers/UserController.php   :   User_UserController
modules/user/models/User.php   :   User_Model_User
=20
Example 2: module =3D default (default) | controller & model =3D User
modules/default/controllers/UserController.php   :  UserController
modules/default/models/User.php   :   Model_User

This is the most simple and most consistent way for ZF & Doctrine
integration, and its pretty simple to implement :)

Actually i have already finished the code-generation stuff and
tested it, whats missing is the Doctrine resource and Zend_Tool providers=
.
Lets see what the night will bring :-)

On Fri, 22 Jan 2010 19:21:54 +0100, Marc Bennewitz
<[email-masked]> wrote:
>> ah default module seems to be a problem, or not?. When should the
default
>> prefix be added, when not? Is there a way to use the same names as
>> already
>> used for controllers ?
> Is there a way to use the same names as already used for controllers ?
>=20
> Example 1: module =3D user | controller & model =3D User
> modules/user/controllers/UserController.php   :   User_UserController
> modules/user/models/UserModel.php   :   User_UserModel
>=20
> Example 2: module =3D default | controller & model =3D User
> modules/default/controllers/UserController.php   :  UserController
> modules/default/models/UserModel.php   :   UserModel
>=20
>=20
>=20
> Am 22.01.2010 14:36, schrieb Benjamin Eberlei:
>> Hey Paddy,
>>
>> ah default module seems to be a problem, or not?. When should the
default
>> prefix
>> be added, when not? How does the resource autoloader work in this
>> context?
>>
>> Questions:
>>
>> 1. How does the resource loader look like if default module is
"default"?
>> 2. How does the resource loader look like if default module is "blog"?
>>
>> greetings,
>> Benjamin
>>
>> On Fri, 22 Jan 2010 04:40:12 -0800 (PST), P=C3=A1draic Brady
>> <[email-masked]> wrote:
>>  =20
>>> Replies inline.
>>>
>>>    =20
>>>> Hello everyone,
>>>>
>>>> there hasn't been much news on this front lately, me was kinda busy
>>>> with
>>>> work and such.
>>>>
>>>> Yesterday I reviewed all the stuff i found on ZF and Doctrine 1
>>>> integration and came to
>>>> the conclusion that while single modular generation is supported by
>>>> Doctrine 1.2's new
>>>> PEAR style model generation you still have to hack lots around.
>>>>
>>>> Therefore my idea is, two-fold:
>>>>
>>>> I. Single ZF Module (Default)
>>>>
>>>> Support Single-Default-Module Scenario more easily by providing a
>>>> config-option
>>>> that automatically sets all the model-generation options correctly.
>>>> This
>>>> would
>>>> be something along the lines of:
>>>>
>>>> $import->setOptions(array(
>>>>    'pearStyle' =3D> true,
>>>>    'baseClassesDirectory' =3D> null,
>>>>    'baseClassPrefix' =3D> 'Base_',
>>>>    'classPrefix' =3D> 'Model_',
>>>>    'classPrefixFiles' =3D> true
>>>> ));
>>>>
>>>> This allows for models of the Style "Model_User", "Model_Foo",
>>>> "Model_Bar".
>>>>
>>>> HOWEVER: Can someone explain to me how that relates to the class nam=
e
>>>>      =20
>> that
>>  =20
>>>> you can
>>>> specifiy in the YAML config file?
>>>>      =20
>>> As in a schema config? Schema would just use Model_User/Model_Foo in
>>>    =20
>> this
>>  =20
>>> case. Not sure if that's what you meant though. The main settings
above
>>>    =20
>> of
>>  =20
>>> interest are classPrefix and classPrefixFiles. classPrefix would
simply
>>> prepend the Module name for module autoloading, though I think
>>> classPrefixFiles would be false to omit the Module name from the
actual
>>> files, so we just have, for example, /application/models/User.php and
>>> /application/models/Foo.php.
>>>
>>> Main thing I'd be interested in is of this option would support the
more
>>> complex scenario of having a named default module, e.g.
>>> /application/modules/default (giving Default_Model_User at
>>> /application/modules/default/models/User.php). I use a named default
all
>>> the time, though of course the ZF CLI tool isn't exactly cooperative
>>>    =20
>> with
>>  =20
>>> that ;).
>>>
>>>    =20
>>>> No upgrade mechanism from single module to multiple module will be
>>>> provided.
>>>>
>>>> II. Doctrine + Multiple ZF MOdules:
>>>>
>>>> Circumvent Doctrine_Core::loadModels() completely by introducing a
new
>>>> auto-loading
>>>> mechanism and slightly modifying the Doctrine_Import_Schema class.
>>>>      =20
>>> I'd circumvent it anyway, isn't there anyway to leverage off our
already
>>> built in resource autoloading? That's already set up to handle all
>>>    =20
>> module
>>  =20
>>> contingencies for models, forms, etc. assigned to directories with
those
>>> names.
>>>
>>>    =20
>>>> This style would do no magic, it would require you to use class name=
s
>>>> of
>>>> the kind:
>>>>
>>>> <ModuleName>_Model_<ModelName>
>>>>
>>>> Doctrine would auto-load all the classes of the kind in all
>>>> <moduleName>/models through
>>>> a Module Resource Loader.
>>>>      =20
>>> Spoke too soon - yeah, that's the way it probably should work by
>>>    =20
>> default.
>>  =20
>>> It's a current convention and if someone want's to start changing it
>>> around, they can do their thing with the local include_path by
>>>    =20
>> themselves.
>>  =20
>>>    =20
>>>> For the CLI tasks in Zend Tool there would be a dection of all model=
s
>>>> by
>>>> the mechanism.
>>>>
>>>> 1. Get Front Controller module/controller directory
>>>> 2. Iteratore over them and find all models directories.
>>>> 3. Recursively scan all models directories for
>>>> <ModuleName>_Model_<ModelName> classes.
>>>>
>>>> For the YAML to Model Generation task the mechanism would be.
>>>>
>>>> 1. Detect Module name by checking the first result of explode("_",
>>>> $className)
>>>> 2. If the first is "Model", grab default module from
Front-Controller,
>>>> otherwise Check that second result is "Model"
>>>> 3. Write record, base-record and optionally table classes into the
>>>>      =20
>> modules
>>  =20
>>>> model directory.
>>>>      =20
>>> Bear in mind that any module name can be the default. Not sure if tha=
t
>>> makes any different if picked up as a distinct modules anyway.
>>>
>>>    =20
>>>> This requires a Doctrine + Zend Modular Application to follow strict
>>>>      =20
>> class
>>  =20
>>>> naming standards,
>>>> but makes the implementation very robust in terms of both frameworks
>>>> and
>>>> avoids any
>>>> additional magic (Looking at the Doctrine 1 code, there is already
too
>>>> much magic!)
>>>>
>>>> Any ideas?
>>>>
>>>> My plan is to get this into 1.11, I'll colaborate with Matthew Lurz
>>>> also
>>>> to get the
>>>> Doctrine application resource ready for this then.
>>>>
>>>> Also my plan is that this integration will require Doctrine 1.2
>>>>      =20
>>> Doctrine 1.2 is fine. Little point supporting an older version whose
use
>>> in new applications should be declining.
>>>
>>> greetings,
>>> Benjamin
>>>    =20
>>

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Julien Pauli <[email-masked]>
Date: Wed, 3 Jun 2009 23:38:44 +0200
To: "Sean P. O. MacCath-Moran" <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Seeking "ZF Contributor" Mentor

--0016369cff73fd4712046b787c50
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hey - Hi Here :-)

Thanks for contributing to Zend Framework, and welcome to this great familly
of modern-web-app-framework developpers and engineers.
However, I'm not well placed to answer you, as I just work on ZF Core and
Doc translation as a completly free contributor, but not on proposals.

Anyway, you should wait for a Zend person to answer you here, he will
explain you all the stuff you need to know.
Also, you could join us (and by this way contact a zend person) on IRC (
http://www.zftalk.com/channel/)

Cheers ^^

Julien.P

On Tue, Jun 2, 2009 at 8:56 PM, Sean P. O. MacCath-Moran <[email-masked]
> wrote:

> Greetings ZF Community,
>
> I'm looking for a mentor for my first foray into Open Source development.
>
> I am a Zend Certified Engineer with over a decade development
> experience (ref http://www.emanaton.com/cv). My CLA has been received
> and approved. I've read through the various entries on the
> framework.zend site for how the contribution process and proposal
> life-cycles function. I'm currently developing code for a project that
> mirrors a Component Proposal, but that proposal has been dormant for
> some time (i.e.
>
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+Rob+Allen
> ).
> I wrote to that proposal's author, Rob Allen, and received word that
> he is no longer working on that project, giving the go ahead to work
> on it. Therefore, I would like to go through the process of proposing,
> discussing, developing, and submitting this code.
>
> All that aside, I've never contributed directly to an open source
> project before. So, rather than flailing about for the answers
> anymore, I'd like to proposition an experienced member(s) of the team
> for a bit of guidance. I'm probably not going to require much
> hand-holding, but I would very much like to have someone(s) I can
> touch base with and make sure that I'm heading in the right direction
> from time to time.
>
> Is there anyone who would feel comfortable fullfilling such a role?
> Should I just use this list and get general feedback? If the latter,
> would anyone care to advise me on my next step? e.g., should I create
> a new proposal, or should I be taking over the original one somehow?
>
> Thanks in advance!
>
> Sean P. O. MacCath-Moran
> www.emanaton.com
>

--0016369cff73fd4712046b787c50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey - Hi Here :-)<br><br>Thanks for contributing to Zend Framework, and wel=
come to this great familly of modern-web-app-framework developpers and engi=
neers.<br>However, I&#39;m not well placed to answer you, as I just work on=
 ZF Core and Doc translation as a completly free contributor, but not on pr=
oposals.<br>

<br>Anyway, you should wait for a Zend person to answer you here, he will e=
xplain you all the stuff you need to know.<br>Also, you could join us (and =
by this way contact a zend person) on IRC (<a href=3D"http://www.zftalk.com=
/channel/">http://www.zftalk.com/channel/</a>)<br>

<br>Cheers ^^<br><br>Julien.P<br><br><div class=3D"gmail_quote">On Tue, Jun=
 2, 2009 at 8:56 PM, Sean P. O. MacCath-Moran <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Greetings ZF Community,<br>
<br>
I&#39;m looking for a mentor for my first foray into Open Source developmen=
t.<br>
<br>
I am a Zend Certified Engineer with over a decade development<br>
experience (ref <a href=3D"http://www.emanaton.com/cv" target=3D"_blank">ht=
tp://www.emanaton.com/cv</a>). My CLA has been received<br>
and approved. I&#39;ve read through the various entries on the<br>
framework.zend site for how the contribution process and proposal<br>
life-cycles function. I&#39;m currently developing code for a project that<=
br>
mirrors a Component Proposal, but that proposal has been dormant for<br>
some time (i.e.<br>
<a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Man=
ager+-+Rob+Allen" target=3D"_blank">http://framework.zend.com/wiki/display/=
ZFPROP/Zend_Db_Schema_Manager+-+Rob+Allen</a>).<br>
I wrote to that proposal&#39;s author, Rob Allen, and received word that<br=
he is no longer working on that project, giving the go ahead to work<br>
on it. Therefore, I would like to go through the process of proposing,<br>
discussing, developing, and submitting this code.<br>
<br>
All that aside, I&#39;ve never contributed directly to an open source<br>
project before. So, rather than flailing about for the answers<br>
anymore, I&#39;d like to proposition an experienced member(s) of the team<b=
r>
for a bit of guidance. I&#39;m probably not going to require much<br>
hand-holding, but I would very much like to have someone(s) I can<br>
touch base with and make sure that I&#39;m heading in the right direction<b=
r>
from time to time.<br>
<br>
Is there anyone who would feel comfortable fullfilling such a role?<br>
Should I just use this list and get general feedback? If the latter,<br>
would anyone care to advise me on my next step? e.g., should I create<br>
a new proposal, or should I be taking over the original one somehow?<br>
<br>
Thanks in advance!<br>
<font color=3D"#888888"><br>
Sean P. O. MacCath-Moran<br>
<a href=3D"http://www.emanaton.com" target=3D"_blank">www.emanaton.com</a><=
br>
</font></blockquote></div><br>

--0016369cff73fd4712046b787c50--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 23 Jan 2010 19:54:06 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Date & build-in class Da

The only one I would reveal is that it isn't clear if a Zend_Date object
is a date only or incl. time.
Sure, I know it for my own code but projects are not only written by
oneself. And this is one more you have to document because it isn't
suffice to scan and skim.

If you inherit a project form another than you get problems If $date
incl. time(zone) or exclusive ?
Do you have to convert timezone to users timezone on display or not ?

Than if $date wouldn't have a time part it is clear and can't do it wrong=
.

> When not then they are ignored.
I can't disable timezone within Zend_Date - for default its the global
configured timezone.
The only one I can do is to set it to UTC. Its an overhead in my mind.

Greetings
Marc

Am 23.01.2010 18:11, schrieb Thomas Weidner:
> Why should it?
> You decide what should be taken into account.
>
> When you are using timezones then timezones are taken into account.
> When not then they are ignored.
>
> These things are no problem for ZF.
> You just need to know what you want to do.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "Marc Bennewitz"
> <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, January 23, 2010 5:48 PM
> Subject: Re: [zf-contributors] Zend_Date & build-in class Da
>
>
>> hi thomas,
>>
>> one more general about Zend_Date: (Please correct my if I'm wrong)
>> Zend_Date handles date & time information. Therefore all date objects
>> have to handle timezones, too.
>> But if you only need the date part the timezone makes it confused.
>>
>> Birthday example:
>> User A:
>>  - current timezone =3D +2h (Europe/Berlin - MEST)
>>  - set his birthday =3D 1983-08-19  =3D 1983-08-19 00:00:00+0200
>>
>> User B:
>>  - current timezone =3D -8h (Nevada)
>>  - display birthday of User A =3D 1983-08-18 14:00:00-0800 =3D 1983-08=
-18
>>  =3D 1 day difference
>>
>> This means the developer have to know which dates have to store/displa=
y
>> with which timezones.
>>
>> I'm not a python developer but i think within it its solved well. Ther=
e
>> 3 classes: date, time and datetime.
>> - date is for only dates without timezone
>> - time is for only times with timezone
>> - datetime for both together
>>
>> Greetings
>> Marc
>>
>> Am 23.01.2010 11:58, schrieb Thomas Weidner:
>>> You are comparing apples with oranges.
>>> A discussion on such a basis is completly useless.
>>>
>>> Actually Zend_Date uses mktime. So when you want to compare one
>>> implementation to the other you need to compare mktime to DateTime.
>>>
>>> And of course you already did a real comparison as you reworked
>>> Zend_Date. Did you?
>>>
>>> Just for information... the lack of performance is due to the reason
>>> how I was forced to implement the class. A class which is 4500 lines
>>> long and adds about 200 methods will never be as performant as a
>>> extension which has has only 15 methods.
>>>
>>> When I am not forced to do the API within a few days as with 0.7 and
>>> am allowed to rework it as it should be done then even the existing
>>> mktime implementation would be multiple times faster.
>>>
>>> PS: Related to mktime DateTime performs also slower. The real benefit
>>> is only for calculations beside the 32bit unix timestamp.
>>>
>>> PPS: Again... as said in past... as long as we are limited to 5.2.4
>>> there will be no rework due to some major problems which has been
>>> solved in later releases.
>>>
>>> Greetings
>>> Thomas Weidner, I18N Team Leader, Zend Framework
>>> http://www.thomasweidner.com
>>>
>>> ----- Original Message ----- From: "Benjamin Eberlei"
>>> <[email-masked]>
>>> To: <[email-masked]>
>>> Sent: Saturday, January 23, 2010 1:36 AM
>>> Subject: Re: [zf-contributors] Zend_Date & build-in class Da
>>>
>>>
>>>> =3D?UTF-8?Q?teTime?=3D
>>>>
>>>>
>>>> The only thing DateTime can't handle that Zend_Date can as of 5.3 is
>>>>
>>>> localized output
>>>>
>>>> and maybe some special features.
>>>>
>>>>
>>>>
>>>>> From the performance point of view, i have tested three use-cases
>>>>> against
>>>>
>>>> each
>>>>
>>>> other:
>>>>
>>>>
>>>>
>>>> 1. Printing the same instance 100 times
>>>>
>>>>
>>>>
>>>> $s =3D microtime(true);
>>>>
>>>> $d =3D new DateTime("now");
>>>>
>>>> for($i =3D 0; $i < 100; $i++) {
>>>>
>>>>   $d->format('d.m.Y, H:i');
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> $date =3D new Zend_Date(1234567890, false);
>>>>
>>>> for($i =3D 0; $i < 100; $i++) {
>>>>
>>>>    $date->toString('d.m.Y, H:i');
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> Gives:
>>>>
>>>> DateTime 0.0004s
>>>>
>>>> Zend_Date 0.0599s
>>>>
>>>>
>>>>
>>>> 2. Changing the date by Unix-Timestamp on each run for 100 times:
>>>>
>>>>
>>>>
>>>> $d =3D new DateTime("now");
>>>>
>>>> for($i =3D 0; $i < 100; $i++) {
>>>>
>>>>   $d->setTimestamp($now + $i * 7200);
>>>>
>>>>   $d->format('d.m.Y, H:i');
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> $date =3D new Zend_Date(1234567890, false);
>>>>
>>>> for($i =3D 0; $i < 100; $i++) {
>>>>
>>>>    $date->setTimestamp($now + $i * 7200);
>>>>
>>>>    $date->toString('d.m.Y, H:i');
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> Gives:
>>>>
>>>> DateTime 0.0010s
>>>>
>>>> Zend_Date 0.0591s
>>>>
>>>>
>>>>
>>>> 3. Changing Date on each call by a defined format (MySQL Database)
>>>> for 100
>>>>
>>>> new instances.
>>>>
>>>>
>>>>
>>>> Now this is the most evil performance hit.
>>>>
>>>>
>>>>
>>>> $s =3D microtime(true);
>>>>
>>>> for($i =3D 0; $i < 100; $i++) {
>>>>
>>>>   $d =3D DateTime::createFromFormat('Y-m-d H:i:s', '2009-04-01
>>>> 12:12:12');
>>>>
>>>>   $d->format('d.m.Y, H:i');
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> for($i =3D 0; $i < 100; $i++) {
>>>>
>>>>    $date =3D new Zend_Date('2009-04-01 12:12:12', Zend_Date::ISO_860=
1);
>>>>
>>>>    $date->toString('d.m.Y, H:i');
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> DateTime: 0.0020s
>>>>
>>>> Zend_Date: 0.1982s
>>>>
>>>>
>>>>
>>>> DateTime is faster than Zend_Date by a magnitute of 60-100!!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, 22 Jan 2010 15:59:32 -0800 (PST), P=C3=A1draic Brady
>>>>
>>>> <[email-masked]> wrote:
>>>>
>>>>> Personally I don't see DateTime as massively important to
>>>>> Zend_Date. It
>>>>
>>>>> would be nice to have, but the class itself is pretty basic that I'=
m
>>>>> not
>>>>
>>>>> sure what exactly it would add to Zend_Date other than offer a
>>>>
>>>> (measured?)
>>>>
>>>>> performance boost and some import/export functionality for
>>>>
>>>> interoperability
>>>>
>>>>> (would have been nicer to have a DateTime interface).
>>>>
>>>>>
>>>>
>>>>>  P=C3=A1draic Brady
>>>>
>>>>>
>>>>
>>>>> http://blog.astrumfutura.com
>>>>
>>>>> http://www.survivethedeepend.com
>>>>
>>>>> OpenID Europe Foundation Irish Representative
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>> ________________________________
>>>>
>>>>> From: Marc Bennewitz <[email-masked]>
>>>>
>>>>> To: [email-masked]
>>>>
>>>>> Sent: Fri, January 22, 2010 10:16:02 PM
>>>>
>>>>> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>>>>
>>>>>
>>>>
>>>>>  Hi all,
>>>>
>>>>>
>>>>
>>>>> Does is matter that Zend_Date doesn't extends the build-in DateTime
>>>>
>>>>> class ?
>>>>
>>>>> -> The DateTime class is available since PHP
>>>>
>>>>> 5.2.0 and ZF require PHP 5.2.4.
>>>>
>>>>>
>>>>
>>>>> It would be very nice because than Zend_Date would be compatible to
>>>>
>>>>> other php libraries using DateTime and within ZF tests like the
>>>>
>>>>> following can simplify:
>>>>
>>>>>
>>>>
>>>>> if ($date instanceof Zend_Date_DateObject) {
>>>>
>>>>>     $timestamp =3D $date->getUnixTimestamp();
>>>>
>>>>> } elseif ($date instanceof DateTime) {
>>>>
>>>>>     $timestamp =3D $date->getTimestamp();
>>>>
>>>>> } else {
>>>>
>>>>>     $timestamp =3D (float)$date;
>>>>
>>>>> }
>>>>
>>>>>
>>>>
>>>>> Greetings,
>>>>
>>>>> Marc
>>>
>>>
>
>

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 12:01:51 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

-- Eric Clemmons <[email-masked]> wrote
(on Monday, 22 March 2010, 09:45 AM -0500):
> So, would a hypothetical (Github) workflow be as follows?
> 
> 1.  Fork Matthew's ZF repo
> 2.  Create local branch for adding feature (ie, OAuth2.0 support)
> 3.  Make atomic commits for unit tests, code changes, and new documentation
> 4.  Push branch to personal repo
> 5.  Issue a pull request for said feature
> 6.  Matthew runs a script that verifies my Github username against the
>     CLAs, subsequently adds the remote and pulls the feature branch.
> 
> Sounds like you'll be really busy, Matthew.
> 
> I'm sure the majority of contributors would not have direct write
> access to the Zend repo, which means the rest of the requests will
> have to be pull requests and properly QA'd prior to merging.

(replied personally earlier, publicly here)

I wouldn't be the only person with commit access to the repository, for
the very reason you describe. We will either give access to any active
component maintainers, create a QA team, or appoint community release
managers who would perform the pull requests.

In other words, there are a variety of approaches that can solve the
bottlenecks, and we'll evaluate which ones work best for the community.

> On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:
> 
> > Greetings, all --
> > 
> > Based on the wiki and the poll on this list, it looks like it makes
> > sense to move forward with git. We're still trying to iron on some
> > details about how this will work, but some details are falling into
> > place.
> > 
> > First, the things we plan:
> > 
> > * Git will be hosted on the ZF servers. This is so that we can have
> >   full control over hooks (i.e., no network latency from web hooks),
> >   integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
> >   will offer both anonymous access as well as selective writable
> >   access.
> > 
> >   Some will say, "why not just use Github?" The above does not preclude
> >   using github in any way; git allows you to specify multiple remotes
> >   from your repository. I already plan to have a mirror of my personal
> >   repo on github, as well as push to the ZF repo from the same
> >   location. This will allow people to use some of githubs powerful
> >   features such as pull queues while still allowing us to retain some
> >   control over the repository. (It also insulates us from githubs
> >   growing pains a bit -- I love github, but they are certainly
> >   suffering from rapid growth the last few months!)
> > 
> > * We plan to have a read-only subversion mirror of the git repository.
> >   This will allow those using svn:externals to continue to do so, as
> >   well as allow folks more familiar with svn to continue to provide
> >   patches.
> > 
> > Next, things we're still researching:
> > 
> > * How to handle contributions. Since we require a signed CLA, we need
> >   some way of verifying that a patch came from an author who has signed
> >   the CLA. There have been some suggestions that this may be possible
> >   with some sort of pre-commit verifications when committing to the
> >   master repository (or when someone with commit privileges commits to
> >   their own repository). We're still researching how this might be
> >   implemented.
> > 
> > * Submodules...
> >   For those unfamiliar with git submodules, they are roughly equivalent
> >   to svn:externals. I say "roughly", because they differ in many ways:
> >   they have to be manually initialized on each person's repository
> >   (though they can be defined in the master repository); they need to
> >   be manually updated periodically (unlike svn:externals, where anytime
> >   you do an "svn up", it also syncs the external); etc.
> > 
> >   They are quite powerful, however, and give us the ability to offer a
> >   "lean" initial checkout, allowing developers to sync in only the
> >   submodules they plan to utilize or commit to.
> > 
> >   On this note, I've fielded a number of suggestions. Some were
> >   suggesting the library directory be its own submodule, some suggested
> >   all top-level directories be their own submodule, etc. I've done some
> >   experimentation, and now propose the following structure:
> > 
> >    MAIN REPO:
> >        INSTALL.txt
> >        LICENSE.txt
> >        README.txt
> >        bin/
> >        library
> >        tests/
> >        documentation/manual/
> >            Makefile
> >            README.txt
> >            en/
> >    SUBMODULES:
> >        demos/
> >        resources/
> >        tools/
> >        documentation/manual/:
> >            all languages except "en"
> > 
> >   Now, for an explanation of the "whys" behind this. As contributors,
> >   it's important to make atomic commits: your code fix should also
> >   include a corresponding unit test, and potentially a documentation
> >   commit as well. If we split the library and tests directories out
> >   into their own submodules, we cannot do so; the code and test must be
> >   committed separately, which is (a) more work, and (b) unintuitive.
> >   The same goes for related documentation commits.
> > 
> >   Translations, on the other hand, are usually managed in a
> >   per-language capacity, flowing from English to the target language.
> >   Most developers do not need the docbook source for anything but their
> >   target language and English (the latter because it's used for
> >   fallbacks, and because it contains the build scripts). While we
> >   potentially lose the history of an "svn cp", I think this
> >   organization provides reasonable benefits.
> > 
> >   Finally, the demos, resources, and tools (the latter is a new
> >   directory) are all "opt-in" items -- if you need them, you can pull
> >   them in; if you don't, there's no reason to.
> > 
> > I'd love to get some feedback on the incomplete items. I think the
> > submodule layout I've come up with makes the most sense for contributors
> > (and based on testing, it's the cleanest and simplest way I've found to
> > accomplish most common development tasks on our tree), but am open to
> > further suggestions. If you have any ideas on handling ACLs, I'd love to
> > hear them, and sooner rather than later!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: Benjamin Eberlei <[email-masked]>, "[email-masked]"
	<[email-masked]>
Date: Sun, 26 Jul 2009 08:32:51 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: RE: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
	ZendX Proposal

Benjamin,

I am not the maintainer for Zend_Service_Amazon but I do maintain the S3 an=
d Ec2 components and I would like to state that the Ec2 and S3 classes are =
using the latest API versions. I did finish up the twitter stuff I don't ha=
ve time to maintain it as I'm busy with a full time job. I am still activel=
y developing the Ec2 classes as my full time job requires using Ec2 and S3 =
APIs.  If someone wants to take over the Twitter Service then by all means =
please do so, it does need some love.

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]
P: (317) 492-8623 - F: (317) 492-6419

-----Original Message-----
From: Benjamin Eberlei [mailto:[email-masked]]
Sent: Sunday, July 26, 2009 5:36 AM
To: [email-masked]
Subject: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to Ze=
ndX Proposal

Hello Everyone,

i took the time today to look at the Problem of Zend_Service_Amazon. Due to=
 an
API upgrade the ZF component won't work anymore come August 15th. I just sa=
w
that the component uses the API from 2005, so its hopelessly out of date. I=
'll
look into a possible fix, but i can't guarantee for this to work with the 2=
005
API and i dont know how complex a migration to the latest 2009 API is.

This out of date problem is the case with most of the other Service compone=
nts
besides Twitter, S3 and EC2. Their code-base is mostly crap and they are al=
l
unmaintained.

I want to propose a change to ZFs handling of Service components. Since the=
y
all rely on third party API (through them having to rely on the stability o=
f
external webservices) they should all be moved into ZendX for 2.0. Also eve=
ry
new service component from now on should only be included in ZendX, with th=
e
exception of service integration being programmed from companies that have =
an
agreement with Zend, such as the Infocard, Google and AMF components, where
the stability and up-to-date API can be somewhat guaranteed.

greetings,
Benjamin

--
Benjamin Eberlei
http://www.beberlei.de

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 8 Dec 2009 09:32:43 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Incubator Issue Tracker: Adding component
	for each incubator component

-- Marcus St=F6hr <[email-masked]> wrote
(on Tuesday, 08 December 2009, 01:15 PM +0100):
> at the moment, there are several components sitting in the incubator
> for development. Wouldn't it be convinient to have a category for each
> component in the issue tracker, e.g. for Zend_Oauth?

We've debated this before. My main reservation is that once the
component moves to trunk, there's no longer a way to see what issues
were resolved within incubator when looking at a component's issue list.

However, a few folks _do_ have incubator project components and are
using it to track tasks -- can some of you perhaps comment?

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Thu, 7 May 2009 01:33:04 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.8.1 code freeze 

Hi all,

ZF 1.8.1 is planned for next Tuesday (05.12).
So code freeze period will start at the end of day this Sunday (PDT
time).

Please let me know if you want to merge anything into 1.8 branch during
code freeze period.
Trunk is still free for development.

With best regards,
   Alexander Veremyev.

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 08:36:52 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Status: 22-Mar-2010 - Git organization

Greetings, all --

Based on the wiki and the poll on this list, it looks like it makes
sense to move forward with git. We're still trying to iron on some
details about how this will work, but some details are falling into
place.

First, the things we plan:

 * Git will be hosted on the ZF servers. This is so that we can have
   full control over hooks (i.e., no network latency from web hooks),
   integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
   will offer both anonymous access as well as selective writable
   access.

   Some will say, "why not just use Github?" The above does not preclude
   using github in any way; git allows you to specify multiple remotes
   from your repository. I already plan to have a mirror of my personal
   repo on github, as well as push to the ZF repo from the same
   location. This will allow people to use some of githubs powerful
   features such as pull queues while still allowing us to retain some
   control over the repository. (It also insulates us from githubs
   growing pains a bit -- I love github, but they are certainly
   suffering from rapid growth the last few months!)

 * We plan to have a read-only subversion mirror of the git repository.
   This will allow those using svn:externals to continue to do so, as
   well as allow folks more familiar with svn to continue to provide
   patches.

Next, things we're still researching:

 * How to handle contributions. Since we require a signed CLA, we need
   some way of verifying that a patch came from an author who has signed
   the CLA. There have been some suggestions that this may be possible
   with some sort of pre-commit verifications when committing to the
   master repository (or when someone with commit privileges commits to
   their own repository). We're still researching how this might be
   implemented.

 * Submodules...
   For those unfamiliar with git submodules, they are roughly equivalent
   to svn:externals. I say "roughly", because they differ in many ways:
   they have to be manually initialized on each person's repository
   (though they can be defined in the master repository); they need to
   be manually updated periodically (unlike svn:externals, where anytime
   you do an "svn up", it also syncs the external); etc.

   They are quite powerful, however, and give us the ability to offer a
   "lean" initial checkout, allowing developers to sync in only the
   submodules they plan to utilize or commit to.

   On this note, I've fielded a number of suggestions. Some were
   suggesting the library directory be its own submodule, some suggested
   all top-level directories be their own submodule, etc. I've done some
   experimentation, and now propose the following structure:

    MAIN REPO:
        INSTALL.txt
        LICENSE.txt
        README.txt
        bin/
        library
        tests/
        documentation/manual/
            Makefile
            README.txt
            en/
    SUBMODULES:
        demos/
        resources/
        tools/
        documentation/manual/:
            all languages except "en"

   Now, for an explanation of the "whys" behind this. As contributors,
   it's important to make atomic commits: your code fix should also
   include a corresponding unit test, and potentially a documentation
   commit as well. If we split the library and tests directories out
   into their own submodules, we cannot do so; the code and test must be
   committed separately, which is (a) more work, and (b) unintuitive.
   The same goes for related documentation commits.

   Translations, on the other hand, are usually managed in a
   per-language capacity, flowing from English to the target language.
   Most developers do not need the docbook source for anything but their
   target language and English (the latter because it's used for
   fallbacks, and because it contains the build scripts). While we
   potentially lose the history of an "svn cp", I think this
   organization provides reasonable benefits.

   Finally, the demos, resources, and tools (the latter is a new
   directory) are all "opt-in" items -- if you need them, you can pull
   them in; if you don't, there's no reason to.

I'd love to get some feedback on the incomplete items. I think the
submodule layout I've come up with makes the most sense for contributors
(and based on testing, it's the cleanest and simplest way I've found to
accomplish most common development tasks on our tree), but am open to
further suggestions. If you have any ideas on handling ACLs, I'd love to
hear them, and sooner rather than later!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 6 Apr 2009 20:01:47 +0200
From: Robin Skoglund <[email-masked]>
To: Wil Sinclair <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*

--001636c5a81c1100d20466e6b25e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <[email-masked]> wrote:
>
> NOTE: For this release, we=92d like to try something new in the feature l=
ist-
> actually acknowledging the significant contributions that y=92 all have m=
ade.
> J The format would be like this:
>
>
>
> * Zend_Application, contributed by Matthew Weier O'Phinney and Ben Scholz=
en
> ,Wil
Hi, I haven't gotten any answer on whether Zend_Navigation will be included
in the PR, but here goes:

* Zend_Navigation, contributed by Robin Skoglund

        robinsk

--001636c5a81c1100d20466e6b25e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span=
> wrote:<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid r=
gb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p>NOTE: For this r=
elease, we=92d like to try something new
in the feature list- actually acknowledging the significant contributions t=
hat
y=92 all have made. <span style=3D"font-family: Wingdings;">J</span> The fo=
rmat
would be like this:</p>

<p>=A0</p>

<p>* Zend_Application, contributed by Matthew Weier O&#39;Phinney
and Ben Scholzen</p>

<p>=A0</p><font color=3D"#888888"><p>,Wil</p>

</font></div>

</div>

</blockquote></div><p>Hi, I haven&#39;t gotten any answer on whether Zend_N=
avigation will be included in the PR, but here goes:<br></p><p>* Zend_Navig=
ation, contributed by Robin Skoglund</p><p>=A0=A0=A0=A0=A0=A0=A0 robinsk<br=
></p>

--001636c5a81c1100d20466e6b25e--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 7 Dec 2009 06:26:33 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

--0-160947504-1260195993=:37910
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,=0A=0AAs some of you are probably aware, I wrote a blog over the wee=
kend titled "Zend_Filter_StripTags: Friend, Foe, or Security Nightmare?" (h=
ttp://blog.astrumfutura.com/archives/425-Zend_Filter_StripTags-Friend,-Foe,=
-or-Security-Nightmare.html). The post was intended to expose the consequen=
ces of using the StripTags filter to clean HTML before it was directly outp=
ut in the View without the application of escaping. This is common in situa=
tions where user input is intended to allow some HTML, e.g. a comment form,=
 or where an external data source contains HTML intended for direct output,=
 e.g. RSS and Atom feeds.=0A=0AIn the post I offered three examples: a bug =
in allowing HTML, a method of injecting malformed HTML capable of impacting=
 a site's layout, and a "self-contained" XSS vector using a data URI. I cla=
rified the alarmist tone of the entry by explaining these "vulnerabilities"=
 are the result of end-user misuse of the filter, i.e. the filter largely d=
oes as it is designed to and not one iota more.=0A=0AAfter discussing this =
with others and my colleagues, I've been asked to raise this with ZF develo=
pers for immediate attention as a confirmed security vulnerability with mul=
tiple vectors based on the following:=0A=0A1. The filter allows for HTML ex=
ceptions to the filter-all default indicating it was originally designed to=
 safely filter HTML for direct output.=0A2. The Zend Framework Certificatio=
n Guide implies that the StripTags filter is an anti-XSS filter.=0A3. Misce=
llaneous websites claim the StripTags filter prevents XSS, use it in this r=
ole, or offer advice incorporating dangerous configuration variations (e.g.=
 allowed a set of attributes for ALL allowed tags) raising an expectation t=
hat it fulfils this role.=0A4. In March 2009, a bug in matching tags led to=
 the reporting of an XSS vulnerability in the StripTags filter requiring a =
new ZF version and backports confirming XSS as a developer concern in the f=
ilter.=0A5. The component appears to behave in a near-identical fashion to =
PHP's strip_tags which has an impact on the integrity of non-HTML input (e.=
g. deleting input after certain characters).=0A=0AThere are currently two r=
elated issues added to the issue tracker:=0A=0AZF-8483: http://framework.ze=
nd.com/issues/browse/ZF-8483=0AZF-8484: http://framework.zend.com/issues/br=
owse/ZF-8484=0A=0AFor myself, I was surprised by the ignorance I faced afte=
r the blog post. There have been suggestions raised about patching the filt=
er, replacing it with a reworked robust version, to the extreme of suggesti=
ng I overreacted. One individual suggested my XSS exploit was unrealistic, =
so I decided to make a point by exposing another XSS exploit coupled with a=
n obvious bug which doesn't need a fancy URI anyone can interpret as some k=
ind of minimal concern.=0A=0A$filter =3D new Zend_Filter_StripTags;=0A$filt=
er->setCommentsAllowed(true);=0A$html =3D "<!--[if gte IE 4]><SCRIPT>alert(=
'XSS');</SCRIPT><![endif]-->";=0A$out =3D $filter->filter($html);=0A=0AOutp=
ut: <!--[if gte IE 4]><SCRIPT>alert('XSS');</SCRIPT><![endif]-->=0A=0ASo mu=
ch for stripping tags... The StripTags filter does not have so much as a cu=
rsory understanding of the real world. Allowing comments allows for almost =
anything applicable to XSS on IE.=0A=0ASo I disagree with all of these folk=
. There appears to be an appreciable and real expectation that the StripTag=
s filter prevents XSS - a cursory search of Google provides examples of peo=
ple suggesting its use which indicates it is used as such. I'm also fast fo=
rming the opinion that a lot of PHP developers are clueless about XSS out t=
here (that probably shouldn't be a surprise to me) and we need to do someth=
ing about it besides wave our hands and leaving this monstrosity in the sou=
rce code intact.=0A=0AThomas Weidner has started the ball rolling by propos=
ing a Zend_Filter_Html component (http://framework.zend.com/wiki/display/ZF=
PROP/Zend_Filter_Html+-+Thomas+Weidner) which will be a wrapper around the =
HTMLPurifier 4.0 (http://www.htmlpurifier.org) library. I support this unre=
servedly since I and others have been using custom filters of this nature f=
or years.=0A=0AI would also suggest the following:=0A=0Aa) Rework the filte=
r's current four lines of documentation (http://framework.zend.com/manual/e=
n/zend.filter.set.html#zend.filter.set.striptags) to cover the component in=
 greater detail clarifying its use cases, potential for misuse, and clarify=
ing it is not XSS  or malformed HTML safe.=0Ab) Immediately deprecate in 1.=
9 branch (and remove in 2.0 - preferably 1.10 given its significance) its a=
bility to flexibly allow some HTML/comments thus preserving its only truly =
worthwhile feature - stripping ALL HTML.=0Ac) Do this ASAP.=0A=0AIt should =
be highlighted that the StripTags filter cannot be "fixed". It simply has l=
ittle capacity to prevent XSS and is based on rudimentary regular expressio=
n matching which is has absolutely no place in preventing XSS. The filter s=
imply must never ever be used in any role involving the safe filtering of H=
TML.=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ah=
ttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Representa=
tive
--0-160947504-1260195993=:37910
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Hi all,<br><br>As some of you are probably aware, I wrote a bl=
og over the weekend titled "Zend_Filter_StripTags: Friend, Foe, or Security=
 Nightmare?" (<a href=3D"http://blog.astrumfutura.com/archives/425-Zend_Fil=
ter_StripTags-Friend,-Foe,-or-Security-Nightmare.html">http://blog.astrumfu=
tura.com/archives/425-Zend_Filter_StripTags-Friend,-Foe,-or-Security-Nightm=
are.html</a>). The post was intended to expose the consequences of using th=
e StripTags filter to clean HTML before it was directly output in the View =
without the application of escaping. This is common in situations where use=
r input is intended to allow some HTML, e.g. a comment form, or where an ex=
ternal data source contains HTML intended for direct output, e.g. RSS and A=
tom feeds.<br><br>In the post I offered three examples: a bug in allowing
 HTML, a method of injecting malformed HTML capable of impacting a site's l=
ayout, and a "self-contained" XSS vector using a data URI. I clarified the =
alarmist tone of the entry by explaining these "vulnerabilities" are the re=
sult of end-user misuse of the filter, i.e. the filter largely does as it i=
s designed to and not one iota more.<br><br>After discussing this with othe=
rs and my colleagues, I've been asked to raise this with ZF developers for =
immediate attention as a confirmed security vulnerability with multiple vec=
tors based on the following:<br><br>1. The filter allows for HTML exception=
s to the filter-all default indicating it was originally designed to safely=
 filter HTML for direct output.<br>2. The Zend Framework Certification Guid=
e implies that the StripTags filter is an anti-XSS filter.<br>3. Miscellane=
ous websites claim the StripTags filter prevents XSS, use it in this role, =
or offer advice incorporating dangerous configuration variations
 (e.g. allowed a set of attributes for ALL allowed tags) raising an expecta=
tion that it fulfils this role.<br>4. In March 2009, a bug in matching tags=
 led to the reporting of an XSS vulnerability in the StripTags filter requi=
ring a new ZF version and backports confirming XSS as a developer concern i=
n the filter.<br>5. The component appears to behave in a near-identical fas=
hion to PHP's strip_tags which has an impact on the integrity of non-HTML i=
nput (e.g. deleting input after certain characters).<br><br>There are curre=
ntly two related issues added to the issue tracker:<br><br>ZF-8483: <a href=
=3D"http://framework.zend.com/issues/browse/ZF-8483">http://framework.zend.=
com/issues/browse/ZF-8483</a><br>ZF-8484: <a href=3D"http://framework.zend.=
com/issues/browse/ZF-8484">http://framework.zend.com/issues/browse/ZF-8484<=
/a><br><br>For myself, I was surprised by the ignorance I faced after the b=
log post. There have been suggestions raised about patching the filter,
 replacing it with a reworked robust version, to the extreme of suggesting =
I overreacted. One individual suggested my XSS exploit was unrealistic, so =
I decided to make a point by exposing another XSS exploit coupled with an o=
bvious bug which doesn't need a fancy URI anyone can interpret as some kind=
 of minimal concern.<br><br>$filter =3D new Zend_Filter_StripTags;<br>$filt=
er-&gt;setCommentsAllowed(true);<br>$html =3D "&lt;!--[if gte IE 4]&gt;&lt;=
SCRIPT&gt;alert('XSS');&lt;/SCRIPT&gt;&lt;![endif]--&gt;";<br>$out =3D $fil=
ter-&gt;filter($html);<br><br>Output: &lt;!--[if gte IE 4]&gt;&lt;SCRIPT&gt=
;alert('XSS');&lt;/SCRIPT&gt;&lt;![endif]--&gt;<br><br>So much for strippin=
g tags... The StripTags filter does not have so much as a cursory understan=
ding of the real world. Allowing comments allows for almost anything applic=
able to XSS on IE.<br><br>So I disagree with all of these folk. There appea=
rs to be an appreciable and real expectation that the StripTags filter
 prevents XSS - a cursory search of Google provides examples of people sugg=
esting its use which indicates it is used as such. I'm also fast forming th=
e opinion that a lot of PHP developers are clueless about XSS out there (th=
at probably shouldn't be a surprise to me) and we need to do something abou=
t it besides wave our hands and leaving this monstrosity in the source code=
 intact.<br><br><span>Thomas Weidner has started the ball rolling by propos=
ing a Zend_Filter_Html component (<a target=3D"_blank" href=3D"http://frame=
work.zend.com/wiki/display/ZFPROP/Zend_Filter_Html+-+Thomas+Weidner">http:/=
/framework.zend.com/wiki/display/ZFPROP/Zend_Filter_Html+-+Thomas+Weidner</=
a>) which will be a wrapper around the HTMLPurifier 4.0 (<a target=3D"_blan=
k" href=3D"http://www.htmlpurifier.org">http://www.htmlpurifier.org</a>) li=
brary. I support this unreservedly since I and others have been using custo=
m filters of this nature for years.</span><br><br>I would also suggest the
 following:<br><br><span>a) Rework the filter's current four lines of docum=
entation (<a target=3D"_blank" href=3D"http://framework.zend.com/manual/en/=
zend.filter.set.html#zend.filter.set.striptags">http://framework.zend.com/m=
anual/en/zend.filter.set.html#zend.filter.set.striptags</a>) to cover the c=
omponent in greater detail clarifying its use cases, potential for misuse, =
and clarifying it is not XSS&nbsp; or malformed HTML safe.</span><br>b) Imm=
ediately deprecate in 1.9 branch (and remove in 2.0 - preferably 1.10 given=
 its significance) its ability to flexibly allow some HTML/comments thus pr=
eserving its only truly worthwhile feature - stripping ALL HTML.<br>c) Do t=
his ASAP.<br><br>It should be highlighted that the StripTags filter cannot =
be "fixed". It simply has little capacity to prevent XSS and is based on ru=
dimentary regular expression matching which is has absolutely no place in p=
reventing XSS. The filter simply must never ever be used in any role
 involving the safe filtering of HTML.<br><br>Paddy<br><div>&nbsp;</div><sp=
an style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: times new r=
oman,new york,times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=
=E1draic Brady<br><br></span></font><span style=3D"font-style: italic;"><fo=
nt style=3D"font-family: times new roman,new york,times,serif;" size=3D"3">=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://blog.astrumfutura.com"=
>http://blog.astrumfutura.com</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com<=
/a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideurop=
e.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span><=
/span><div><br></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compressed/chunked=
 Mon Dec  7 03:29:14 PST 2009 -->=0A</div></body></html>
--0-160947504-1260195993=:37910--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Eric Clemmons <[email-masked]>
Date: Wed, 31 Mar 2010 15:59:36 -0500
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Plugin implementations

My understanding is that __invoke is simply the PHP 5.3 function for =
what we've been calling "direct" or whatever the function name is.

To me, it makes sense to take advantage of features that solve a problem =
that's already available in the language, then creating your own custom =
conventions second.

Does anything else change with the switch to __invoke, besides the time =
& effort to bring the unit tests up to speed?  I was under the =
impression it's a behind-the-scenes change.

On Mar 31, 2010, at 3:49 PM, Juozas wrote:

> I'm starting to question __invoke now... Are initial ideas behind this
> somewhere? =
http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures
> found this one, but it hardly explains "why?". It does say that it's
> consistent which is as consistent as filter(). You are mentioning that
> it makes it consistent between different plugins. But, I like when
> method calls are self explanatory, for example if I have:
>=20
> $anything->filter($value);
>=20
> I know that it's filtering something, or:
>=20
> $anything->render($value);
>=20
> it renders it somehow. Now basing all calls on __invoke magic method
> means that I the only thing what describes what I'm doing now, is
> variable name, and they are not always *that* good for doing this,
> especially when you try to keep them short (not $a, but
> standards-short).
>=20
> ..., and that it's simple. The more I look at this, the more I think
> that it's not simple at all. For such things as anonymous functions it
> does look ok, but for objects... Really think standard methods are
> much more straightforward.
>=20
> And lets say we go with __invoke as interface method (only). Not sure
> why, but it doesn't feel right.
>=20
> My 2 British pennies.
>=20
> --
> Juozas Kaziuk=C4=97nas ([email-masked])
> My website - JuoKaz (http://www.juokaz.com)
>=20
>=20
>=20
> On Wed, Mar 31, 2010 at 9:37 PM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
>> -- Juozas <[email-masked]> wrote
>> (on Wednesday, 31 March 2010, 08:59 PM +0100):
>>> -1 from me too.
>>>=20
>>> Looking at the interface it's absolutely not clear what are those =
two
>>> methods intended for. Interfaces should not require looking at the
>>> actual implementation to get that some methods are just for the sake
>>> of making testing easier (?) and in all implementations just provide =
a
>>> proxy.
>>=20
>> Actually, I'm not talking about the implementation being harder, but =
the
>> fact that conversion and migration takes a lot more effort, due to =
the
>> fact that more code needs to change in the unit tests. As an example, =
I
>> had the whole Filter tree migrated in just over an hour yesterday -- =
but
>> the tests took another 5-6 hours to complete, due to the number of
>> changes necessary to make them comply with the new signatures.
>>=20
>> But if it makes the implementation better, then it's worth it. I'm =
just
>> questioning whether that's the case.
>>=20
>>> Personally, I think that once you can do things in more than 1 way,
>>> it's confusing and misleading (not in all senses, but in a sense of
>>> method call). Now it *might* work if that proxy is provided by
>>> abstract class (just to make code more backwards compatible/any =
other
>>> reason), but still since we are talking about 2.0 here, I'd rather
>>> have only __invoke.
>>>=20
>>> Speaking of tests, I didn't completely get where the problem lies:
>>>=20
>>> $filter->filter($value);
>>>=20
>>> becomes:
>>>=20
>>> $filter($value);
>>>=20
>>> is this the refactoring you are mentioning?
>>=20
>> Yes -- and then a bit more.
>>=20
>> Often setUp() creates the filter:
>>=20
>>    $this->_filter =3D new SomeFilter();
>>=20
>> One problem that arises is that PHP is kind of stupid about calling
>> __invoke on object members. You'd think this would work:
>>=20
>>    $this->_filter($value);
>>=20
>> But it doesn't -- instead, PHP thinks you're calling the method
>> "_filter" on the current object, and then FATALs on you. So you have =
to
>> do this:
>>=20
>>    $filter   =3D $this->_filter;
>>    $filtered =3D $filter($value);
>>=20
>> Knowing this limitation, I can see other potential issues down the =
line
>> -- you can't simply call the object as if it were a function; you =
have
>> to think about whether you're operating on an object member or not, =
and
>> then change your methodology accordingly. I see that as a potential
>> drawback to using __invoke().
>>=20
>>> On Wed, Mar 31, 2010 at 8:38 PM, Lukas K=C3=B6ll <[email-masked]> =
wrote:
>>>> -1 from me, too - I'm totally agreeing with Renan.
>>>> Additionally I don't think design decisions should be based on how =
much work it
>>>> is to write the corresponding unit tests. Don't get me wrong, of =
course the code
>>>> must be testable. But especially for framework code I think that a =
low overhead
>>>> should be preferred against easier testability - infact framework =
code is
>>>> written (or changed) far more seldom than executed.
>>>>=20
>>>> If, however you decide to use __invoke as proxy, I would recommend =
to somehow
>>>> prevent the proxied methods (filter, validate) to be called from =
outside or at least mark them as deprecated
>>>> so client code _must_ use invoke and we could then remove the =
proxies later on if
>>>> it should be decided that the tests are rewritten.
>>>>=20
>>>> best regards
>>>>=20
>>>> Lukas K=C3=B6ll
>>>>=20
>>>>> -1
>>>>>=20
>>>>> Talking to my coworkers, a big piece of people take a little more =
time
>>>>> to understand something when there is more than one way to do what
>>>>> they want to do. I think that when we start a new project with
>>>>> unnecessary duplicated features it's not good. This usually =
happens
>>>>> after years, we should get this situations away. Obviously =
sometimes
>>>>> it's interesting we provide alternative ways to achieve a goal, =
but
>>>>> for those situations  (filter, validator...) it's not.
>>>>>=20
>>>>>>> The benefits:
>>>>>>>=20
>>>>>>> * Fewer changes necessary to existing unit tests
>>>>>=20
>>>>> time is the solution ;-)
>>>>>=20
>>>>>>> * interface method names may be more descriptive of intent
>>>>>=20
>>>>> they should pick a better name for their variables, like =
$filterFloat,
>>>>> $filterAlpha
>>>>>=20
>>>>>>> Problems:
>>>>>>>=20
>>>>>>> * Using __invoke() introduces overhead -- 2 method calls instead =
of one
>>>>>>> * Redundancy (two methods doing the same thing)
>>>>>=20
>>>>> that's my point! this extra way is not relevant, this one adds no =
new feature
>>>>>=20
>>>>>>> * A few extra tests to write (to ensure __invoke works as =
expecte)
>>>>>=20
>>>>> my 1 cent ;-)
>>>>>=20
>>>>> --
>>>>> Renan de Lima Barbosa
>>>>> gtalk/msn: [email-masked]
>>>>> skype: renandelima
>>>>> +55 61 8166-7755
>>>>> renandelima.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 31 March 2010 11:38, Dennis Winter =
<[email-masked]> wrote:
>>>>>> +1 on this! It's ok to have two methods for the same thing! And =
the benefit
>>>>>> of clearer interfaces is overwhelming the disadvantages!
>>>>>> Just my 2 cents!
>>>>>>=20
>>>>>> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney =
<[email-masked]>:
>>>>>>=20
>>>>>>> Greetings, all --
>>>>>>>=20
>>>>>>> Per the roadmap, one change we're planning on making is making =
plugin
>>>>>>> usage consistent across components: plugins will implement =
__invoke(),
>>>>>>> which makes them inherently callable.
>>>>>>>=20
>>>>>>> In our refactoring branch, I've done this now with Zend_Filter. =
However,
>>>>>>> it required a ton of refactoring on the unit tests (had to =
either call
>>>>>>> __invoke() directly, or $filter($value)), and it got me to =
thinking:
>>>>>>>=20
>>>>>>> Would it make sense to keep the original interfaces (filter, =
isValid,
>>>>>>> render, etc.), but also implement __invoke() -- having it proxy =
to the
>>>>>>> appropriate interface method?
>>>>>>>=20
>>>>>>> As an example:
>>>>>>>=20
>>>>>>>   interface Filter
>>>>>>>   {
>>>>>>>       public function filter($value);
>>>>>>>       public function __invoke($value);
>>>>>>>   }
>>>>>>>=20
>>>>>>>   class Digits implements Filter
>>>>>>>   {
>>>>>>>       public function filter($value)
>>>>>>>       {
>>>>>>>           // ... logic...
>>>>>>>       }
>>>>>>>=20
>>>>>>>       public function __invoke($value)
>>>>>>>       {
>>>>>>>           return $this->filter($value);
>>>>>>>       }
>>>>>>>   }
>>>>>>>=20
>>>>>>> The benefits:
>>>>>>>=20
>>>>>>> * Fewer changes necessary to existing unit tests
>>>>>>> * interface method names may be more descriptive of intent
>>>>>>>=20
>>>>>>> Problems:
>>>>>>>=20
>>>>>>> * Using __invoke() introduces overhead -- 2 method calls instead =
of one
>>>>>>> * Redundancy (two methods doing the same thing)
>>>>>>> * A few extra tests to write (to ensure __invoke works as =
expecte)
>>>>>>>=20
>>>>>>> After discussion with Ralph and Alex, I'm leaning towards having
>>>>>>> __invoke() as an _additional_ method, instead of replacing =
existing
>>>>>>> methods.
>>>>>>>=20
>>>>>>> Any thoughts or comments?
>>>>>>>=20
>>>>>>> --
>>>>>>> Matthew Weier O'Phinney
>>>>>>> Project Lead            | [email-masked]
>>>>>>> Zend Framework          | http://framework.zend.com/
>>>>>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>> --
>> Matthew Weier O'Phinney
>> Project Lead            | [email-masked]
>> Zend Framework          | http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>=20

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 29 Sep 2009 17:18:31 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Google Wave Invites

-- Graham Anderson <[email-masked]> wrote
(on Tuesday, 29 September 2009, 06:17 PM +0200):
> The first wave (pardon the pun) of mass invites for Google Wave are going out 
> tomorrow, people with existing accounts and new invitees will be allocated 8 
> additional invites.
> 
> If you don't already have a wave account and have *not* signed up to get one, 
> I'll send out my 8 invites in on a first come first served basis on this list.

I'd love to play with it a bit. My gmail account is 'mweierophinney'.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 17 Apr 2009 15:28:36 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Code Freeze starts Monday

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Friday, 17 April 2009, 10:41 AM -0400):
> If you have components that you have completed in incubator and want
> reviewed for inclusion, please get them in before then. Please be aware
> that if the component test coverage or documentation are deemed
> incomplete or unsatisfactory at that time, they will *NOT* be included
> in the final 1.8 release. 

Also, once you have contributions ready for review, please post to this
list. :)

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 31 Jul 2009 12:23:49 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Freeze lifted on all branches

The commit freeze is now lifted on all branches! Start fixing issues and
merging them to the 1.9 release branch as necessary. :)

Thanks, everyone!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Fri, 15 Jan 2010 01:20:13 +0100
To: Marc Bennewitz <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] 1.10 has been branched!

Gratz all!

Jira tells us there's (only?) a 149 issues to fix (
http://framework.zend.com/issues/browse/ZF#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
(494 + 40 - 385 = 149)), how about closing all of them? :D

-- Freeaqingme

On Fri, Jan 15, 2010 at 12:32 AM, Marc Bennewitz
<[email-masked]> wrote:
> oh sorry - forget this - i see it is already done
> my mistake
>
> Am 15.01.2010 00:27, schrieb Marc Bennewitz:
>> Great :)
>>
>> Can you add the new components of 1.10 on issue tracker and move the
>> incubator components to Zend Framework project please.
>>
>> Greetings
>> Marc B.
>>
>> Am 14.01.2010 22:55, schrieb Matthew Weier O'Phinney:
>>
>>> Greetings, all!
>>>
>>> I've just created the official 1.10 branch, and will be tagging the beta
>>> off of this branch momentarily.
>>>
>>> >From this point forward, no API changes are allowed in the release-1.10
>>> branch -- but DO please assist in fixing bugs, translating, etc.!
>>>
>>> Thanks!
>>>
>>>
>>>
>

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 7 Dec 2009 10:46:19 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

-- P=E1draic Brady <[email-masked]> wrote
(on Monday, 07 December 2009, 06:26 AM -0800):
> As some of you are probably aware, I wrote a blog over the weekend titl=
ed
> "Zend_Filter_StripTags: Friend, Foe, or Security Nightmare?" (http://
> blog.astrumfutura.com/archives/
> 425-Zend_Filter_StripTags-Friend,-Foe,-or-Security-Nightmare.html). The=
 post
> was intended to expose the consequences of using the StripTags filter t=
o clean
> HTML before it was directly output in the View without the application =
of
> escaping. This is common in situations where user input is intended to =
allow
> some HTML, e.g. a comment form, or where an external data source contai=
ns HTML
> intended for direct output, e.g. RSS and Atom feeds.

Paddy --

A few things. First, strip_tags and ZF's StripTags should _not_ be
equated with XSS protection. The fact that people do indicates to me a
documentation and education problem, not necessarily a bona-fide
security issue -- which would mean that the code _introduces_ a security
issue.

I do want to clarify something: the issue reported earlier this year was
not so much about filtering XSS attacks, but about the fact that due to h=
ow
attributes were matched, it _introduced_ an XSS attack vector. Because
the regex did not take into account newlines, it was possible to break
an attribute value onto multiple lines to prevent it being matched --
which provided the attack vector, as attributes not in the whitelist
would be retained in the final filtered tag.=20

This is very different from what you describe in your post and this
email. These are principally XSS vectors _within_ the attribute values
themselves -- i.e., the code is behaving as intended, and not
introducing _new_ attack vectors through mishandling. Quite simply,
StripTags was never designed to strip XSS vectors in the first place.=20

I do see your point regarding the "setCommentsAllowed" functionality; it
is, quite simply, a bad idea, as there is no semantic or structural
value to keeping comments; sure, you could use them for conditional
output, but that's a system ripe for abuse. I'm not entirely sure why
this functionality was added in the first place, and agree with you that
it should be removed.

So, with these points made, I'd like to ask how we should proceed? I
think it's a bit alarmist to state that the filter should be immediately
deprecated and removed ASAP. It does exactly as advertised -- and its
documentation mentions nothing about protection from XSS.

May I suggest the following:

 * ZF-8483 and ZF-8484 should be resolved ASAP

 * As part of ZF-8484, which calls for better documenting the use cases
   for StripTags, include a <warning> section clearly stating that it is
   not intended for XSS prevention

 * Create an HtmlPurifier filter that proxies to PEAR's HTML_Purifier
   package; this would be included in an upcoming release.

 * Remove the setCommentsAllowed() functionality (by having it throw an
   exception indicating the security vulnerabilities it opens)

Finally, a request: in the future, when reporting suspected security
vulnerabilities, it's customary to notify the project _privately_ and
allow some time for the project to address the vulnerability before
making it public. As it is, you've created a very large, public
discussion that will make the project seem (a) reactionary, instead of
proactive, and (b) paint us as completely non-security minded. This is
particularly bad in this situation, as, unless there's more to report,
the primary issue here is one of documentation and education, not actual
vulnerabilities in the code (with the exception of setCommentsAllowed()
-- which isn't a vulnerability per-se, but an ill-guided idea from the
outset).

> In the post I offered three examples: a bug in allowing HTML, a method =
of
> injecting malformed HTML capable of impacting a site's layout, and a
> "self-contained" XSS vector using a data URI. I clarified the alarmist =
tone of
> the entry by explaining these "vulnerabilities" are the result of end-u=
ser
> misuse of the filter, i.e. the filter largely does as it is designed to=
 and not
> one iota more.
>=20
> After discussing this with others and my colleagues, I've been asked to=
 raise
> this with ZF developers for immediate attention as a confirmed security
> vulnerability with multiple vectors based on the following:
>=20
> 1. The filter allows for HTML exceptions to the filter-all default indi=
cating
> it was originally designed to safely filter HTML for direct output.
> 2. The Zend Framework Certification Guide implies that the StripTags fi=
lter is
> an anti-XSS filter.
> 3. Miscellaneous websites claim the StripTags filter prevents XSS, use =
it in
> this role, or offer advice incorporating dangerous configuration variat=
ions
> (e.g. allowed a set of attributes for ALL allowed tags) raising an expe=
ctation
> that it fulfils this role.
> 4. In March 2009, a bug in matching tags led to the reporting of an XSS
> vulnerability in the StripTags filter requiring a new ZF version and ba=
ckports
> confirming XSS as a developer concern in the filter.
> 5. The component appears to behave in a near-identical fashion to PHP's
> strip_tags which has an impact on the integrity of non-HTML input (e.g.
> deleting input after certain characters).
>=20
> There are currently two related issues added to the issue tracker:
>=20
> ZF-8483: http://framework.zend.com/issues/browse/ZF-8483
> ZF-8484: http://framework.zend.com/issues/browse/ZF-8484
>=20
> For myself, I was surprised by the ignorance I faced after the blog pos=
t. There
> have been suggestions raised about patching the filter, replacing it wi=
th a
> reworked robust version, to the extreme of suggesting I overreacted. On=
e
> individual suggested my XSS exploit was unrealistic, so I decided to ma=
ke a
> point by exposing another XSS exploit coupled with an obvious bug which=
 doesn't
> need a fancy URI anyone can interpret as some kind of minimal concern.
>=20
> $filter =3D new Zend_Filter_StripTags;
> $filter->setCommentsAllowed(true);
> $html =3D "<!--[if gte IE 4]><SCRIPT>alert('XSS');</SCRIPT><![endif]-->=
";
> $out =3D $filter->filter($html);
>=20
> Output: <!--[if gte IE 4]><SCRIPT>alert('XSS');</SCRIPT><![endif]-->
>=20
> So much for stripping tags... The StripTags filter does not have so muc=
h as a
> cursory understanding of the real world. Allowing comments allows for a=
lmost
> anything applicable to XSS on IE.
>=20
> So I disagree with all of these folk. There appears to be an appreciabl=
e and
> real expectation that the StripTags filter prevents XSS - a cursory sea=
rch of
> Google provides examples of people suggesting its use which indicates i=
t is
> used as such. I'm also fast forming the opinion that a lot of PHP devel=
opers
> are clueless about XSS out there (that probably shouldn't be a surprise=
 to me)
> and we need to do something about it besides wave our hands and leaving=
 this
> monstrosity in the source code intact.
>=20
> Thomas Weidner has started the ball rolling by proposing a Zend_Filter_=
Html
> component (http://framework.zend.com/wiki/display/ZFPROP/
> Zend_Filter_Html+-+Thomas+Weidner) which will be a wrapper around the
> HTMLPurifier 4.0 (http://www.htmlpurifier.org) library. I support this
> unreservedly since I and others have been using custom filters of this =
nature
> for years.
>=20
> I would also suggest the following:
>=20
> a) Rework the filter's current four lines of documentation (http://
> framework.zend.com/manual/en/zend.filter.set.html#zend.filter.set.strip=
tags) to
> cover the component in greater detail clarifying its use cases, potenti=
al for
> misuse, and clarifying it is not XSS  or malformed HTML safe.
> b) Immediately deprecate in 1.9 branch (and remove in 2.0 - preferably =
1.10
> given its significance) its ability to flexibly allow some HTML/comment=
s thus
> preserving its only truly worthwhile feature - stripping ALL HTML.
> c) Do this ASAP.
>=20
> It should be highlighted that the StripTags filter cannot be "fixed". I=
t simply
> has little capacity to prevent XSS and is based on rudimentary regular
> expression matching which is has absolutely no place in preventing XSS.=
 The
> filter simply must never ever be used in any role involving the safe fi=
ltering
> of HTML.
>=20
> Paddy
> =20
> P draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 14:38:29 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

-- Ryan Albertson <[email-masked]> wrote
(on Thursday, 25 February 2010, 02:20 PM -0500):
> Another consideration of mine would be if Doctrine is used, would ZF use yaml
> like symfony does for the generation of schemas and model classes by making
> Zend_Tool work with yaml like the symfony CLI?

One consideration I have for 2.0 is to do a YAML backend for
Zend_Config, which would consume sfYaml. This would allow you to do what
you're suggesting, while simultaneously using the same configuration
file(s) with your ZF application.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 15:45:30 -0800 (PST)
From: =?utf-8?B?UMOhZHJhaWMgQnJhZHk=?= <[email-masked]>
To: Dolf Schimmel <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

--0-1456929370-1267141530=:25714
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I suppose just to make two points (I am pro-git but they need consideration=
).=0A=0A>> Tooling across platforms is not as mature or robust=0A>Who needs=
 =0Aanything else than /usr/bin/git? Obviously should the=0A>Atlassian tool=
s should support git as well, but I guess they do these=0A>days.=0A=0AOrigi=
nal comment was referring to Windows. The tools are heavily Linux centric a=
nd I'm sure many of us are more than comfortable doing things the Linux way=
. I know I rarely, if ever, leave the command line except to switch to my e=
ditor or browser ;). Is everyone though? On Windows, the story is less kind=
 and the tools somewhat cumbersome. On the other hand, for SVN, the Windows=
 tooling is very mature, easy to use, and integrates right in alongside pre=
tty much everything.=0A=0APaddy=0A=0A P=C3=A1draic Brady=0A=0Ahttp://blog.a=
strumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundati=
on Irish Representative=0A=0A=0A=0A=0A=0A________________________________=
=0AFrom: Dolf Schimmel <[email-masked]>=0ATo: Graham Anderson <grah=
[email-masked]>=0ACc: [email-masked]=0ASent: Thu, Fe=
bruary 25, 2010 11:20:26 PM=0ASubject: Re: [zf-contributors] Git vs SVN. Wa=
s: ZF 2.0 development begins!=0A=0AI guess I'll have to confess I've been c=
onvinced ZF should use GIT,=0Anot only because other major projects like Zy=
m use it (:wink:), but=0Aalso because it seems to bring quite a lot of adva=
ntages, while hardly=0Abringing any disadvantages.=0A=0AThe cons (from the =
wiki):=0A> Tracking CLAs becomes more difficult. Currently with SVN, we onl=
y grant access to those who have signed a CLA; if anybody can fork, we now =
need some way to verify CLA status before pulling patches.=0AAfter all ther=
e's always someone who's committing to the 'main'=0A(master?) repository. Y=
ou can always track who makes those 'main'=0Acommits? The person committing=
 to the main repos should then keep=0Atrack of=0Aeverybody contributing to =
a certain commit has signed a CLA (as is=0Adone now when a patch is applied=
). There should however be a clear and=0Auptodate list of everybody who sig=
ned a CLA (that's more than a=0Aselectbox in jira...).=0A=0A=0A> No good sv=
n:externals equivalent=0AWe could just commit a checkout of Dojo (and possi=
bly Dcotrine) into=0Athe ZF repository, making it read-only by anybody who'=
s not a release=0Amanager. For people who use svn for their own projects, t=
here should=0Abe an svn mirror for people to use for their svn:externals. I=
f Zend=0Acan't provide such mirror I (my company) would be happy to do so.=
=0A=0A> Tooling across platforms is not as mature or robust=0AWho needs any=
thing else than /usr/bin/git? Obviously should the=0AAtlassian tools should=
 support git as well, but I guess they do these=0Adays.=0A=0A> Would potent=
ially require (re-)training contributors=0AI have never worked with git mys=
elf, but how difficult can the basics=0Abe? git clone, git pull, git status=
, git add, git commit -a should be=0Athings any contributor can understand =
(right?). Instead of actively=0Atrain them, I'd be a fan of putting a link =
to=0Ahttp://git.or.cz/course/svn.html in the topic of #zftalk.dev on=0Afree=
node (and the wiki etc...).=0A=0A=0A--Freeaqingme=0A=0AP.s. For all of thos=
e not following me, I indeed had a different=0Aopinion on this a few days a=
go...=0A=0AOn Thu, Feb 25, 2010 at 11:53 PM, Graham Anderson=0A<graham.ande=
[email-masked]> wrote:=0A> On Thursday 25 February 2010 21:48:57 Matthew We=
ier O'Phinney wrote:=0A>>The release master can=0A>>track multiple repos fr=
om multiple collaborators, and then selectively=0A>>merge into their own "m=
aster" -- and push those patches into the=0A>>mainline.=0A>=0A> For the ben=
efit of those who don't currently use Git one other powerful aspect=0A> of =
this collaborative work-flow is being able to cherry pick commits.=0A>=0A> =
In this situation you may have multiple branches, some of them may or may n=
ot=0A> track other developers remote branches. Rather than merge the whole =
branch=0A> from HEAD to 6 commits previously, you see that only one of the =
commits has=0A> the changeset you need. Git cherry-pick allows you to merge=
 a single commit.=0A>=0A> This, and being able to merge at will from multip=
le remote branches is the=0A> kind of functionality I believe makes Git mor=
e suitable than SVN for what we=0A> do.=0A>=0A> There's more, much more. On=
e of the key differences between Git and SVN, and=0A> this is extremely imp=
ortant, is that Git tracks the _content_ of your files=0A> whereas SVN trac=
ks the files themselves. Git really doesn't care that there=0A> are 10 or 2=
0 or 1,000 files, it only cares about the content and it only cares=0A> how=
 the content changes.=0A>=0A> Here's an example, since Layout.php has been =
in the codebase for a while I=0A> wanted to see who was responsible for las=
t editing it. So i looked at the=0A> source and decided to lookup the metho=
d setMvcSuccessfulActionOnly(). It's on=0A> line number 483-487.=0A>=0A>   =
 git blame -L 483,487 Layout.php=0A>=0A> I'll trim the output and ommit the=
 actual code which is appended to the end of=0A> the following lines but yo=
u can see the detailed info that is available.=0A>=0A> b1b8f48b incubator/l=
ibrary/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000=0A> 483)=0A> b1b8f4=
8b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000=0A> 4=
84)=0A> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:=
21 +0000=0A> 485)=0A> b1b8f48b incubator/library/Zend/Layout.php (ralph 200=
7-11-16 15:40:21 +0000=0A> 486)=0A> b1b8f48b incubator/library/Zend/Layout.=
php (ralph 2007-11-16 15:40:21 +0000=0A> 487)=0A>=0A> So in less than a qua=
rter of a second I can search the whole commit history of=0A> the main ZF r=
epo and see who was responsible for last editing any line of any=0A> file. =
There's lots more gems like this that let you unleash the power of Git=0A> =
if you want to look below the surface.=0A>=0A> The surface is a good place =
to be as well, let me offer a common work-flow=0A> situation with git using=
 every day commands.=0A>=0A> git checkout -b foobar=0A> edit foo/bar.php=0A=
> ... hack hack hack ...=0A> *ring ring* oops emergency fix needed=0A> git =
stash=0A> git checkout master=0A> edit emergency/fix.php=0A> git commit -am=
 "Commit fix!"=0A> git checkout foobar=0A> git stash pop=0A> ... hack hack =
hack ...=0A> git checkout master=0A> git merge foobar=0A> *glug glug glug* =
cold beers while your colleagues are still fighting SVN.=0A>=0A> The story =
above is: Create and move into feature branch "foobar". Start=0A> hacking o=
n the feature. Boss calls, X is broken!, stash your changes and=0A> quickly=
 switch to master(trunk). Fix broken things, commit them, switch back=0A> t=
o foobar branch. Pop your changes from the stash into your working set,=0A>=
 continue hacking. Switch to master(trunk) and merge your new feature Fooba=
r.=0A> Profit!=0A>=0A> --=0A> =E2=80=9CWhat can be asserted without proof c=
an be dismissed without proof.=E2=80=9D=0A> - Christopher Hitchens=0A>=0A
--0-1456929370-1267141530=:25714
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">I suppose just to make two points (I am pro-git but they need =
consideration).<br><br>&gt;&gt; Tooling across platforms is not as mature o=
r robust<br>&gt;Who needs =0Aanything else than /usr/bin/git? Obviously sho=
uld the<br>&gt;Atlassian tools=0A should support git as well, but I guess t=
hey do these<br>&gt;days.<br><br>Original comment was referring to Windows.=
 The tools are heavily Linux centric and I'm sure many of us are more than =
comfortable doing things the Linux way. I know I rarely, if ever, leave the=
 command line except to switch to my editor or browser ;). Is everyone thou=
gh? On Windows, the story is less kind and the tools somewhat cumbersome. O=
n the other hand, for SVN, the Windows tooling is very mature, easy to use,=
 and integrates right in alongside pretty much everything.<br><br>Paddy<br>=
<div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font=
-family: times new roman,new york,times,serif;" size=3D"3"><span style=3D"f=
ont-weight: bold;">P=C3=A1draic Brady<br><br></span></font><span style=3D"f=
ont-style: italic;"><font style=3D"font-family: times new roman,new york,ti=
mes,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: tahoma,new york,times,serif; font-size: 8pt;"><font =
face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font-weight: bo=
ld;">From:</span></b> Dolf Schimmel &lt;[email-masked]&gt;<br><b><s=
pan style=3D"font-weight: bold;">To:</span></b> Graham Anderson &lt;graham.=
[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">Cc:</span><=
/b> [email-masked]<br><b><span style=3D"font-weight: bold;"=
>Sent:</span></b> Thu, February 25, 2010 11:20:26 PM<br><b><span style=3D"f=
ont-weight:
 bold;">Subject:</span></b> Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 d=
evelopment begins!<br></font><br>=0AI guess I'll have to confess I've been =
convinced ZF should use GIT,<br>not only because other major projects like =
Zym use it (:wink:), but<br>also because it seems to bring quite a lot of a=
dvantages, while hardly<br>bringing any disadvantages.<br><br>The cons (fro=
m the wiki):<br>&gt; Tracking CLAs becomes more difficult. Currently with S=
VN, we only grant access to those who have signed a CLA; if anybody can for=
k, we now need some way to verify CLA status before pulling patches.<br>Aft=
er all there's always someone who's committing to the 'main'<br>(master?) r=
epository. You can always track who makes those 'main'<br>commits? The pers=
on committing to the main repos should then keep<br>track of<br>everybody c=
ontributing to a certain commit has signed a CLA (as is<br>done now when a =
patch is applied). There should however be a clear and<br>uptodate list of =
everybody who signed a CLA (that's more than a<br>selectbox in jira...).<br=
><br><br>&gt; No good
 svn:externals equivalent<br>We could just commit a checkout of Dojo (and p=
ossibly Dcotrine) into<br>the ZF repository, making it read-only by anybody=
 who's not a release<br>manager. For people who use svn for their own proje=
cts, there should<br>be an svn mirror for people to use for their svn:exter=
nals. If Zend<br>can't provide such mirror I (my company) would be happy to=
 do so.<br><br>&gt; Tooling across platforms is not as mature or robust<br>=
Who needs anything else than /usr/bin/git? Obviously should the<br>Atlassia=
n tools should support git as well, but I guess they do these<br>days.<br><=
br>&gt; Would potentially require (re-)training contributors<br>I have neve=
r worked with git myself, but how difficult can the basics<br>be? git clone=
, git pull, git status, git add, git commit -a should be<br>things any cont=
ributor can understand (right?). Instead of actively<br>train them, I'd be =
a fan of putting a link to<br><span><a target=3D"_blank"
 href=3D"http://git.or.cz/course/svn.html">http://git.or.cz/course/svn.html=
</a> in the topic of #zftalk.dev on</span><br>freenode (and the wiki etc...=
).<br><br><br>--Freeaqingme<br><br>P.s. For all of those not following me, =
I indeed had a different<br>opinion on this a few days ago...<br><br>On Thu=
, Feb 25, 2010 at 11:53 PM, Graham Anderson<br>&lt;<a ymailto=3D"mailto:gra=
[email-masked]" href=3D"mailto:[email-masked]">graham.an=
[email-masked]</a>&gt; wrote:<br>&gt; On Thursday 25 February 2010 21:48:=
57 Matthew Weier O'Phinney wrote:<br>&gt;&gt;The release master can<br>&gt;=
&gt;track multiple repos from multiple collaborators, and then selectively<=
br>&gt;&gt;merge into their own "master" -- and push those patches into the=
<br>&gt;&gt;mainline.<br>&gt;<br>&gt; For the benefit of those who don't cu=
rrently use Git one other powerful aspect<br>&gt; of this collaborative wor=
k-flow is being able to cherry pick commits.<br>&gt;<br>&gt; In this
 situation you may have multiple branches, some of them may or may not<br>&=
gt; track other developers remote branches. Rather than merge the whole bra=
nch<br>&gt; from HEAD to 6 commits previously, you see that only one of the=
 commits has<br>&gt; the changeset you need. Git cherry-pick allows you to =
merge a single commit.<br>&gt;<br>&gt; This, and being able to merge at wil=
l from multiple remote branches is the<br>&gt; kind of functionality I beli=
eve makes Git more suitable than SVN for what we<br>&gt; do.<br>&gt;<br>&gt=
; There's more, much more. One of the key differences between Git and SVN, =
and<br>&gt; this is extremely important, is that Git tracks the _content_ o=
f your files<br>&gt; whereas SVN tracks the files themselves. Git really do=
esn't care that there<br>&gt; are 10 or 20 or 1,000 files, it only cares ab=
out the content and it only cares<br>&gt; how the content changes.<br>&gt;<=
br>&gt; Here's an example, since Layout.php has been in the codebase
 for a while I<br>&gt; wanted to see who was responsible for last editing i=
t. So i looked at the<br>&gt; source and decided to lookup the method setMv=
cSuccessfulActionOnly(). It's on<br>&gt; line number 483-487.<br>&gt;<br>&g=
t; &nbsp; &nbsp;git blame -L 483,487 Layout.php<br>&gt;<br>&gt; I'll trim t=
he output and ommit the actual code which is appended to the end of<br>&gt;=
 the following lines but you can see the detailed info that is available.<b=
r>&gt;<br>&gt; b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16=
 15:40:21 +0000<br>&gt; 483)<br>&gt; b1b8f48b incubator/library/Zend/Layout=
.php (ralph 2007-11-16 15:40:21 +0000<br>&gt; 484)<br>&gt; b1b8f48b incubat=
or/library/Zend/Layout.php (ralph 2007-11-16 15:40:21 +0000<br>&gt; 485)<br=
>&gt; b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21=
 +0000<br>&gt; 486)<br>&gt; b1b8f48b incubator/library/Zend/Layout.php (ral=
ph 2007-11-16 15:40:21 +0000<br>&gt; 487)<br>&gt;<br>&gt; So in less
 than a quarter of a second I can search the whole commit history of<br>&gt=
; the main ZF repo and see who was responsible for last editing any line of=
 any<br>&gt; file. There's lots more gems like this that let you unleash th=
e power of Git<br>&gt; if you want to look below the surface.<br>&gt;<br>&g=
t; The surface is a good place to be as well, let me offer a common work-fl=
ow<br>&gt; situation with git using every day commands.<br>&gt;<br>&gt; git=
 checkout -b foobar<br>&gt; edit foo/bar.php<br>&gt; ... hack hack hack ...=
<br>&gt; *ring ring* oops emergency fix needed<br>&gt; git stash<br>&gt; gi=
t checkout master<br>&gt; edit emergency/fix.php<br>&gt; git commit -am "Co=
mmit fix!"<br>&gt; git checkout foobar<br>&gt; git stash pop<br>&gt; ... ha=
ck hack hack ...<br>&gt; git checkout master<br>&gt; git merge foobar<br>&g=
t; *glug glug glug* cold beers while your colleagues are still fighting SVN=
.<br>&gt;<br>&gt; The story above is: Create and move into feature
 branch "foobar". Start<br>&gt; hacking on the feature. Boss calls, X is br=
oken!, stash your changes and<br>&gt; quickly switch to master(trunk). Fix =
broken things, commit them, switch back<br>&gt; to foobar branch. Pop your =
changes from the stash into your working set,<br>&gt; continue hacking. Swi=
tch to master(trunk) and merge your new feature Foobar.<br>&gt; Profit!<br>=
&gt;<br>&gt; --<br>&gt; =E2=80=9CWhat can be asserted without proof can be =
dismissed without proof.=E2=80=9D<br>&gt; - Christopher Hitchens<br>&gt;<br=
></div></div>=0A</div></body></html>
--0-1456929370-1267141530=:25714--

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 6 Oct 2009 07:36:05 -0500
From: Juan Felipe Alvarez Saldarriaga <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] PDF, DOCX and DOC Generation with Zend 
	Framework

Great news!, thanks.

On Tue, Oct 6, 2009 at 7:34 AM, Jonathan Maron
<[email-masked]> wrote:
> Hello all
>
> I have just posted an article about the soon to be released
> Zend_Service_LiveDocx_* components.
>
> http://www.phplivedocx.org/articles/pdf-generation-with-zend-framework/
>
> The components are scheduled for ZF 1.10. For the time being, you can
> check them out of the Standard Incubator (http://is.gd/40hXz).
>
> Comments and critique are welcome.
>
> Very best regards
>
> Jonathan Maron
>

nFrom nobody Wed Apr  7 08:46:13 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 21:49:54 +0100
From: Juozas <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

I'm starting to question __invoke now... Are initial ideas behind this
somewhere? http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectur=
es
found this one, but it hardly explains "why?". It does say that it's
consistent which is as consistent as filter(). You are mentioning that
it makes it consistent between different plugins. But, I like when
method calls are self explanatory, for example if I have:

$anything->filter($value);

I know that it's filtering something, or:

$anything->render($value);

it renders it somehow. Now basing all calls on __invoke magic method
means that I the only thing what describes what I'm doing now, is
variable name, and they are not always *that* good for doing this,
especially when you try to keep them short (not $a, but
standards-short).

..., and that it's simple. The more I look at this, the more I think
that it's not simple at all. For such things as anonymous functions it
does look ok, but for objects... Really think standard methods are
much more straightforward.

And lets say we go with __invoke as interface method (only). Not sure
why, but it doesn't feel right.

My 2 British pennies.

--
Juozas Kaziuk=C4=97nas ([email-masked])
My website - JuoKaz (http://www.juokaz.com)

On Wed, Mar 31, 2010 at 9:37 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Juozas <[email-masked]> wrote
> (on Wednesday, 31 March 2010, 08:59 PM +0100):
>> -1 from me too.
>>
>> Looking at the interface it's absolutely not clear what are those two
>> methods intended for. Interfaces should not require looking at the
>> actual implementation to get that some methods are just for the sake
>> of making testing easier (?) and in all implementations just provide a
>> proxy.
>
> Actually, I'm not talking about the implementation being harder, but the
> fact that conversion and migration takes a lot more effort, due to the
> fact that more code needs to change in the unit tests. As an example, I
> had the whole Filter tree migrated in just over an hour yesterday -- but
> the tests took another 5-6 hours to complete, due to the number of
> changes necessary to make them comply with the new signatures.
>
> But if it makes the implementation better, then it's worth it. I'm just
> questioning whether that's the case.
>
>> Personally, I think that once you can do things in more than 1 way,
>> it's confusing and misleading (not in all senses, but in a sense of
>> method call). Now it *might* work if that proxy is provided by
>> abstract class (just to make code more backwards compatible/any other
>> reason), but still since we are talking about 2.0 here, I'd rather
>> have only __invoke.
>>
>> Speaking of tests, I didn't completely get where the problem lies:
>>
>> $filter->filter($value);
>>
>> becomes:
>>
>> $filter($value);
>>
>> is this the refactoring you are mentioning?
>
> Yes -- and then a bit more.
>
> Often setUp() creates the filter:
>
> =C2=A0 =C2=A0$this->_filter =3D new SomeFilter();
>
> One problem that arises is that PHP is kind of stupid about calling
> __invoke on object members. You'd think this would work:
>
> =C2=A0 =C2=A0$this->_filter($value);
>
> But it doesn't -- instead, PHP thinks you're calling the method
> "_filter" on the current object, and then FATALs on you. So you have to
> do this:
>
> =C2=A0 =C2=A0$filter =C2=A0 =3D $this->_filter;
> =C2=A0 =C2=A0$filtered =3D $filter($value);
>
> Knowing this limitation, I can see other potential issues down the line
> -- you can't simply call the object as if it were a function; you have
> to think about whether you're operating on an object member or not, and
> then change your methodology accordingly. I see that as a potential
> drawback to using __invoke().
>
>> On Wed, Mar 31, 2010 at 8:38 PM, Lukas K=C3=B6ll <[email-masked]> wro=
te:
>> > -1 from me, too - I'm totally agreeing with Renan.
>> > Additionally I don't think design decisions should be based on how muc=
h work it
>> > is to write the corresponding unit tests. Don't get me wrong, of cours=
e the code
>> > must be testable. But especially for framework code I think that a low=
 overhead
>> > should be preferred against easier testability - infact framework code=
 is
>> > written (or changed) far more seldom than executed.
>> >
>> > If, however you decide to use __invoke as proxy, I would recommend to =
somehow
>> > prevent the proxied methods (filter, validate) to be called from outsi=
de or at least mark them as deprecated
>> > so client code _must_ use invoke and we could then remove the proxies =
later on if
>> > it should be decided that the tests are rewritten.
>> >
>> > best regards
>> >
>> > Lukas K=C3=B6ll
>> >
>> >> -1
>> >>
>> >> Talking to my coworkers, a big piece of people take a little more tim=
e
>> >> to understand something when there is more than one way to do what
>> >> they want to do. I think that when we start a new project with
>> >> unnecessary duplicated features it's not good. This usually happens
>> >> after years, we should get this situations away. Obviously sometimes
>> >> it's interesting we provide alternative ways to achieve a goal, but
>> >> for those situations =C2=A0(filter, validator...) it's not.
>> >>
>> >>>> The benefits:
>> >>>>
>> >>>> * Fewer changes necessary to existing unit tests
>> >>
>> >> time is the solution ;-)
>> >>
>> >>>> * interface method names may be more descriptive of intent
>> >>
>> >> they should pick a better name for their variables, like $filterFloat=
,
>> >> $filterAlpha
>> >>
>> >>>> Problems:
>> >>>>
>> >>>> * Using __invoke() introduces overhead -- 2 method calls instead of=
 one
>> >>>> * Redundancy (two methods doing the same thing)
>> >>
>> >> that's my point! this extra way is not relevant, this one adds no new=
 feature
>> >>
>> >>>> * A few extra tests to write (to ensure __invoke works as expecte)
>> >>
>> >> my 1 cent ;-)
>> >>
>> >> --
>> >> Renan de Lima Barbosa
>> >> gtalk/msn: [email-masked]
>> >> skype: renandelima
>> >> +55 61 8166-7755
>> >> renandelima.com
>> >>
>> >>
>> >>
>> >> On 31 March 2010 11:38, Dennis Winter <[email-masked]=
m> wrote:
>> >>> +1 on this! It's ok to have two methods for the same thing! And the =
benefit
>> >>> of clearer interfaces is overwhelming the disadvantages!
>> >>> Just my 2 cents!
>> >>>
>> >>> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney <matthew@zend=
.com>:
>> >>>
>> >>>> Greetings, all --
>> >>>>
>> >>>> Per the roadmap, one change we're planning on making is making plug=
in
>> >>>> usage consistent across components: plugins will implement __invoke=
(),
>> >>>> which makes them inherently callable.
>> >>>>
>> >>>> In our refactoring branch, I've done this now with Zend_Filter. How=
ever,
>> >>>> it required a ton of refactoring on the unit tests (had to either c=
all
>> >>>> __invoke() directly, or $filter($value)), and it got me to thinking=
:
>> >>>>
>> >>>> Would it make sense to keep the original interfaces (filter, isVali=
d,
>> >>>> render, etc.), but also implement __invoke() -- having it proxy to =
the
>> >>>> appropriate interface method?
>> >>>>
>> >>>> As an example:
>> >>>>
>> >>>> =C2=A0 interface Filter
>> >>>> =C2=A0 {
>> >>>> =C2=A0 =C2=A0 =C2=A0 public function filter($value);
>> >>>> =C2=A0 =C2=A0 =C2=A0 public function __invoke($value);
>> >>>> =C2=A0 }
>> >>>>
>> >>>> =C2=A0 class Digits implements Filter
>> >>>> =C2=A0 {
>> >>>> =C2=A0 =C2=A0 =C2=A0 public function filter($value)
>> >>>> =C2=A0 =C2=A0 =C2=A0 {
>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... logic...
>> >>>> =C2=A0 =C2=A0 =C2=A0 }
>> >>>>
>> >>>> =C2=A0 =C2=A0 =C2=A0 public function __invoke($value)
>> >>>> =C2=A0 =C2=A0 =C2=A0 {
>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return $this->filter($value);
>> >>>> =C2=A0 =C2=A0 =C2=A0 }
>> >>>> =C2=A0 }
>> >>>>
>> >>>> The benefits:
>> >>>>
>> >>>> * Fewer changes necessary to existing unit tests
>> >>>> * interface method names may be more descriptive of intent
>> >>>>
>> >>>> Problems:
>> >>>>
>> >>>> * Using __invoke() introduces overhead -- 2 method calls instead of=
 one
>> >>>> * Redundancy (two methods doing the same thing)
>> >>>> * A few extra tests to write (to ensure __invoke works as expecte)
>> >>>>
>> >>>> After discussion with Ralph and Alex, I'm leaning towards having
>> >>>> __invoke() as an _additional_ method, instead of replacing existing
>> >>>> methods.
>> >>>>
>> >>>> Any thoughts or comments?
>> >>>>
>> >>>> --
>> >>>> Matthew Weier O'Phinney
>> >>>> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| matthew@zen=
d.com
>> >>>> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework=
.zend.com/
>> >>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>> >>>
>> >
>> >
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 5 Dec 2009 04:25:31 -0800 (PST)
From: =?utf-8?B?UMOhZHJhaWMgQnJhZHk=?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework modularity and application
	structure

--0-112325626-1260015931=:19359
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

My own apps are largely divided across sub-apps in the form of modules. Pla=
ying into this I've composed a collection of dependency modules which act a=
s supporting reusable packages of libs, forms, models and associated contro=
llers. The challenge has been reuse obviously but also how to cleanly integ=
rate and configure these in the context of the main app.=0A=0A=0ASome of th=
e solutions aren't rocket science so it would be great to see support added=
. I started a proposal for module "configurators" as an example to impose m=
odule (not global) specific configuration but there is lots more needed for=
 a complete solution.=0A=0AOne often overlooked part of the puzzle is that =
the concept of a module is really loose and the default assumptions of the =
framework hold little utility in RL. Zend_App ignored this rather blatantly=
 (it wasn't intentional) leaving us with the current weird setup of overrid=
ing module associated configs that are actually applied globally. Besides b=
eing almost pointless this is really confusing.=0A=0AA clearer definition o=
f modules, which I guess is the point of this thread in essence ;), will he=
lp pave the path. Looking forward to that table!=0A=0APaddy=0A=0A=0AOn 5 De=
c 2009, at 03:58, Juozas <[email-masked]> wrote:=0A=0A=0AHello everyone,=
=0A>=0A>=0A>as you know, Zend Framework 2.0 is having a major rewrite in so=
me parts and a lot things can be arranged to make development easier/more f=
lexible/etc.=0A>=0A>=0A>After discussing this with Matthew, I'm asking you =
to:=0A>=0A>=0A>Write in short, how do you use Zend Framework=0A>=0A>=0A>Wha=
t interests us is how you work with modules (blog, products, news, users), =
how you divide your applications in to parts (admin, public, something else=
) and how other parts of code (acl, configuration, resources) comes into pl=
ay here. =0A>=0A>=0A>The reason why I'm asking this, is because I'm using Z=
end Framework for quote big applications and for me it's important to have =
ability to create application with self-contained modules and sub-applicati=
ons. For example I have e-commerce products having admin, public and suppli=
er sub-applications, but everything is still nicely divided into modules (p=
roducts, warehouse, orders, customers etc.) and App_Application and FrontCo=
ntroller plugins does some work to make one application code to be divided =
in these parts. =0A>=0A>=0A>However, I know that some people use applicatio=
ns completely based on acl - there is one site and only depending on what y=
our permissions are, you see data, can edit or delete if you want to. Here =
again somewhat different structure comes into play. Also quite popular thin=
g to do is to have admin/default modules. Even though I completely don't un=
derstand this approach, some people like it and use everyday, hence it shou=
ld also be possible to use. =0A>=0A>=0A>So please write what you think abou=
t such things, I will try to read them all, generalize into a comparison ta=
ble and make it into a proposal of what functions from core are needed to s=
upport it (without any hacking, which I done quite a lot)=0A>=0A>--=0A>Juoz=
as Kaziuk=C4=97nas ([email-masked])=0A>A=C5=A1 internete - JuoKaz (http:=
//www.juokaz.com)=0A>
--0-112325626-1260015931=:19359
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">My own apps are largely divided across sub-apps in the form of=
 modules. Playing into this I've composed a collection of dependency module=
s which act as supporting reusable packages of libs, forms, models and asso=
ciated controllers. The challenge has been reuse obviously but also how to =
cleanly integrate and configure these in the context of the main app.<div s=
tyle=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;=
"><div style=3D"font-family: times new roman,new york,times,serif; font-siz=
e: 12pt;"><div><br></div><div>Some of the solutions aren't rocket science s=
o it would be great to see support added. I started a proposal for module "=
configurators" as an example to impose module (not global) specific configu=
ration but there is lots more needed for a complete
 solution.</div><div><br></div><div>One often overlooked part of the puzzle=
 is that the concept of a module is really loose and the default assumption=
s of the framework hold little utility in RL. Zend_App ignored this rather =
blatantly (it wasn't intentional) leaving us with the current weird setup o=
f=0A overriding module associated configs that are actually applied globall=
y. Besides being almost pointless this is really confusing.</div><div><br><=
/div><div>A clearer definition of modules, which I guess is the point of th=
is thread in essence ;), will help pave the path. Looking forward to that t=
able!</div><div><br></div><div>Paddy</div><div><br></div><div><br>On 5 Dec =
2009, at 03:58, Juozas &lt;<a rel=3D"nofollow" ymailto=3D"mailto:juozas@juo=
kaz.com" target=3D"_blank" href=3D"mailto:[email-masked]">juozas@juokaz.=
com</a>&gt; wrote:<br><br></div><div></div><blockquote type=3D"cite"><div>H=
ello everyone,<div><br></div><div>as you know, Zend Framework 2.0 is having=
 a major rewrite in some parts and a lot things can be arranged to make dev=
elopment easier/more flexible/etc.</div><div><br></div><div>After discussin=
g this with Matthew, I'm asking you to:</div>=0A<div><br></div><div><b>Writ=
e in short, how do you use Zend Framework</b></div><div><b><br></b></div><d=
iv>What&nbsp;interests us is how you work with modules (blog, products, new=
s, users), how you divide your applications in to parts (admin, public, som=
ething else)&nbsp;and how other parts of code (acl, configuration, resource=
s) comes into play here.&nbsp;</div>=0A<div><br></div><div>The reason why I=
'm asking this, is because I'm using Zend Framework for quote big applicati=
ons and for me it's important to have ability to create application with se=
lf-contained modules and sub-applications. For example I have e-commerce pr=
oducts having admin, public and supplier sub-applications, but everything i=
s still nicely divided into modules (products, warehouse, orders, customers=
 etc.) and App_Application and FrontController plugins does some work to ma=
ke one application code to be divided in these parts.&nbsp;</div>=0A<div><b=
r></div><div>However, I know that some people use applications completely b=
ased on acl - there is one site and only depending on what your permissions=
 are, you see data, can edit or delete if you want to. Here again somewhat =
different structure comes into play.&nbsp;Also quite popular thing to do is=
 to have admin/default modules. Even though I completely don't understand t=
his approach, some people like it and use everyday, hence it should also be=
 possible to use.&nbsp;</div>=0A<div><br></div><div>So please write what yo=
u think about such things, I will try to read them all, generalize into a c=
omparison table and make it into a proposal of what functions from core are=
 needed to support it (without any hacking, which I done quite a lot)</div>=
=0A<div><br clear=3D"all">--<br>Juozas Kaziuk=C4=97nas (<a rel=3D"nofollow"=
 ymailto=3D"mailto:[email-masked]" target=3D"_blank" href=3D"mailto:juoz=
[email-masked]"></a><a rel=3D"nofollow" ymailto=3D"mailto:[email-masked]"=
 target=3D"_blank" href=3D"mailto:[email-masked]">[email-masked]</a>)=
<br>A=C5=A1 internete - JuoKaz (<a rel=3D"nofollow" target=3D"_blank" href=
=3D"http://www.juokaz.com">http://www.juokaz.com</a>)<br>=0A</div>=0A</div>=
</blockquote><meta http-equiv=3D"x-dns-prefetch-control" content=3D"on"></d=
iv></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compressed/chunked Fri Dec  4 =
03:01:48 PST 2009 -->=0A</div></body></html>
--0-112325626-1260015931=:19359--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 15:35:00 -0700
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming 
	Conventions

--001636c924579ff15c04673af90e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I think Ben and I are saying similar things.  Zend\View\PhpCore and
Zend\View\PhpEngine seem a bit awkward.  Surely it would be easier and more
apparent to say:
Zend_View_Interface => zend\view\IEngine
Zend_View_Abstract => zend\view\Engine
Zend_View => zend\view\engine\Standard

Where "Standard" could also be "Native" or "PHP" (but was chosen to mimic
the dispatcher).

View this as a compromise between your suggested solution and the "I"
notation for interfaces.  A single "I" is not much in the way of Hungarian
notation and every experienced developer will be familiar with the meaning.
I think this will solve a lot of naming dilemmas easily in advance, as
well--like Interface and Abstract do currently.

-Matt

On Fri, Apr 10, 2009 at 1:38 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> -- Matthew Ratzloff <[email-masked]> wrote
> (on Friday, 10 April 2009, 01:08 PM -0700):
> > "This decision is basically already made..."
> >
> > Before I weigh in, I'd first like to suggest that this is perhaps a poor
> > approach to this sort of thing.  It's like bringing in a job candidate
> and
> > saying, "He's basically already hired, but feel free to interview him."
>
> Heh -- I actually did this intentionally in part to stimulate the
> debate. Nothing like something inflammatory to get people to start
> commenting. :)
>
> > That said, I have no real preference, but one consideration that I didn't
> see
> > in the latter solution was how to go about naming if there is both an
> interface
> > and an abstract class.  For example, Zend_View_Interface and
> > Zend_View_Abstract.  I'm guessing the abstract will probably change to
> > something like Zend_View_Engine or Zend_View_Adapter, but what about the
> > interface?
>
> It will depend in large part on the implementation. In the case of
> Zend_View, it will likely actually be the following:
>
>  * Zend_View_Interface -> Zend\View\Engine (the interface references
>    "getEngine()", which makes this appropriate
>
>  * Zend_View_Abstract -> Zend\View\PhpCore (because this is the core
>    functionality for a concrete PHP view implementation)
>
> ...and that leads to your next point, as we need to address Zend_View...
>
> > Also, how would you go about renaming classes in a situation where you
> have a
> > "root" class and an abstract class?  For example, Zend_Session extends
> > Zend_Session_Abstract.
>
> Zend_View would likely become Zend\View\PhpEngine, as it's a view
> engine that utilizes PHP. But the basic idea is that it now moves
> underneath the Zend\View namespace -- and that's what will happen to
> other components as well.
>
> We'll have to discuss these on a case by case instance. As more are
> moved over, we'll likely get some emerging idioms to draw upon.
>
>
> > On Fri, Apr 10, 2009 at 11:24 AM, Matthew Weier O'Phinney <
> [email-masked]>
> > wrote:
> >
> >     Greetings, all --
> >
> >     Below is a proposal I am making to modify the Zend Framework Coding
> >     Standards conventions for the naming of Interfaces and Abstract
> classes.
> >
> >     This decision is basically already made, but I'd appreciate any
> feedback
> >     that you may have on the matter.
> >
> >     Thanks!
> >
> >     The problem
> >     ===========
> >     PHP 5.3 introduces namespaces to the PHP language. While this won't
> have an
> >     impact much on userland code, it will have an impact on library and
> >     framework
> >     code, as it provides a useful paradigm for organizing components as
> well as
> >     simplifying syntax. Instead of having to say things like:
> >
> >        $analyzer = new
> Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> >
> >     we can instead do something like this:
> >
> >        namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >        $analyzer = new Common_TextNum();
> >
> >     or even:
> >
> >        namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >        class Common_TextNum extends Common
> >        {
> >        }
> >
> >     The problem that arises for Zend Framework has to do with how we name
> >     abstract
> >     classes and interfaces. Currently, the final segment of such classes
> are
> >     expected to end with _Abstract and _Interface, respectively. This
> will not
> >     work
> >     when we migrate to utilize namespaces, for two reasons.
> >
> >     First, and most obviously, 'abstract' and 'interface' are reserved
> PHP
> >     keywords.
> >     As such, in situations such as the following:
> >
> >        namespace Zend\Controller\Request;
> >
> >        class Abstract
> >        {
> >        }
> >
> >        // or:
> >
> >        namespace Zend\Controller\Dispatcher;
> >
> >        interface Interface
> >        {
> >        }
> >
> >     we'll run into issues.
> >
> >     Second, and less obvious, is that perhaps the easiest solution breaks
> one
> >     of the
> >     key principles of namespaces (which are designed to help encapsulate
> >     components). This one's harder to explain, so let's look at examples.
> >     Consider a
> >     component such as Zend_Controller_Request. The simplest solution
> would be
> >     to
> >     name the abstract class or interface Zend\Controller\Request, and
> then have
> >     the
> >     various concrete implementations under that namespace:
> >
> >        namespace Zend\Controller;
> >
> >        interface Request
> >        {
> >        }
> >
> >        // and concrete ones:
> >
> >        namespace Zend\Controller\Request;
> >
> >        class Http
> >        {
> >        }
> >
> >     What's the problem here? The interface is not in the same namespace
> as the
> >     concrete implementations.
> >
> >     Potential solutions and recommendation
> >     ======================================
> >     So, how should Zend Framework "solve" these issues? A number of
> proposals
> >     and
> >     recommendations have been floated around, both within ZF circles and
> in the
> >     greater PHP community.
> >
> >     Considerations include:
> >
> >      * Avoiding the use of PHP reserved keywords (already noted).
> >      * Avoiding Hungarian Notation (i.e., having the name or a portion of
> the
> >     name
> >       describe its type -- which, to a degree, the current naming
> conventions
> >       already violate). (See
> http://en.wikipedia.org/wiki/Hungarian_Notation,
> >     the
> >       sections "Disadvantages of Systems Hungarian" and "Notable
> Opinions" for
> >     some
> >       of the arguments against using Hungarian Notation.)
> >
> >     Approaches that have been considered include:
> >
> >      * Using 'I' to prefix interfaces. This derives from standards in
> other
> >       programming languages (.Net and python, in particular). This is
> just
> >     another
> >       form of Hungarian Notation, however.
> >
> >      * Using "Interface" or "Abstract" as a class name suffix:
> >     RequestInterface,
> >       RequestAbstract. Again, however this is Hungarian Notation.
> >
> >      * Using the term "Base" for abstract classes: BaseRequest,
> RequestBase,
> >     Base.
> >       This is just substituting the word Base for Abstract, however, and
> is
> >     really
> >       not much different than the above.
> >
> >      * Use generic, descriptive names indicative of functionality or
> behavior.
> >     As
> >       examples from the SPL, "Countable", "Iterator", "ArrayObject".
> >
> >     My recommendation is to use the latter, as it solves all
> considerations. It
> >     will
> >     take more thought when naming, but will ensure that components can
> live in
> >     a
> >     self-contained namespace, do not use reserved keywords, and avoid
> Hungarian
> >     Notation.
> >
> >     Plan for implementation
> >     =======================
> >     I recommend that the Coding Standards documentation be updated to
> reflect
> >     this
> >     approach.
> >
> >     All new components going into 1.8 and onwards should adopt these
> standards.
> >     In
> >     releases 1.9 and forward, we will begin migrating existing
> interfaces/
> >     abstract
> >     classe. First, new classes/interfaces will be created that follow
> these
> >     conventions and which extend the originals; later, any type-hinting
> based
> >     on the
> >     original class/interface names will be updated to point to the new
> names;
> >     and
> >     finally, in 2.0, we will remove the old interfaces/abstract classes
> >     entirely.
> >
> >     --
> >     Matthew Weier O'Phinney
> >     Software Architect      | [email-masked]
> >     Zend Framework          | http://framework.zend.com/
> >
> >
>
> --
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--001636c924579ff15c04673af90e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think Ben and I are saying similar things. =C2=A0Zend\View\PhpCore and Ze=
nd\View\PhpEngine seem a bit awkward. =C2=A0Surely it would be easier and m=
ore apparent to say:<div><br></div><div>Zend_View_Interface =3D&gt; zend\vi=
ew\IEngine</div>
<div>Zend_View_Abstract =3D&gt; zend\view\Engine</div><div>Zend_View =3D&gt=
; zend\view\engine\Standard</div><div><br></div><div>Where &quot;Standard&q=
uot; could also be &quot;Native&quot; or &quot;PHP&quot; (but was chosen to=
 mimic the dispatcher).</div>
<div><br></div><div>View this as a compromise between your suggested soluti=
on and the &quot;I&quot; notation for interfaces. =C2=A0A single &quot;I&qu=
ot; is not much in the way of Hungarian notation and every experienced deve=
loper will be familiar with the meaning. I think this will solve a lot of n=
aming dilemmas easily in advance, as well--like Interface and Abstract do c=
urrently.</div>
<div><br></div><div>-Matt</div><div><br><div class=3D"gmail_quote">On Fri, =
Apr 10, 2009 at 1:38 PM, Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;=
<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">-- Matthew Ratzloff &lt;<a href=3D"mailto:m=
[email-masked]">[email-masked]</a>&gt; wrote<br>
(on Friday, 10 April 2009, 01:08 PM -0700):<br>
<div class=3D"im">&gt; &quot;This decision is basically already made...&quo=
t;<br>
&gt;<br>
&gt; Before I weigh in, I&#39;d=C2=A0first=C2=A0like to suggest that this i=
s perhaps a poor<br>
&gt; approach to this sort of thing. =C2=A0It&#39;s like bringing in a job =
candidate and<br>
&gt; saying, &quot;He&#39;s basically already hired, but feel free to inter=
view him.&quot;<br>
<br>
</div>Heh -- I actually did this intentionally in part to stimulate the<br>
debate. Nothing like something inflammatory to get people to start<br>
commenting. :)<br>
<div class=3D"im"><br>
&gt; That said, I have no real preference, but one consideration that I did=
n&#39;t see<br>
&gt; in the latter solution was how to go about naming if there is both an =
interface<br>
&gt; and an abstract class. =C2=A0For example, Zend_View_Interface and<br>
&gt; Zend_View_Abstract. =C2=A0I&#39;m guessing the abstract will probably =
change to<br>
&gt; something like Zend_View_Engine or Zend_View_Adapter, but what about t=
he<br>
&gt; interface?<br>
<br>
</div>It will depend in large part on the implementation. In the case of<br=
Zend_View, it will likely actually be the following:<br>
<br>
 =C2=A0* Zend_View_Interface -&gt; Zend\View\Engine (the interface referenc=
es<br>
 =C2=A0 =C2=A0&quot;getEngine()&quot;, which makes this appropriate<br>
<br>
 =C2=A0* Zend_View_Abstract -&gt; Zend\View\PhpCore (because this is the co=
re<br>
 =C2=A0 =C2=A0functionality for a concrete PHP view implementation)<br>
<br>
...and that leads to your next point, as we need to address Zend_View...<br=
<div class=3D"im"><br>
&gt; Also, how would you go about renaming classes in a situation where you=
 have a<br>
&gt; &quot;root&quot; class and an abstract class? =C2=A0For example, Zend_=
Session extends<br>
&gt; Zend_Session_Abstract.<br>
<br>
</div>Zend_View would likely become Zend\View\PhpEngine, as it&#39;s a view=
<br>
engine that utilizes PHP. But the basic idea is that it now moves<br>
underneath the Zend\View namespace -- and that&#39;s what will happen to<br=
other components as well.<br>
<br>
We&#39;ll have to discuss these on a case by case instance. As more are<br>
moved over, we&#39;ll likely get some emerging idioms to draw upon.<br>
<div><div></div><div class=3D"h5"><br>
<br>
&gt; On Fri, Apr 10, 2009 at 11:24 AM, Matthew Weier O&#39;Phinney &lt;<a h=
ref=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Greetings, all --<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Below is a proposal I am making to modify the Zend Frame=
work Coding<br>
&gt; =C2=A0 =C2=A0 Standards conventions for the naming of Interfaces and A=
bstract classes.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 This decision is basically already made, but I&#39;d app=
reciate any feedback<br>
&gt; =C2=A0 =C2=A0 that you may have on the matter.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Thanks!<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The problem<br>
&gt; =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; =C2=A0 =C2=A0 PHP 5.3 introduces namespaces to the PHP language. While=
 this won&#39;t have an<br>
&gt; =C2=A0 =C2=A0 impact much on userland code, it will have an impact on =
library and<br>
&gt; =C2=A0 =C2=A0 framework<br>
&gt; =C2=A0 =C2=A0 code, as it provides a useful paradigm for organizing co=
mponents as well as<br>
&gt; =C2=A0 =C2=A0 simplifying syntax. Instead of having to say things like=
:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0$analyzer =3D new Zend_Search_Lucene_Analys=
is_Analyzer_Common_TextNum();<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 we can instead do something like this:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0namespace Zend\Search\Lucene\Analysis\Analy=
zer;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0$analyzer =3D new Common_TextNum();<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 or even:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0namespace Zend\Search\Lucene\Analysis\Analy=
zer;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0class Common_TextNum extends Common<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The problem that arises for Zend Framework has to do wit=
h how we name<br>
&gt; =C2=A0 =C2=A0 abstract<br>
&gt; =C2=A0 =C2=A0 classes and interfaces. Currently, the final segment of =
such classes are<br>
&gt; =C2=A0 =C2=A0 expected to end with _Abstract and _Interface, respectiv=
ely. This will not<br>
&gt; =C2=A0 =C2=A0 work<br>
&gt; =C2=A0 =C2=A0 when we migrate to utilize namespaces, for two reasons.<=
br>
&gt;<br>
&gt; =C2=A0 =C2=A0 First, and most obviously, &#39;abstract&#39; and &#39;i=
nterface&#39; are reserved PHP<br>
&gt; =C2=A0 =C2=A0 keywords.<br>
&gt; =C2=A0 =C2=A0 As such, in situations such as the following:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0namespace Zend\Controller\Request;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0class Abstract<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0// or:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0namespace Zend\Controller\Dispatcher;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0interface Interface<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 we&#39;ll run into issues.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Second, and less obvious, is that perhaps the easiest so=
lution breaks one<br>
&gt; =C2=A0 =C2=A0 of the<br>
&gt; =C2=A0 =C2=A0 key principles of namespaces (which are designed to help=
 encapsulate<br>
&gt; =C2=A0 =C2=A0 components). This one&#39;s harder to explain, so let&#3=
9;s look at examples.<br>
&gt; =C2=A0 =C2=A0 Consider a<br>
&gt; =C2=A0 =C2=A0 component such as Zend_Controller_Request. The simplest =
solution would be<br>
&gt; =C2=A0 =C2=A0 to<br>
&gt; =C2=A0 =C2=A0 name the abstract class or interface Zend\Controller\Req=
uest, and then have<br>
&gt; =C2=A0 =C2=A0 the<br>
&gt; =C2=A0 =C2=A0 various concrete implementations under that namespace:<b=
r>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0namespace Zend\Controller;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0interface Request<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0// and concrete ones:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0namespace Zend\Controller\Request;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0class Http<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 What&#39;s the problem here? The interface is not in the=
 same namespace as the<br>
&gt; =C2=A0 =C2=A0 concrete implementations.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Potential solutions and recommendation<br>
&gt; =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; =C2=A0 =C2=A0 So, how should Zend Framework &quot;solve&quot; these is=
sues? A number of proposals<br>
&gt; =C2=A0 =C2=A0 and<br>
&gt; =C2=A0 =C2=A0 recommendations have been floated around, both within ZF=
 circles and in the<br>
&gt; =C2=A0 =C2=A0 greater PHP community.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Considerations include:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0* Avoiding the use of PHP reserved keywords (alrea=
dy noted).<br>
&gt; =C2=A0 =C2=A0 =C2=A0* Avoiding Hungarian Notation (i.e., having the na=
me or a portion of the<br>
&gt; =C2=A0 =C2=A0 name<br>
&gt; =C2=A0 =C2=A0 =C2=A0 describe its type -- which, to a degree, the curr=
ent naming conventions<br>
&gt; =C2=A0 =C2=A0 =C2=A0 already violate). (See <a href=3D"http://en.wikip=
edia.org/wiki/Hungarian_Notation" target=3D"_blank">http://en.wikipedia.org=
/wiki/Hungarian_Notation</a>,<br>
&gt; =C2=A0 =C2=A0 the<br>
&gt; =C2=A0 =C2=A0 =C2=A0 sections &quot;Disadvantages of Systems Hungarian=
&quot; and &quot;Notable Opinions&quot; for<br>
&gt; =C2=A0 =C2=A0 some<br>
&gt; =C2=A0 =C2=A0 =C2=A0 of the arguments against using Hungarian Notation=
.)<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Approaches that have been considered include:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0* Using &#39;I&#39; to prefix interfaces. This der=
ives from standards in other<br>
&gt; =C2=A0 =C2=A0 =C2=A0 programming languages (.Net and python, in partic=
ular). This is just<br>
&gt; =C2=A0 =C2=A0 another<br>
&gt; =C2=A0 =C2=A0 =C2=A0 form of Hungarian Notation, however.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0* Using &quot;Interface&quot; or &quot;Abstract&qu=
ot; as a class name suffix:<br>
&gt; =C2=A0 =C2=A0 RequestInterface,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 RequestAbstract. Again, however this is Hungarian=
 Notation.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0* Using the term &quot;Base&quot; for abstract cla=
sses: BaseRequest, RequestBase,<br>
&gt; =C2=A0 =C2=A0 Base.<br>
&gt; =C2=A0 =C2=A0 =C2=A0 This is just substituting the word Base for Abstr=
act, however, and is<br>
&gt; =C2=A0 =C2=A0 really<br>
&gt; =C2=A0 =C2=A0 =C2=A0 not much different than the above.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0* Use generic, descriptive names indicative of fun=
ctionality or behavior.<br>
&gt; =C2=A0 =C2=A0 As<br>
&gt; =C2=A0 =C2=A0 =C2=A0 examples from the SPL, &quot;Countable&quot;, &qu=
ot;Iterator&quot;, &quot;ArrayObject&quot;.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 My recommendation is to use the latter, as it solves all=
 considerations. It<br>
&gt; =C2=A0 =C2=A0 will<br>
&gt; =C2=A0 =C2=A0 take more thought when naming, but will ensure that comp=
onents can live in<br>
&gt; =C2=A0 =C2=A0 a<br>
&gt; =C2=A0 =C2=A0 self-contained namespace, do not use reserved keywords, =
and avoid Hungarian<br>
&gt; =C2=A0 =C2=A0 Notation.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Plan for implementation<br>
&gt; =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<br>
&gt; =C2=A0 =C2=A0 I recommend that the Coding Standards documentation be u=
pdated to reflect<br>
&gt; =C2=A0 =C2=A0 this<br>
&gt; =C2=A0 =C2=A0 approach.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 All new components going into 1.8 and onwards should ado=
pt these standards.<br>
&gt; =C2=A0 =C2=A0 In<br>
&gt; =C2=A0 =C2=A0 releases 1.9 and forward, we will begin migrating existi=
ng interfaces/<br>
&gt; =C2=A0 =C2=A0 abstract<br>
&gt; =C2=A0 =C2=A0 classe. First, new classes/interfaces will be created th=
at follow these<br>
&gt; =C2=A0 =C2=A0 conventions and which extend the originals; later, any t=
ype-hinting based<br>
&gt; =C2=A0 =C2=A0 on the<br>
&gt; =C2=A0 =C2=A0 original class/interface names will be updated to point =
to the new names;<br>
&gt; =C2=A0 =C2=A0 and<br>
&gt; =C2=A0 =C2=A0 finally, in 2.0, we will remove the old interfaces/abstr=
act classes<br>
&gt; =C2=A0 =C2=A0 entirely.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 --<br>
&gt; =C2=A0 =C2=A0 Matthew Weier O&#39;Phinney<br>
&gt; =C2=A0 =C2=A0 Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mail=
to:[email-masked]">[email-masked]</a><br>
&gt; =C2=A0 =C2=A0 Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a hr=
ef=3D"http://framework.zend.com/" target=3D"_blank">http://framework.zend.c=
om/</a><br>
&gt;<br>
&gt;<br>
<br>
</div></div>--<br>
<div><div></div><div class=3D"h5">Matthew Weier O&#39;Phinney<br>
Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:[email-masked]=
">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
</div></div></blockquote></div><br></div>

--001636c924579ff15c04673af90e--

nFrom nobody Wed Apr  7 08:46:14 2010
Date: Mon, 27 Jul 2009 08:29:21 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
	ZendX Proposal
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>

--0-1748743313-1248708561=:49113
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Matthew,=0A=0AI'll apologise in turn for other reasons. I have a bad hab=
it at times of reacting off the cuff and my last indignant email was a prim=
e example. It should not have been sent in that form - especially not to yo=
u. You were not involved in what happened in 2007, and it was completely un=
fair to assume otherwise in my response. Shortly after that abrupt email, I=
 ended up laughing at myself and the whole thing. I even wrote up a little =
tirade on the blog making fun of the entire history of this, myself, and Ze=
nd's actions at the time. No offense to anyone at Zend - this was two years=
 ago now and other than brief relapses like yesterday, I don't harbour any =
bad feelings.=0A=0ATo put my reaction in context, it's just a sore issue fo=
r me. At the time, I released a New BSD licensed version of my code reworke=
d to use Zend components to show what I had to share and was prepared to su=
pply under the CLA. I commented on the early proposal in the wiki, reviewed=
 the existing prototype code from Zend, offered suggestions, proposed chang=
es where needed, highlighted technical issues and, I think, raised at least=
 some awareness of the OpenID edge cases to be careful with. Eventually, it=
 became clear I wasn't achieving anything. OpenID was on its fast track, an=
d it wasn't stopping for anyone.=0A=0ANow none of this is constructive, and=
 nothing here helps with the problem that components like Zend_OpenId are c=
urrently broken, or will be, or just have some small API compliance issues.=
 Unfortunately, few will tell everyone else in a timely and very public man=
ner. Most of the problems are already on the issue tracker - and that's pro=
bably what needs attention here before anything else. So, a few ideas in th=
at direction...=0A=0A1. Hold a once monthly issue clearing day. I'm sure th=
at's not original... Having at least one day (anymore may risk it losing it=
s "special" status) to raise awareness on the blogs and mailing lists that =
you need help clearing issues, how to get started, and who to call when a c=
ommit goes completely off target might achieve something. Once a month is a=
lso light enough that it remains a special event needing minimal time commi=
tments.=0A=0A2. There are a lot of issues where people have attached patche=
s, so it shouldn't be too hard to press gang some volunteers into a more or=
ganic team responsible for reviewing those specifically. Giving them a fanc=
y name like "Matthew's Elite Hit Squad" would serve as additional motivatio=
n. Failing that, tell them it's their patriotic duty (nation dependent). Or=
 park a Rentokil van outside their house at 2am.=0A=0A3. Badger the maintai=
ners. I know I suffer from the "one day soon..." attitude on anything I hav=
en't worked on recently. An email reminding them of their responsibility an=
d asking if they could get to it...like...right now; it might help. Hey, Ze=
nd_Feed_Reader moved because I was asked :). If it works on me, it's a sure=
 thing.=0A=0A4. Not sure if this exists, but it's been mentioned before so =
maybe not (Carlton Gibson), something like a help wanted board could help. =
Make it a regular mailing list email for extra exposure. It's all about awa=
reness to be honest - if people don't know and don't care, nothing will get=
 done. Somewhat related, is there a page listing the most pressing issues n=
eeding resolution? I remember something like this from some time ago.=0A=0A=
5. Direct targeting. Before a new volunteer realises their mistake, immedia=
tely slap them with several issues they just became wholly responsible for.=
 Probably works best in a mentoring situation - I know nothing about PDF fo=
r example, so if I got a Zend_Pdf issue I might skip the country. There pro=
bably should be a few people for any of these ideas to handle your voluntee=
rs' queries. and cherry picking should be allowed...to an extent.=0A=0A6. D=
ocument the entire process of resolving an issue and committing patches. A =
lot of stuff is easily fixed in theory, but when you are looking at an issu=
e in, for example, Zend_Pdf (I know little about it or PDF) you might end u=
p struggling through all that code, trying to figure out how it works, etc.=
 Anything that gives people a leg up could be worthwhile.=0A=0A7. It takes =
about 4 clicks, and some reading, before anyone can access guidance on how =
to report bugs or issues in a helpful and effective manner. It's unlike any=
one will get that far searching for something they may not be aware of. I'd=
 recommend we draft a short easy to read set of guidance on what makes a go=
od issue report and add it to the tracker and wiki so it only takes a singl=
e click to reach.=0A=0A8. Statistics lie? People get really scared when the=
y see the number of old issues. I would limit any blind assays onto the iss=
ue tracker to the most recent 12 months. How to go back even further to iss=
ues which look more and more like they will never get resolved is a hard on=
e. By now, some might not even be applicable, have too fragmented or unclea=
r of a description to be useful, and some may just need the ol' RTFM stamp =
or an immediate closure.=0A=0A9. Is there a clear policy on stepping on som=
ebody's toes? For example, if I notice a bug in Zend_Date's parsing of ISO =
8601 dates (purely fictional, Thomas!), report it, and 16 months later it's=
 still not resolved and Thomas has not been heard from despite frantic crie=
s for help for most of that time - can I commit a patch to svn? At what poi=
nt does the need to resolve an issue overtake the usual steps of harassing =
the component lead or maintainer? Probably already part of 6 though...=0A=
=0ATo back them up with actual commitment, I will volunteer for any patch r=
eviewing. I will be active on any issue days if they are implemented. I wil=
l raise my hand to fix any and all open issues concerning Zend_OpenId and Z=
end_Feed (for now) assuming their maintainers either a) agree to it or b) a=
re not currently active or don't mind either way. I won't undertake to impl=
ement new features though - personally I think the issue tracker as a forum=
 for "improvements" has only added to the flood burying the actual bug/patc=
h issues but I don't see how it could have been avoided either. You can tak=
e these as actual commitments.=0A=0AI do also understand your frustration. =
I think everyone has completely underestimated the work involved and has ta=
ken to the assumption that Zend fixes all with dozens of developers. When t=
hey see the issues grow in number and the resolution times creep up, but no=
thing obviously break apart disastrously like Zend_Controller (how much mor=
e obvious would that get) they assume the rest will get fixed...eventually.=
 Preferably before it ever impacts them. This is an unrealistic attitude an=
d we shouldn't expect three people to hold our world together when it's an =
open source project.=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.co=
m=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Repre=
sentative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Matthew=
 Weier O'Phinney <[email-masked]>=0ATo: P=E1draic Brady <padraic.brady@ya=
hoo.com>; [email-masked]=0ASent: Monday, July 27, 2009 3:00=
:43 AM=0ASubject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + S=
ervices to ZendX Proposal=0A=0A-- P=E1draic Brady <[email-masked]>=
 wrote=0A(on Sunday, 26 July 2009, 11:13 AM -0700):=0A> > Paddy, to be hone=
st, this feels like a really daft criticism. Dmitry did=0A> > do the origin=
al Zend_OpenId component, but we have blocked on YOU to do=0A> > the 2.0 su=
pport. When Dmitry started the OpenId component, I had Andi=0A> > put him i=
n touch with you so that the two of you could collaborate. At=0A> > that ti=
me, you indicated that you would assist as you could, but that=0A> > you wo=
uld spend your efforts on OAuth and Yadis support, and then help=0A> > with=
 shaping our 2.0 support. These components have remained in=0A> > basically=
 proposal stage since spring 2008.=0A> >=0A> > So, bad example; if you want=
 to see further support for the 2.0 Draft 11=0A> > specs, then please help =
us by completing what you started -- or indicate=0A> > you won't do it, so =
that somebody else can potentially step in and=0A> > complete this effort.=
=0A> =0A> Mathew, to clarify, I have zero involvement in Zend_OpenId and I'=
ve never=0A> committed to any such involvement. I've never committed so muc=
h as a line of=0A> code for it. My work on Zend_Service_Yadis and Zend_Cryp=
t were a byproduct of=0A> my own intentions in February 2007 to bring an Op=
enId proposal to the table.=0A> Once that was overtaken in June 2007 by Dmi=
try's proposal (it's no secret how I=0A> reacted to that), we had some info=
rmal discussions on collaborating but it=0A> remained an insurmountable pro=
blem that my own library was already in place=0A> after months of work - I =
simply did not have the time or the motivation to work=0A> on what amounted=
 to a second OpenId library from scratch when I already had a=0A> perfectly=
 operational one underway that I had already intended making a ZF=0A> contr=
ibution. As I said at the time (and wrote about on the blog in September=0A=
> 07), the then ZF proposal process was a thoroughly discouraging one that =
made=0A> no effort to engage with proposers in a constructive manner.=0A> =
=0A> Though I certainly would have expressed a willingness to assist with O=
penID (by=0A> email if I remember?) it would not have been an immediate pro=
ject and I would=0A> not have committed to it on the spot without submittin=
g a formal proposal for=0A> discussion. This is neither the time or place t=
o discuss what my involvement or=0A> the direction of Zend_OpenId could be,=
 but the component needs more than a few=0A> patches and it's more a task f=
or ZF 2.0 I think.=0A=0AFirst, I want to apologize for my critique. It was =
unwarranted, and very=0Alikely unjustified. I lashed out as I was frustrate=
d that this thread=0Astarted on the eve of a new release. This is the sort =
of thing that=0Ashould have been raised weeks ago, as we could have altered=
 the release=0Aschedule at that time. Brought up this late in the release c=
ycle, it=0Araises the specter of, "why are they releasing now when even the=
=0Acontributors feel the framework is shoddy?" The fact of the matter is:=
=0Athis is a very large project, and there is a *ton* to maintain. A lot of=
=0Alegacy code was not reviewed well prior to inclusion, and it's left us=
=0Awith a lot of headaches; we're also still establishing quality=0Aguideli=
nes for promotion to trunk, and this means that code going into=0Atrunk sti=
ll varies in quality. =0A=0AAre these reasons to delay release? Possibly. B=
ut raised this late in=0Athe release cycle, it's too late. What it can mean=
, however, is that we=0Awork harder towards maintaining what we do have cur=
rently for future=0Areleases.=0A=0AI also want to point out at this time th=
at the internal team has=0Acontributed very, very little to ZF 1.9.0's *fea=
tures*. This is very=0Amuch a community release -- look at all the major fe=
atures, and you'll=0Asee that the ones with most impact and most developmen=
t are, to a one,=0Acommunity driven. My team has been working almost entire=
ly on=0Amaintenance for this release -- Zend_Db and Zend_Pdf, in particular=
,=0Awere given a ton of attention in the past months, and we have also been=
=0Ataking a very close look at the test suite and cleaning up code where we=
=0Asee unit tests failing. Over all, I feel this is the most stable release=
=0Ato date -- even with the number of issues that exist in the tracker.=0A=
=0ASecond, Paddy, my apologies if I have remembered the situation=0Aincorre=
ctly, or, in fact, did not have all the information -- which is=0Aalso enti=
rely likely as at that time I was not involved full-time with=0Athe project=
. My main recollection was that, due to Dmitry's proposal=0Abeing fast-trac=
ked, but incomplete with regards to 2.0 support, you had=0Aindicated some i=
nterest in assisting with the latter after the initial=0Arelease. I never m=
eant to indicate that you are a current maintainer=0Afor Zend_OpenId -- onl=
y that in my mind, and I would argue those of a=0Anumber of others, that yo=
u were going to be the "party of interest" with=0Aregards to 2.0 support. I=
 would be absolutely thrilled if you would=0Astill be willing to contribute=
 it -- even if it means another=0A"Zend_Feed_Reader" situation where we hav=
e another parallel library that=0Aoffers more and better support.=0A=0A> As=
 for Zend_Crypt and Zend_Service_Yadis, these date back to 2007. I don't kn=
ow=0A> how long they have been in the Incubator - but aside from a few mino=
r issues in=0A> Yadis they've been sitting there waiting for whatever the n=
ext step is. =0A=0AFor the record of those reading, once a developer feels =
their=0Acontribution is complete and ready for inclusion in trunk -- and th=
is=0Ameans (a) tests covering the proposal expectations, (b) good test=0Aco=
verage, and (c) complete documentation for the component -- ping=0Asomebody=
 on the Zend team to do a review for inclusion. We will verify=0Athese poin=
ts, and either ask for further work to be done or work with=0Ayou to move t=
hem into trunk.=0A=0ASo, Paddy, does this mean you're ready for Zend_Crypt =
and=0AZend_Service_Yadis to move into trunk? :)=0A=0A> I don't have any imm=
ediate need for them - they were intended for use=0A> in Zend_OpenId whenev=
er Dmitry needed them. Yadis has been up on PEAR=0A> as a release for almos=
t as long. =0A=0ALet's discuss this after 1.9 is out the door. I'd like to =
see some=0Aresolution on OpenId support, and it would be good to get you, D=
mitry,=0Aand myself on a call or IRC chat together to determine the way for=
ward.=0A=0A> OAuth dates from mid-2008 - completely my fault it's not quite=
=0A> finished but I have told a few people since last December that they=0A=
> should not hesitate to work on it in my absence.  I just couldn't get=0A>=
 to it at the time. In any case, it's on my card right after ZFR=0A> finish=
es up with the final testing.=0A=0AIf you have, nobody has approached anybo=
dy on the team about taking over=0Athe proposal. Again, let's discuss this =
after 1.9.=0A=0A> Anyway, this is way way off topic.=0A=0AAgreed -- and I a=
pologize again for bringing it up on a public forum. I=0Aam, and remain, fr=
ustrated that the topic of bug and component=0Amaintenance was raised basic=
ally on the even of a new release, and took=0Ait out on you. I shouldn't ha=
ve.=0A=0A> My point in using that example is that it's another component th=
at is not=0A> actively maintained. I am definitely not its maintainer - and=
 I don't even use=0A> it. Just backing up Benjamin's observation. I know it=
's an unrealistic pain in=0A> the butt that Zend are expected to maintain t=
hese, but at some point either=0A> maintenance needs to be enforced =0A=0AA=
nd I think the key point here is that it needs to be a "put up, or live=0Aw=
ith having others maintain your code" policy. I actually have people=0Aregu=
larly asking if they can work on a component -- and usually put them=0Ain t=
ouch with the existing maintainer. I think at a certain point,=0Ahowever, i=
f it's clear the developer is no longer actively maintaining=0Athe code, we=
 mark it as unmaintained somewhere, and, as somebody else=0Anoted, put up a=
 "help wanted" sign for that component. The question is=0Awhere this will l=
ive, and what the policy will be regarding when a=0Acomponent is considered=
 "unmaintained".=0A=0AThat said... I know I'm not actively maintaining much=
 of the code I've=0Awritten. I hope to, soon, but with the change in roles,=
 I've had much=0Aless time for this activity. So, if you know I authored a =
component, and=0Aare interested in helping maintain it... please contact me=
. :)=0A=0A=0A-- =0AMatthew Weier O'Phinney=0AProject Lead            | matt=
[email-masked]=0AZend Framework          | http://framework.zend.com/=0A
--0-1748743313-1248708561=:49113
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Hi Matthew,<br><br>I'll apologise in turn for other reasons. I=
 have a bad habit at times of reacting off the cuff and my last indignant e=
mail was a prime example. It should not have been sent in that form - espec=
ially not to you. You were not involved in what happened in 2007, and it wa=
s completely unfair to assume otherwise in my response. Shortly after that =
abrupt email, I ended up laughing at myself and the whole thing. I even wro=
te up a little tirade on the blog making fun of the entire history of this,=
 myself, and Zend's actions at the time. No offense to anyone at Zend - thi=
s was two years ago now and other than brief relapses like yesterday, I don=
't harbour any bad feelings.<br><br>To put my reaction in context, it's jus=
t a sore issue for me. At the time, I released a New BSD licensed
 version of my code reworked to use Zend components to show what I had to s=
hare and was prepared to supply under the CLA. I commented on the early pro=
posal in the wiki, reviewed the existing prototype code from Zend, offered =
suggestions, proposed changes where needed, highlighted technical issues an=
d, I think, raised at least some awareness of the OpenID edge cases to be c=
areful with. Eventually, it became clear I wasn't achieving anything. OpenI=
D was on its fast track, and it wasn't stopping for anyone.<br><br>Now none=
 of this is constructive, and nothing here helps with the problem that comp=
onents like Zend_OpenId are currently broken, or will be, or just have some=
 small API compliance issues. Unfortunately, few will tell everyone else in=
 a timely and very public manner. Most of the problems are already on the i=
ssue tracker - and that's probably what needs attention here before anythin=
g else. So, a few ideas in that direction...<br><br>1. Hold a once
 monthly issue clearing day. I'm sure that's not original... Having at leas=
t one day (anymore may risk it losing its "special" status) to raise awaren=
ess on the blogs and mailing lists that you need help clearing issues, how =
to get started, and who to call when a commit goes completely off target mi=
ght achieve something. Once a month is also light enough that it remains a =
special event needing minimal time commitments.<br><br>2. There are a lot o=
f issues where people have attached patches, so it shouldn't be too hard to=
 press gang some volunteers into a more organic team responsible for review=
ing those specifically. Giving them a fancy name like "Matthew's Elite Hit =
Squad" would serve as additional motivation. Failing that, tell them it's t=
heir patriotic duty (nation dependent). Or park a Rentokil van outside thei=
r house at 2am.<br><br>3. Badger the maintainers. I know I suffer from the =
"one day soon..." attitude on anything I haven't worked on recently.
 An email reminding them of their responsibility and asking if they could g=
et to it...like...right now; it might help. Hey, Zend_Feed_Reader moved bec=
ause I was asked :). If it works on me, it's a sure thing.<br><br>4. Not su=
re if this exists, but it's been mentioned before so maybe not (Carlton Gib=
son), something like a help wanted board could help. Make it a regular mail=
ing list email for extra exposure. It's all about awareness to be honest - =
if people don't know and don't care, nothing will get done. Somewhat relate=
d, is there a page listing the most pressing issues needing resolution? I r=
emember something like this from some time ago.<br><br>5. Direct targeting.=
 Before a new volunteer realises their mistake, immediately slap them with =
several issues they just became wholly responsible for. Probably works best=
 in a mentoring situation - I know nothing about PDF for example, so if I g=
ot a Zend_Pdf issue I might skip the country. There probably should
 be a few people for any of these ideas to handle your volunteers' queries.=
 and cherry picking should be allowed...to an extent.<br><br>6. Document th=
e entire process of resolving an issue and committing patches. A lot of stu=
ff is easily fixed in theory, but when you are looking at an issue in, for =
example, Zend_Pdf (I know little about it or PDF) you might end up struggli=
ng through all that code, trying to figure out how it works, etc. Anything =
that gives people a leg up could be worthwhile.<br><br>7. It takes about 4 =
clicks, and some reading, before anyone can access guidance on how to repor=
t bugs or issues in a helpful and effective manner. It's unlike anyone will=
 get that far searching for something they may not be aware of. I'd recomme=
nd we draft a short easy to read set of guidance on what makes a good issue=
 report and add it to the tracker and wiki so it only takes a single click =
to reach.<br><br>8. Statistics lie? People get really scared when
 they see the number of old issues. I would limit any blind assays onto the=
 issue tracker to the most recent 12 months. How to go back even further to=
 issues which look more and more like they will never get resolved is a har=
d one. By now, some might not even be applicable, have too fragmented or un=
clear of a description to be useful, and some may just need the ol' RTFM st=
amp or an immediate closure.<br><br>9. Is there a clear policy on stepping =
on somebody's toes? For example, if I notice a bug in Zend_Date's parsing o=
f ISO 8601 dates (purely fictional, Thomas!), report it, and 16 months late=
r it's still not resolved and Thomas has not been heard from despite franti=
c cries for help for most of that time - can I commit a patch to svn? At wh=
at point does the need to resolve an issue overtake the usual steps of hara=
ssing the component lead or maintainer? Probably already part of 6 though..=
.<br><br>To back them up with actual commitment, I will volunteer
 for any patch reviewing. I will be active on any issue days if they are im=
plemented. I will raise my hand to fix any and all open issues concerning Z=
end_OpenId and Zend_Feed (for now) assuming their maintainers either a) agr=
ee to it or b) are not currently active or don't mind either way. I won't u=
ndertake to implement new features though - personally I think the issue tr=
acker as a forum for "improvements" has only added to the flood burying the=
 actual bug/patch issues but I don't see how it could have been avoided eit=
her. You can take these as actual commitments.<br><br>I do also understand =
your frustration. I think everyone has completely underestimated the work i=
nvolved and has taken to the assumption that Zend fixes all with dozens of =
developers. When they see the issues grow in number and the resolution time=
s creep up, but nothing obviously break apart disastrously like Zend_Contro=
ller (how much more obvious would that get) they assume the rest
 will get fixed...eventually. Preferably before it ever impacts them. This =
is an unrealistic attitude and we shouldn't expect three people to hold our=
 world together when it's an open source project.<br><div>&nbsp;</div><span=
 style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: times new rom=
an,new york,times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=
=E1draic Brady<br><br></span></font><span style=3D"font-style: italic;"><fo=
nt style=3D"font-family: times new roman,new york,times,serif;" size=3D"3">=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://blog.astrumfutura.com"=
>http://blog.astrumfutura.com</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com<=
/a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideurop=
e.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span><=
/span><div><br></div><div style=3D"font-family: times new roman,new york,ti=
mes,serif; font-size:
 12pt;"><br><div style=3D"font-family: arial,helvetica,sans-serif; font-siz=
e: 10pt;"><font size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><span style=3D=
"font-weight: bold;">From:</span></b> Matthew Weier O'Phinney &lt;matthew@z=
end.com&gt;<br><b><span style=3D"font-weight: bold;">To:</span></b> P=E1dra=
ic Brady &lt;[email-masked]&gt;; [email-masked]<br=
><b><span style=3D"font-weight: bold;">Sent:</span></b> Monday, July 27, 20=
09 3:00:43 AM<br><b><span style=3D"font-weight: bold;">Subject:</span></b> =
Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to ZendX P=
roposal<br></font><br>=0A-- P=E1draic Brady &lt;<a ymailto=3D"mailto:padrai=
[email-masked]" href=3D"mailto:[email-masked]">padraic.brady@ya=
hoo.com</a>&gt; wrote<br>(on Sunday, 26 July 2009, 11:13 AM -0700):<br>&gt;=
 &gt; Paddy, to be honest, this feels like a really daft criticism. Dmitry =
did<br>&gt; &gt; do the original Zend_OpenId component, but we have blocked=
 on YOU to do<br>&gt; &gt; the 2.0 support. When Dmitry started the OpenId =
component, I had Andi<br>&gt; &gt; put him in touch with you so that the tw=
o of you could collaborate. At<br>&gt; &gt; that time, you indicated that y=
ou would assist as you could, but that<br>&gt; &gt; you would spend your ef=
forts on OAuth and Yadis support, and then help<br>&gt; &gt; with shaping o=
ur 2.0 support. These components have remained in<br>&gt; &gt; basically pr=
oposal stage since spring 2008.<br>&gt; &gt;<br>&gt; &gt; So, bad example; =
if you want to see further support for the 2.0 Draft 11<br>&gt; &gt; specs,=
 then please help us by
 completing what you started -- or indicate<br>&gt; &gt; you won't do it, s=
o that somebody else can potentially step in and<br>&gt; &gt; complete this=
 effort.<br>&gt; <br>&gt; Mathew, to clarify, I have zero involvement in Ze=
nd_OpenId and I've never<br>&gt; committed to any such involvement. I've ne=
ver committed so much as a line of<br>&gt; code for it. My work on Zend_Ser=
vice_Yadis and Zend_Crypt were a byproduct of<br>&gt; my own intentions in =
February 2007 to bring an OpenId proposal to the table.<br>&gt; Once that w=
as overtaken in June 2007 by Dmitry's proposal (it's no secret how I<br>&gt=
; reacted to that), we had some informal discussions on collaborating but i=
t<br>&gt; remained an insurmountable problem that my own library was alread=
y in place<br>&gt; after months of work - I simply did not have the time or=
 the motivation to work<br>&gt; on what amounted to a second OpenId library=
 from scratch when I already had a<br>&gt; perfectly operational one
 underway that I had already intended making a ZF<br>&gt; contribution. As =
I said at the time (and wrote about on the blog in September<br>&gt; 07), t=
he then ZF proposal process was a thoroughly discouraging one that made<br>=
&gt; no effort to engage with proposers in a constructive manner.<br>&gt; <=
br>&gt; Though I certainly would have expressed a willingness to assist wit=
h OpenID (by<br>&gt; email if I remember?) it would not have been an immedi=
ate project and I would<br>&gt; not have committed to it on the spot withou=
t submitting a formal proposal for<br>&gt; discussion. This is neither the =
time or place to discuss what my involvement or<br>&gt; the direction of Ze=
nd_OpenId could be, but the component needs more than a few<br>&gt; patches=
 and it's more a task for ZF 2.0 I think.<br><br>First, I want to apologize=
 for my critique. It was unwarranted, and very<br>likely unjustified. I las=
hed out as I was frustrated that this thread<br>started on the eve
 of a new release. This is the sort of thing that<br>should have been raise=
d weeks ago, as we could have altered the release<br>schedule at that time.=
 Brought up this late in the release cycle, it<br>raises the specter of, "w=
hy are they releasing now when even the<br>contributors feel the framework =
is shoddy?" The fact of the matter is:<br>this is a very large project, and=
 there is a *ton* to maintain. A lot of<br>legacy code was not reviewed wel=
l prior to inclusion, and it's left us<br>with a lot of headaches; we're al=
so still establishing quality<br>guidelines for promotion to trunk, and thi=
s means that code going into<br>trunk still varies in quality. <br><br>Are =
these reasons to delay release? Possibly. But raised this late in<br>the re=
lease cycle, it's too late. What it can mean, however, is that we<br>work h=
arder towards maintaining what we do have currently for future<br>releases.=
<br><br>I also want to point out at this time that the internal team
 has<br>contributed very, very little to ZF 1.9.0's *features*. This is ver=
y<br>much a community release -- look at all the major features, and you'll=
<br>see that the ones with most impact and most development are, to a one,<=
br>community driven. My team has been working almost entirely on<br>mainten=
ance for this release -- Zend_Db and Zend_Pdf, in particular,<br>were given=
 a ton of attention in the past months, and we have also been<br>taking a v=
ery close look at the test suite and cleaning up code where we<br>see unit =
tests failing. Over all, I feel this is the most stable release<br>to date =
-- even with the number of issues that exist in the tracker.<br><br>Second,=
 Paddy, my apologies if I have remembered the situation<br>incorrectly, or,=
 in fact, did not have all the information -- which is<br>also entirely lik=
ely as at that time I was not involved full-time with<br>the project. My ma=
in recollection was that, due to Dmitry's proposal<br>being
 fast-tracked, but incomplete with regards to 2.0 support, you had<br>indic=
ated some interest in assisting with the latter after the initial<br>releas=
e. I never meant to indicate that you are a current maintainer<br>for Zend_=
OpenId -- only that in my mind, and I would argue those of a<br>number of o=
thers, that you were going to be the "party of interest" with<br>regards to=
 2.0 support. I would be absolutely thrilled if you would<br>still be willi=
ng to contribute it -- even if it means another<br>"Zend_Feed_Reader" situa=
tion where we have another parallel library that<br>offers more and better =
support.<br><br>&gt; As for Zend_Crypt and Zend_Service_Yadis, these date b=
ack to 2007. I don't know<br>&gt; how long they have been in the Incubator =
- but aside from a few minor issues in<br>&gt; Yadis they've been sitting t=
here waiting for whatever the next step is. <br><br>For the record of those=
 reading, once a developer feels their<br>contribution is complete
 and ready for inclusion in trunk -- and this<br>means (a) tests covering t=
he proposal expectations, (b) good test<br>coverage, and (c) complete docum=
entation for the component -- ping<br>somebody on the Zend team to do a rev=
iew for inclusion. We will verify<br>these points, and either ask for furth=
er work to be done or work with<br>you to move them into trunk.<br><br>So, =
Paddy, does this mean you're ready for Zend_Crypt and<br>Zend_Service_Yadis=
 to move into trunk? :)<br><br>&gt; I don't have any immediate need for the=
m - they were intended for use<br>&gt; in Zend_OpenId whenever Dmitry neede=
d them. Yadis has been up on PEAR<br>&gt; as a release for almost as long. =
<br><br>Let's discuss this after 1.9 is out the door. I'd like to see some<=
br>resolution on OpenId support, and it would be good to get you, Dmitry,<b=
r>and myself on a call or IRC chat together to determine the way forward.<b=
r><br>&gt; OAuth dates from mid-2008 - completely my fault it's not
 quite<br>&gt; finished but I have told a few people since last December th=
at they<br>&gt; should not hesitate to work on it in my absence.&nbsp; I ju=
st couldn't get<br>&gt; to it at the time. In any case, it's on my card rig=
ht after ZFR<br>&gt; finishes up with the final testing.<br><br>If you have=
, nobody has approached anybody on the team about taking over<br>the propos=
al. Again, let's discuss this after 1.9.<br><br>&gt; Anyway, this is way wa=
y off topic.<br><br>Agreed -- and I apologize again for bringing it up on a=
 public forum. I<br>am, and remain, frustrated that the topic of bug and co=
mponent<br>maintenance was raised basically on the even of a new release, a=
nd took<br>it out on you. I shouldn't have.<br><br>&gt; My point in using t=
hat example is that it's another component that is not<br>&gt; actively mai=
ntained. I am definitely not its maintainer - and I don't even use<br>&gt; =
it. Just backing up Benjamin's observation. I know it's an
 unrealistic pain in<br>&gt; the butt that Zend are expected to maintain th=
ese, but at some point either<br>&gt; maintenance needs to be enforced <br>=
<br>And I think the key point here is that it needs to be a "put up, or liv=
e<br>with having others maintain your code" policy. I actually have people<=
br>regularly asking if they can work on a component -- and usually put them=
<br>in touch with the existing maintainer. I think at a certain point,<br>h=
owever, if it's clear the developer is no longer actively maintaining<br>th=
e code, we mark it as unmaintained somewhere, and, as somebody else<br>note=
d, put up a "help wanted" sign for that component. The question is<br>where=
 this will live, and what the policy will be regarding when a<br>component =
is considered "unmaintained".<br><br>That said... I know I'm not actively m=
aintaining much of the code I've<br>written. I hope to, soon, but with the =
change in roles, I've had much<br>less time for this activity. So,
 if you know I authored a component, and<br>are interested in helping maint=
ain it... please contact me. :)<br><br><br>-- <br>Matthew Weier O'Phinney<b=
r>Project Lead&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a ymailto=3D"mai=
lto:[email-masked]" href=3D"mailto:[email-masked]">[email-masked]</a>=
<br><span>Zend Framework&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | <a target=3D"_=
blank" href=3D"http://framework.zend.com/">http://framework.zend.com/</a></=
span><br></div></div></div></body></html>
--0-1748743313-1248708561=:49113--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 15:56:28 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: =?iso-8859-1?Q?Lukas_K=F6ll?= <[email-masked]>,
	[email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

--0-712856887-1268693788=:59656
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Lukas,=0A=0AYou're right. There...short and sweet confirmation ;). If we ta=
ke up Matthew's suggestion the interface would be either a noun or an adjec=
tive, so something like the current Zend_Feed_Subscriber_CallbackInterface =
would simply be shortened to Zend_Feed_Subscriber_Callback. Unfortunately, =
we're likely to meet conflicts - in this exampleZend_Feed_Subscriber_Callba=
ck is already a concrete implementation so it would need to be renamed. To =
what, I'm not sure - Zend_Feed_Subscriber_Callback_Basic? This lengthens th=
e concrete class name and also shifts its directory position to boot, so pe=
rhaps simply Zend_Feed_Subscriber_CallbackBasic. Oddly I seem to do this an=
 awful lot :P. Since Interface was our marker, the nouns and adjectives wer=
e used for concrete class names instead. Going to be...interesting...revers=
ing all that in a sensible way.=0A=0AMain thing to come out of any confusio=
n here though, is simply to stick with standard English. If a new interface=
 name looks decidedly odd or uncomfortable, it's probably just as well back=
tracking a little and contemplating a more sensible name. Some of the earli=
er examples like Foobarable and Foobarist missed the simplicity of "Foobar"=
 - it's a noun, right? If it happens to be currently a concrete class, well=
, it will just have to move over and make way for the Interface. It will be=
 somewhat disruptive in this sense.=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ah=
ttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Eur=
ope Foundation Irish Representative=0A=0A=0A=0A=0A=0A______________________=
__________=0AFrom: Lukas K=F6ll <[email-masked]>=0ATo: zf-contributors@l=
ists.zend.com=0ASent: Mon, March 15, 2010 10:09:39 PM=0ASubject: Re: [zf-co=
ntributors] Poll: Interfaces/Abstract class naming conventions=0A=0AHi Ralf=
,=0Athis is my first "get-in-touch" with the zf-contributor list so please =
feel free to draw my attention to any mistakes i make.=0A=0AFor Zend_Acl_Ro=
le I would have thought that Zend_Acl_Role should be the new Interface, whi=
le for the default implementation there should be something like Zend_Acl_R=
ole_Default/Text. As I have never needed to implement custom acl-roles myse=
lf I also don't know which possible use cases a custom implementation of a =
Zend_Acl_Role Interface might have. I also think that an interface named Ze=
nd_Acl_Role is much more reader-friendly than Zend_Acl_Role_Interface. =0A=
=0AZend_Captcha_Adapter might from my point of view stay just as-is (becaus=
e, actually, everything that implements Zend_Captcha_Adapter CAN ACT AS an =
adapter), Zend_Pdf_ElementFactory_Interface should in my opinion also be re=
named to Zend_Pdf_ElementFactory and move the default implementation to som=
ething like Zend_Pdf_ElementFactory_Default (maybe someone can come up with=
 something better then "Default" ?) - again, reading "instanceof Zend_Pdf_E=
lementFactory" feels at least to me much more natural than "instanceof Zend=
_Pdf_ElementFactory_Interface"=0A=0AZend_Validate would by the way be a goo=
d example for adding adjectives. My proposal: Zend_Validateable or Zend_Val=
idate_Validateable=0A=0Abest regards=0A=0ALukas K=F6ll=0A=0AAm 15.03.2010 u=
m 22:34 schrieb Ralf Eggert:=0A=0A> Hi Matthew,=0A> =0A> Could you feed thi=
s discussion with some real world examples? For=0A> example "Foobarable" an=
d "Foobarist" sound a little weird to me.=0A> =0A> Please name some interfa=
ces with their current name and the future=0A> variations for the options 1=
 to 8. Maybe this could help a little more=0A> in the discussion. For examp=
le how should Zend_Acl_Role_Interface oder=0A> Zend_Captcha_Adapter or Zend=
_Pdf_ElementFactory_Interface be renamed?=0A> =0A> Thanks and best regards,=
=0A> =0A> Ralf=0A> 
--0-712856887-1268693788=:59656
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Lukas,<br><br>You're right. There...short and sweet confirmati=
on ;). If we take up Matthew's suggestion the interface would be either a n=
oun or an adjective, so something like the current Zend_Feed_Subscriber_Cal=
lbackInterface would simply be shortened to Zend_Feed_Subscriber_Callback. =
Unfortunately, we're likely to meet conflicts - in this example Zend_Feed_S=
ubscriber_Callback is already a concrete implementation so it would need to=
 be renamed. To what, I'm not sure - Zend_Feed_Subscriber_Callback_Basic? T=
his lengthens the concrete class name and also shifts its directory positio=
n to boot, so perhaps simply Zend_Feed_Subscriber_CallbackBasic. Oddly I se=
em to do this an awful lot :P. Since Interface was our marker, the nouns an=
d adjectives were used for concrete class names instead. Going to
 be...interesting...reversing all that in a sensible way.<br><br>Main thing=
 to come out of any confusion here though, is simply to stick with standard=
 English. If a new interface name looks decidedly odd or uncomfortable, it'=
s probably just as well backtracking a little and contemplating a more sens=
ible name. Some of the earlier examples like Foobarable and Foobarist misse=
d the simplicity of "Foobar" - it's a noun, right? If it happens to be curr=
ently a concrete class, well, it will just have to move over and make way f=
or the Interface. It will be somewhat disruptive in this sense.<br><br>Padd=
y<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D=
"font-family: times new roman,new york,times,serif;" size=3D"3"><span style=
=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span style=3D=
"font-style: italic;"><font style=3D"font-family: times new roman,new york,=
times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: tahoma,new york,times,serif; font-size: 8pt;"><font =
size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><span style=3D"font-weight: bo=
ld;">From:</span></b> Lukas K=F6ll &lt;[email-masked]&gt;<br><b><span st=
yle=3D"font-weight: bold;">To:</span></b> [email-masked]<br=
><b><span style=3D"font-weight: bold;">Sent:</span></b> Mon, March 15, 2010=
 10:09:39 PM<br><b><span style=3D"font-weight: bold;">Subject:</span></b> R=
e: [zf-contributors] Poll: Interfaces/Abstract class naming conventions<br>=
</font><br>=0AHi Ralf,<br>this is my first "get-in-touch" with the zf-contr=
ibutor list so please feel free to draw my attention to any mistakes i make=
.<br><br>For Zend_Acl_Role I would have thought that Zend_Acl_Role should b=
e the new Interface, while for the default implementation there should be s=
omething like Zend_Acl_Role_Default/Text. As I have never needed to impleme=
nt custom acl-roles myself I also don't know which possible use cases a cus=
tom implementation of a Zend_Acl_Role Interface might have. I also think th=
at an interface named Zend_Acl_Role is much more reader-friendly than Zend_=
Acl_Role_Interface. <br><br>Zend_Captcha_Adapter might from my point of vie=
w stay just as-is (because, actually, everything that implements Zend_Captc=
ha_Adapter CAN ACT AS an adapter), Zend_Pdf_ElementFactory_Interface should=
 in my opinion also be renamed to Zend_Pdf_ElementFactory and move the defa=
ult implementation to something like Zend_Pdf_ElementFactory_Default (maybe
 someone can come up with something better then "Default" ?) - again, readi=
ng "instanceof Zend_Pdf_ElementFactory" feels at least to me much more natu=
ral than "instanceof Zend_Pdf_ElementFactory_Interface"<br><br>Zend_Validat=
e would by the way be a good example for adding adjectives. My proposal: Ze=
nd_Validateable or Zend_Validate_Validateable<br><br>best regards<br><br>Lu=
kas K=F6ll<br><br>Am 15.03.2010 um 22:34 schrieb Ralf Eggert:<br><br>&gt; H=
i Matthew,<br>&gt; <br>&gt; Could you feed this discussion with some real w=
orld examples? For<br>&gt; example "Foobarable" and "Foobarist" sound a lit=
tle weird to me.<br>&gt; <br>&gt; Please name some interfaces with their cu=
rrent name and the future<br>&gt; variations for the options 1 to 8. Maybe =
this could help a little more<br>&gt; in the discussion. For example how sh=
ould Zend_Acl_Role_Interface oder<br>&gt; Zend_Captcha_Adapter or Zend_Pdf_=
ElementFactory_Interface be renamed?<br>&gt; <br>&gt; Thanks and best
 regards,<br>&gt; <br>&gt; Ralf<br>&gt; <br><br></div></div>=0A</div></body=
></html>
--0-712856887-1268693788=:59656--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 19:16:03 +0300
From: islam el-naggar <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Contributed documentation

--001485f778c40f57bb04744108ea
Content-Type: text/plain; charset=ISO-8859-1

i sent my CLA on the fax few moths ago , and i'm on my way to develop and
contribute in ZF so  i didn't get any response till now

--001485f778c40f57bb04744108ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span class=3D"Apple-style-span" style=3D"font-family: ari=
al, sans-serif; font-size: 13px; border-collapse: collapse; ">i sent my CLA=
 on the fax few moths ago , and i&#39;m on my way to develop and contribute=
 in ZF so =A0i didn&#39;t get any response till now</span></div>

--001485f778c40f57bb04744108ea--

nFrom nobody Wed Apr  7 08:46:14 2010
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization
From: Josh Butts <[email-masked]>
Date: Mon, 22 Mar 2010 08:07:09 -0500
Cc: [email-masked]
To: Matthew Weier O'Phinney <[email-masked]>

Matthew,

Just as an FYI, the latest version of Fisheye does support Git (you =
mentioned viewgit below). We're using it at my company and have had no =
problems with it.

-Josh

On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:

> Greetings, all --
>=20
> Based on the wiki and the poll on this list, it looks like it makes
> sense to move forward with git. We're still trying to iron on some
> details about how this will work, but some details are falling into
> place.
>=20
> First, the things we plan:
>=20
> * Git will be hosted on the ZF servers. This is so that we can have
>   full control over hooks (i.e., no network latency from web hooks),
>   integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
>   will offer both anonymous access as well as selective writable
>   access.
>=20
>   Some will say, "why not just use Github?" The above does not =
preclude
>   using github in any way; git allows you to specify multiple remotes
>   from your repository. I already plan to have a mirror of my personal
>   repo on github, as well as push to the ZF repo from the same
>   location. This will allow people to use some of githubs powerful
>   features such as pull queues while still allowing us to retain some
>   control over the repository. (It also insulates us from githubs
>   growing pains a bit -- I love github, but they are certainly
>   suffering from rapid growth the last few months!)
>=20
> * We plan to have a read-only subversion mirror of the git repository.
>   This will allow those using svn:externals to continue to do so, as
>   well as allow folks more familiar with svn to continue to provide
>   patches.
>=20
> Next, things we're still researching:
>=20
> * How to handle contributions. Since we require a signed CLA, we need
>   some way of verifying that a patch came from an author who has =
signed
>   the CLA. There have been some suggestions that this may be possible
>   with some sort of pre-commit verifications when committing to the
>   master repository (or when someone with commit privileges commits to
>   their own repository). We're still researching how this might be
>   implemented.
>=20
> * Submodules...
>   For those unfamiliar with git submodules, they are roughly =
equivalent
>   to svn:externals. I say "roughly", because they differ in many ways:
>   they have to be manually initialized on each person's repository
>   (though they can be defined in the master repository); they need to
>   be manually updated periodically (unlike svn:externals, where =
anytime
>   you do an "svn up", it also syncs the external); etc.
>=20
>   They are quite powerful, however, and give us the ability to offer a
>   "lean" initial checkout, allowing developers to sync in only the
>   submodules they plan to utilize or commit to.
>=20
>   On this note, I've fielded a number of suggestions. Some were
>   suggesting the library directory be its own submodule, some =
suggested
>   all top-level directories be their own submodule, etc. I've done =
some
>   experimentation, and now propose the following structure:
>=20
>    MAIN REPO:
>        INSTALL.txt
>        LICENSE.txt
>        README.txt
>        bin/
>        library
>        tests/
>        documentation/manual/
>            Makefile
>            README.txt
>            en/
>    SUBMODULES:
>        demos/
>        resources/
>        tools/
>        documentation/manual/:
>            all languages except "en"
>=20
>   Now, for an explanation of the "whys" behind this. As contributors,
>   it's important to make atomic commits: your code fix should also
>   include a corresponding unit test, and potentially a documentation
>   commit as well. If we split the library and tests directories out
>   into their own submodules, we cannot do so; the code and test must =
be
>   committed separately, which is (a) more work, and (b) unintuitive.
>   The same goes for related documentation commits.
>=20
>   Translations, on the other hand, are usually managed in a
>   per-language capacity, flowing from English to the target language.
>   Most developers do not need the docbook source for anything but =
their
>   target language and English (the latter because it's used for
>   fallbacks, and because it contains the build scripts). While we
>   potentially lose the history of an "svn cp", I think this
>   organization provides reasonable benefits.
>=20
>   Finally, the demos, resources, and tools (the latter is a new
>   directory) are all "opt-in" items -- if you need them, you can pull
>   them in; if you don't, there's no reason to.
>=20
> I'd love to get some feedback on the incomplete items. I think the
> submodule layout I've come up with makes the most sense for =
contributors
> (and based on testing, it's the cleanest and simplest way I've found =
to
> accomplish most common development tasks on our tree), but am open to
> further suggestions. If you have any ideas on handling ACLs, I'd love =
to
> hear them, and sooner rather than later!
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 01:32:33 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

Matthew Weier O'Phinney wrote on 25.02.2010 21:48:
> People clone it, and
> then issue a pull request to a release master. The release master can
> track multiple repos from multiple collaborators, and then selectively
> merge into their own "master" -- and push those patches into the
> mainline.

Would that mean, that the component maintainers would not have any
commit access anymore but only the liasions? Or would those component
maintainers become the release masters? Because if only a handful of
people (like those 3 liasions) would get commit access, the entire
colaboration process would become pretty slow.

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 14 Sep 2009 12:55:25 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Announcement: Monthly Bug Hunt!

Greetings, one and all!

I've alluded several times in the past month to having a plan for
helping manage our ever-growing bug list in the issue tracker. We're now
ready to roll out phase one of this plan, and we need *you*!

Starting this month, we will be sponsoring two bug hunt days monthly, on
the third Thursday and Friday of the month. That's this upcoming
Thursday and Friday, 17-18 September 2009.

During those days, the Zend team -- myself, Ralph, and Alex -- will be
in #zftalk.dev on Freenode for our entire work day (Ralph and myself are
in the United States, Alex is based in Russia; figure out the timezones
yourself (-: ). We will be triaging bugs ourselves, but, more
importantly, we will be there to help facilitate *you*, our contributors
and users, in resolving issue reports. 

As an incentive, each month, we will ship a Zend Framework t-shirt to
the individual that assists in the most issue resolutions during the bug
hunt days, whether via patches or direct commits. Quarterly, we will
evaluate overall contributions, including documentation, bug fixes, and
newly contributed components, and award a developer with their choice of
a Zend Studio license or Zend Framework Certification voucher. (Caveat:
one t-shirt per person per year, and one license/voucher per person per
year, folks!) 

For those interested in participating in the bug hunt days, the rules
are simple: have a signed CLA on file, and resolve issues in the
tracker. 

If you have not yet signed a CLA and want to participate, you can get a
copy of the form here:

    http://framework.zend.com/cla

Sign it and return it (you can email it, fax it, or send it via post);
if you send it via post, you'll need to wait for confirmation that
we've received it before we can accept code contributions from you.

Now, when it comes to the issue tracker, you'll need to determine if the
issue:

 * is simply the reporter misunderstanding or misusing code OR
 * is a request for a new feature OR
 * is a reproducible issue

In the first case, comment on it and indicate the correct usage, and ask
the component maintainer or somebody from Zend to review your response
and mark the issue as resolved. In the second case, please try and focus
on issue reports instead of feature requests during the bug hunt days.

That brings us to the final case, reproducible issue reports. With
these, you'll need to do the following:

 * Capture the reproduce case as a unit test
 * Resolve the issue in such a way as to maintain backwards
   compatibility with existing usage. (In other words, don't change the
   signature of a method unless the signature is what is actually
   broken.)

>From there, you then have two options:

 * If you already have commit access, commit the test and fix to the
   repository, and either resolve the issue or ask somebody from Zend to
   review and resolve.  Don't forget to merge your changes to the 1.9
   release branch!

 * If you do not have commit rights, create a patch with the unit test
   and fix, and attach the patch to the issue. Ask the maintainer or
   somebody from Zend to review and apply the patch.

If you need help creating the unit test or patch file, hop onto the
#zftalk.dev IRC channel and ask for help.

How should you choose issues to work on? Answer the following questions,
and you should be able to hop right in:

 * What components do you have expertise in?
 * What components are you interested in learning more about?
 * What issues have a high number of voters or watchers?

Bug hunting should be fun, so pick components and issues you're
interested in. Ask questions on IRC if you don't understand how
something works.

So, spread the word, and come prepared this week to help make the
framework even better! I look forward to seeing you on IRC this week!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 04 Jun 2009 11:47:52 -0700
From: Jason Webster <[email-masked]>
To: till <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] addScriptPath question

One workaround is to retrieve the path array from the getScriptPath method, append the path, then 
feed it back to the view using the setScriptPath method.

On 04/06/2009 10:11 AM, till wrote:
> Hey,
>
> debugging some code, and I noticed that addScripPath (and ultimately
> _addPath()) in Zend_View_Abstract always prepends the path. I was
> trying to add script paths as a fall back -- if not found in this
> module, fallback to default (or where the other path leads to). Any
> idea if we could add this kind of behavior for 2.0?
>
> This is the code (from Zend/View/Abstract.php, _addPath()):
>
>          switch ($type) {
>                  case 'script':
>                      // add to the top of the stack.
>                      array_unshift($this->_path[$type], $dir);
>                      break;
>
> Sort of related, it would be nice if there were no private methods in
> that class. ;-(
>
> Till

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 20 Jan 2010 09:30:59 -0800
From: Matthew Ratzloff <[email-masked]>
To: Mihai Bojin <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend_Grid component proposal

--001485f7d6a026eaec047d9bf31e
Content-Type: text/plain; charset=UTF-8

Just an FYI, you are probably going to hit some limitations with the
Zend_Paginator adapters that I've been meaning to fix (for, uh, awhile now).
 When I integrated Ext JS at work, I needed some features like sorting that
were missing.

Since we're now transitioning to GWT and Spring, it's been hard finding the
time or energy to push those changes back into Zend Framework.

-Matt

On Wed, Jan 20, 2010 at 5:55 AM, Mihai Bojin <[email-masked]> wrote:

> Hello Everyone,
>
> I submitted a proposal for review and right now I'm waiting for any
> suggestions, advice, opinions and so on :)
>
> You can check out the proposal here:
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin
>
> Any feedback will be greatly appreciated !
>
>
> Looking forward to hearing from the community,
>
> Mihai Bojin
> Web Developer
> [email-masked]
> [email-masked]
> +4.0721.231.134

--001485f7d6a026eaec047d9bf31e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Just an FYI, you are probably going to hit some limitations with the Zend_P=
aginator adapters that I&#39;ve been meaning to fix (for, uh, awhile now). =
=C2=A0When I integrated Ext JS at work, I needed some features like sorting=
 that were missing.<div>
<br></div><div>Since we&#39;re now transitioning to GWT and Spring, it&#39;=
s been hard finding the time or energy to push those changes back into Zend=
 Framework.</div><div><br></div><div>-Matt<br><br><div class=3D"gmail_quote=
">
On Wed, Jan 20, 2010 at 5:55 AM, Mihai Bojin <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex;">
Hello Everyone,<br>
<br>
I submitted a proposal for review and right now I&#39;m waiting for any sug=
gestions, advice, opinions and so on :)<br>
<br>
You can check out the proposal here:<br>
<a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+=
Bojin" target=3D"_blank">http://framework.zend.com/wiki/display/ZFPROP/Zend=
_Grid+-+Mihai+Bojin</a><br>
<br>
Any feedback will be greatly appreciated !<br>
<br>
<br>
Looking forward to hearing from the community,<br>
<br>
Mihai Bojin<br>
Web Developer<br>
<font color=3D"#888888"><a href=3D"mailto:[email-masked]">mihai.boji=
[email-masked]</a><br>
[email-masked]<br>
+4.0721.231.134</font></blockquote></div><br></div>

--001485f7d6a026eaec047d9bf31e--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 23 Nov 2009 16:19:51 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 1.9.6 sanity check tarballs ready

Sorry all -- I gave the wrong links. Corrected links are below.

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Monday, 23 November 2009, 03:52 PM -0500):
> Greetings!
> 
> Thanks everyone for participating in the Bug Hunt Days last week! Many
> of the fruits of your labors will be released this week, with ZF 1.9.6.
> 
> I've prepared some sanity check tarballs:
> 
>  * Full packages:
      http://framework.zend.com/releases/preview/ZendFramework-1.9.6/ZendFramework-1.9.6.tar.gz
      http://framework.zend.com/releases/preview/ZendFramework-1.9.6/ZendFramework-1.9.6.zip

>  * Minimal packages:
     http://framework.zend.com/releases/preview/ZendFramework-1.9.6/ZendFramework-1.9.6-minimal.tar.gz
     http://framework.zend.com/releases/preview/ZendFramework-1.9.6/ZendFramework-1.9.6-minimal.zip

> At this time, we plan to release late tomorrow (Tuesday) or early
> Wednesday (EST).
> 
> Please test and let me know ASAP if you discover any show stoppers. 
> 
> Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Sat, 23 Jan 2010 18:11:22 +0100
Subject: Re: [zf-contributors] Zend_Date & build-in class Da

Why should it?
You decide what should be taken into account.

When you are using timezones then timezones are taken into account.
When not then they are ignored.

These things are no problem for ZF.
You just need to know what you want to do.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Marc Bennewitz" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, January 23, 2010 5:48 PM
Subject: Re: [zf-contributors] Zend_Date & build-in class Da

> hi thomas,
>
> one more general about Zend_Date: (Please correct my if I'm wrong)
> Zend_Date handles date & time information. Therefore all date objects
> have to handle timezones, too.
> But if you only need the date part the timezone makes it confused.
>
> Birthday example:
> User A:
>  - current timezone =3D +2h (Europe/Berlin - MEST)
>  - set his birthday =3D 1983-08-19  =3D 1983-08-19 00:00:00+0200
>
> User B:
>  - current timezone =3D -8h (Nevada)
>  - display birthday of User A =3D 1983-08-18 14:00:00-0800 =3D 1983-08-=
18
>  =3D 1 day difference
>
> This means the developer have to know which dates have to store/display
> with which timezones.
>
> I'm not a python developer but i think within it its solved well. There
> 3 classes: date, time and datetime.
> - date is for only dates without timezone
> - time is for only times with timezone
> - datetime for both together
>
> Greetings
> Marc
>
> Am 23.01.2010 11:58, schrieb Thomas Weidner:
>> You are comparing apples with oranges.
>> A discussion on such a basis is completly useless.
>>
>> Actually Zend_Date uses mktime. So when you want to compare one
>> implementation to the other you need to compare mktime to DateTime.
>>
>> And of course you already did a real comparison as you reworked
>> Zend_Date. Did you?
>>
>> Just for information... the lack of performance is due to the reason
>> how I was forced to implement the class. A class which is 4500 lines
>> long and adds about 200 methods will never be as performant as a
>> extension which has has only 15 methods.
>>
>> When I am not forced to do the API within a few days as with 0.7 and
>> am allowed to rework it as it should be done then even the existing
>> mktime implementation would be multiple times faster.
>>
>> PS: Related to mktime DateTime performs also slower. The real benefit
>> is only for calculations beside the 32bit unix timestamp.
>>
>> PPS: Again... as said in past... as long as we are limited to 5.2.4
>> there will be no rework due to some major problems which has been
>> solved in later releases.
>>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com
>>
>> ----- Original Message ----- From: "Benjamin Eberlei"
>> <[email-masked]>
>> To: <[email-masked]>
>> Sent: Saturday, January 23, 2010 1:36 AM
>> Subject: Re: [zf-contributors] Zend_Date & build-in class Da
>>
>>
>>> =3D?UTF-8?Q?teTime?=3D
>>>
>>>
>>> The only thing DateTime can't handle that Zend_Date can as of 5.3 is
>>>
>>> localized output
>>>
>>> and maybe some special features.
>>>
>>>
>>>
>>>> From the performance point of view, i have tested three use-cases
>>>> against
>>>
>>> each
>>>
>>> other:
>>>
>>>
>>>
>>> 1. Printing the same instance 100 times
>>>
>>>
>>>
>>> $s =3D microtime(true);
>>>
>>> $d =3D new DateTime("now");
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>   $d->format('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> $date =3D new Zend_Date(1234567890, false);
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>    $date->toString('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> Gives:
>>>
>>> DateTime 0.0004s
>>>
>>> Zend_Date 0.0599s
>>>
>>>
>>>
>>> 2. Changing the date by Unix-Timestamp on each run for 100 times:
>>>
>>>
>>>
>>> $d =3D new DateTime("now");
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>   $d->setTimestamp($now + $i * 7200);
>>>
>>>   $d->format('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> $date =3D new Zend_Date(1234567890, false);
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>    $date->setTimestamp($now + $i * 7200);
>>>
>>>    $date->toString('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> Gives:
>>>
>>> DateTime 0.0010s
>>>
>>> Zend_Date 0.0591s
>>>
>>>
>>>
>>> 3. Changing Date on each call by a defined format (MySQL Database)
>>> for 100
>>>
>>> new instances.
>>>
>>>
>>>
>>> Now this is the most evil performance hit.
>>>
>>>
>>>
>>> $s =3D microtime(true);
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>   $d =3D DateTime::createFromFormat('Y-m-d H:i:s', '2009-04-01 12:12:=
12');
>>>
>>>   $d->format('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>    $date =3D new Zend_Date('2009-04-01 12:12:12', Zend_Date::ISO_8601=
);
>>>
>>>    $date->toString('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> DateTime: 0.0020s
>>>
>>> Zend_Date: 0.1982s
>>>
>>>
>>>
>>> DateTime is faster than Zend_Date by a magnitute of 60-100!!
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 22 Jan 2010 15:59:32 -0800 (PST), P=C3=A1draic Brady
>>>
>>> <[email-masked]> wrote:
>>>
>>>> Personally I don't see DateTime as massively important to Zend_Date.=
 It
>>>
>>>> would be nice to have, but the class itself is pretty basic that I'm
>>>> not
>>>
>>>> sure what exactly it would add to Zend_Date other than offer a
>>>
>>> (measured?)
>>>
>>>> performance boost and some import/export functionality for
>>>
>>> interoperability
>>>
>>>> (would have been nicer to have a DateTime interface).
>>>
>>>>
>>>
>>>>  P=C3=A1draic Brady
>>>
>>>>
>>>
>>>> http://blog.astrumfutura.com
>>>
>>>> http://www.survivethedeepend.com
>>>
>>>> OpenID Europe Foundation Irish Representative
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>> ________________________________
>>>
>>>> From: Marc Bennewitz <[email-masked]>
>>>
>>>> To: [email-masked]
>>>
>>>> Sent: Fri, January 22, 2010 10:16:02 PM
>>>
>>>> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>>>
>>>>
>>>
>>>>  Hi all,
>>>
>>>>
>>>
>>>> Does is matter that Zend_Date doesn't extends the build-in DateTime
>>>
>>>> class ?
>>>
>>>> -> The DateTime class is available since PHP
>>>
>>>> 5.2.0 and ZF require PHP 5.2.4.
>>>
>>>>
>>>
>>>> It would be very nice because than Zend_Date would be compatible to
>>>
>>>> other php libraries using DateTime and within ZF tests like the
>>>
>>>> following can simplify:
>>>
>>>>
>>>
>>>> if ($date instanceof Zend_Date_DateObject) {
>>>
>>>>     $timestamp =3D $date->getUnixTimestamp();
>>>
>>>> } elseif ($date instanceof DateTime) {
>>>
>>>>     $timestamp =3D $date->getTimestamp();
>>>
>>>> } else {
>>>
>>>>     $timestamp =3D (float)$date;
>>>
>>>> }
>>>
>>>>
>>>
>>>> Greetings,
>>>
>>>> Marc
>>
>>=20

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 18:39:51 +0000
From: David Caunt <[email-masked]>
To: Court Ewing <[email-masked]>
Cc: Matthew Ratzloff <[email-masked]>, 
	"Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--001517479428c2a0e40480711bb9
Content-Type: text/plain; charset=UTF-8

I'm inclined to agree with Court and Matthew then - focus on doing a
cracking job of ZF2 and Doctrine 2 and lets make something awesome!

On 25 February 2010 18:24, Court Ewing <[email-masked]> wrote:

> Howdy,
>
> I agree with this sentiment entirely.  While Doctrine 1.x is currently the
> stable series, plans already exist to drop support for it in a little over a
> year (according to the latest roadmap I've seen).  As this is a ZF2 email
> chain, we should focus on Doctrine 2 integration with ZF2.
>
> Doctrine 2, while under heavy development, is actually in a pretty stable
> state.  Pretty much all of the currently implemented functionality will not
> be changing over the next few months, so this sort of integration could
> begin shortly after the initial ZF changes that Matthew has already
> described.
>
> Court Ewing
>
>
> On Thu, Feb 25, 2010 at 1:10 PM, Matthew Ratzloff <
> [email-masked]> wrote:
>
>> I don't think it would be beneficial to include Doctrine 1.x support in
>> Zend Framework 1.x for this reason.  There is no real "upgrade" path from
>> version 1 to 2; they are very different.  It also divides contributors'
>> limited time, and the idea that you'll be working hard on something that
>> will quickly be deprecated is not very motivating.
>>
>> -Matt
>>
>>
>> On Thu, Feb 25, 2010 at 8:46 AM, Giorgio Sironi <
>> [email-masked]> wrote:
>>
>>> On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]>wrote:
>>>
>>>> I like the idea (as David Caunt mentioned) of releasing a 1.X branch
>>>> with Doctrine 1 to test the waters and judging by the amount of work
>>>> required decide to go with Doc2+ZF2 when the time comes.
>>>>
>>>
>>> Beware that Doctrine 1 and Doctrine 2 are very different: the fomer is
>>> ActiveRecord-based while the latter on the UnitOfWork pattern. Their
>>> metadata management is not the same and 2.x is a complete rewrite of 1.x.
>>>
>>> Regards,
>>> --
>>> Giorgio Sironi
>>> Piccolo Principe & Web Engineer
>>> http://giorgiosironi.blogspot.com
>>> http://twitter.com/giorgiosironi
>>>
>>
>>
>
>
> --
> Regards,
> Court Ewing
> 610-304-1624
>

-- 
Save Water...Drink Ouzo !

--001517479428c2a0e40480711bb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I&#39;m inclined to agree with Court and Matthew then - focus on doing a cr=
acking job of ZF2 and Doctrine 2 and lets make something awesome!<div><br><=
/div><div><br><br><div class=3D"gmail_quote">On 25 February 2010 18:24, Cou=
rt Ewing <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">cour=
[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Howdy,<br><br>I agree with this sentiment e=
ntirely.=C2=A0 While Doctrine 1.x is currently the stable series, plans alr=
eady exist to drop support for it in a little over a year (according to the=
 latest roadmap I&#39;ve seen).=C2=A0 As this is a ZF2 email chain, we shou=
ld focus on Doctrine 2 integration with ZF2.<br>

<br>Doctrine 2, while under heavy development, is actually in a pretty stab=
le state.=C2=A0 Pretty much all of the currently implemented functionality =
will not be changing over the next few months, so this sort of integration =
could begin shortly after the initial ZF changes that Matthew has already d=
escribed.<br>

<br>Court Ewing<div><div></div><div class=3D"h5"><br><br><div class=3D"gmai=
l_quote">On Thu, Feb 25, 2010 at 1:10 PM, Matthew Ratzloff <span dir=3D"ltr=
">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">matt@bu=
iltfromsource.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204, 204, 204);padding-left:1ex">
I don&#39;t think it would be beneficial to include Doctrine 1.x support in=
 Zend Framework 1.x for this reason. =C2=A0There is no real &quot;upgrade&q=
uot; path from version 1 to 2; they are very different. =C2=A0It also divid=
es contributors&#39; limited time, and the idea that you&#39;ll be working =
hard on something that will quickly be deprecated is not very motivating.<d=
iv>

<br></div><div>-Matt<div><div></div><div><br><br><div class=3D"gmail_quote"=
>On Thu, Feb 25, 2010 at 8:46 AM, Giorgio Sironi <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:[email-masked]" target=3D"_blank">piccolopr=
[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204, 204, 204);padding-left:1ex"><div class=3D"gmail_quo=
te"><div class=3D"gmail_quote"><div><div>On Thu, Feb 25, 2010 at 5:24 PM, A=
nthony Shireman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>

</div></div><div><div><blockquote class=3D"gmail_quote" style=3D"border-lef=
t:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
I like the idea (as David Caunt mentioned) of releasing a 1.X branch with D=
octrine 1 to test the waters and judging by the amount of work required dec=
ide to go with Doc2+ZF2 when the time comes.<br clear=3D"all"></blockquote>

</div></div><div><br>Beware that Doctrine 1 and Doctrine 2 are very differe=
nt: the fomer is ActiveRecord-based while the latter on the UnitOfWork patt=
ern. Their metadata management is not the same and 2.x is a complete rewrit=
e of 1.x.<br>

</div></div><div><div></div><br clear=3D"all"></div></div><div><div></div><=
div>Regards,<br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Enginee=
r<br><a href=3D"http://giorgiosironi.blogspot.com" target=3D"_blank">http:/=
/giorgiosironi.blogspot.com</a><br>

<a href=3D"http://twitter.com/giorgiosironi" target=3D"_blank">http://twitt=
er.com/giorgiosironi</a><br>

</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear=3D"all"><br></div></div><font color=3D"#88=
8888">-- <br>Regards,<br>Court Ewing<br>610-304-1624<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water...Dri=
nk Ouzo !<br>
</div>

--001517479428c2a0e40480711bb9--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 8 Oct 2009 14:38:00 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] mailing list for contributors doesn't work
	on framework.zend.com

-- Whitcraft, Jon <[email-masked]> wrote
(on Thursday, 08 October 2009, 02:20 PM -0400):
> I believe that is because this list is not archived.  I may be
> mistaken with that but Matthew or Ralph should know better than I.

Not sure why it's not; looking into it.

> -----Original Message-----
> From: Marc Bennewitz [mailto:[email-masked]]
> Sent: Thursday, October 08, 2009 1:10 PM
> To: [email-masked]
> Subject: [zf-contributors] mailing list for contributors doesn't work on framework.zend.com
> 
> Hi,
> 
> The mailing list for contributors doesn't work:
> http://framework.zend.com/archives/contributors
> 
> ERR:  An error occurred with this request: Action "contributors" does
> not exist and was not trapped in __call().
> 
> The link is shown here:
> http://framework.zend.com/wiki/display/ZFDEV/Contributing+to+Zend+Framework#ContributingtoZendFramework-mailinglists
> 
> All other mailing lists are working

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 14:03:55 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Court Ewing <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

--0-7632830-1268687035=:127
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I agree with Matthew on the rest, except that, as with Court, I prefer Abst=
ract to Base. Longer term albeit, it makes more sense than Base which can s=
uggest a broader use meaning (e.g. a non-Abstract super class). Under that =
meaning, Base can be any parent class so the indication of a class being Ab=
stract is no longer a certainty without referring to API docs (or the code =
itself).=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=
=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Repres=
entative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Court Ew=
ing <[email-masked]>=0ATo: [email-masked]=0ASent: Mon=
, March 15, 2010 8:21:26 PM=0ASubject: Re: [zf-contributors] Poll: Interfac=
es/Abstract class naming  conventions=0A=0AHowdy,=0A=0AI think adjective/no=
un names for interfaces are ideal because they are far more inline with the=
 naming conventions already used in SPL, and I think that is something we s=
hould be striving to do wherever possible.=0A=0AI support prefixes for abst=
ract classes rather than suffixes, but it seems that has long been shot dow=
n as an option.=0A=0ARegardless of whether we do prefixes or suffixes thoug=
h, I think we should use the word "Abstract" rather than "Base".  All progr=
ammatic dogma aside, if I were to describe an abstract class to someone els=
e (take an abstract Triangle class), I would tell the person that this is a=
n abstract representation of a triangle; I wouldn't say it is a base repres=
entation of a triangle.  If you're going to cite hungarian notation as the =
reason for not using the word "abstract", then I don't know how you can jus=
tify using any keyword to denote that it is abstract.=0A=0A-Court=0A=0A=0AO=
n Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[email-masked]> =
wrote:=0A=0A>Hey, all --=0A>=0A>>I know this has been hashed out a fair bit=
 already, and we've already=0A>>established some guidelines, but as I play =
with code for ZF2, I'm=0A>>beginning to question the naming conventions for=
 Interfaces and Abstract=0A>>Classes.=0A>=0A>>When we made the decisions be=
fore, we were looking at the following=0A>>three options for interfaces:=0A=
>=0A>> 1. Prefix interfaces with "I" ("IFoobar").=0A>> 2. Suffix interfaces=
 with "Interface" ("FoobarInterface")=0A>> 3. Use adjective/noun names such=
 as "Foobarable", "Foobarist"=0A>=0A>>For abstract classes, we looked at:=
=0A>=0A>> 4. Prefix abstract classes with "A" ("AFoobar")=0A>> 5. Suffix ab=
stract classes with "Abstract" ("FoobarAbstract")=0A>> 6. Prefix abstract c=
lasses with "Base" ("BaseFoobar")=0A>> 7. Suffix abstract classes with "Bas=
e" ("FoobarBase")=0A>> 8. Use normal class names ("Foobar")=0A>=0A>>Regardi=
ng 1, 2, and 4-7, the arguments against were fairly numerous:=0A>>they smac=
k of Hungarian Notation, the long forms lead to really long=0A>>names, etc.=
 Prefixing can lead to similar classes not being grouped when=0A>>doing dir=
ectory listings (i.e., all abstract class or interface files=0A>>get cluste=
red together). Also, for classes beginning with "I" or "A",=0A>>there can p=
otentially be confusion over whether or not the given class=0A>>is supposed=
 to be concrete. Finally, during refactoring, if you choose=0A>>to make an =
interface an abstract class or concrete class, or an abstract=0A>>class an =
interface or concrete class, you can't do so without renaming=0A>>files and=
 classes. (That said, you'll most likely need to make other=0A>>changes any=
ways -- and ZF will likely never make an interface an=0A>>abstract class or=
 vice versa.)=0A>=0A>>Regarding 3 and 8, the primary problems are that it's=
 often hard to come=0A>>up with meaningful names that do not conflict with =
concrete=0A>>implementations, and that for non-native English speakers, thi=
s latter=0A>>problem becomes an even bigger obstacle. Additionally, you can=
't=0A>>determine which files contain abstract classes and/or interfaces jus=
t by=0A>>the filename -- you have to look in the file or look in API=0A>>do=
cumentation to determine this information.=0A>=0A>>Now, as to the issues I'=
ve seen: the word "Interface" becomes a real=0A>>pain to type (yes, even wi=
th autocompletion), and it doesn't really=0A>>connote any real information.=
 When type-hinting, I simply know what type=0A>>I want to use -- the name d=
oesn't need to tell me it's an interface, as=0A>>I already know that inform=
ation. If I'm writing code that consumes or=0A>>interacts with the class, A=
PI docs will tell me what I need to do.=0A>=0A>>That said, I don't use Abst=
ract classes that often, but considering they=0A>>are a foundation on which=
 to build concrete classes (presumably to take=0A>>care of many of the nitt=
y gritty details and leave the concrete classes=0A>>to implement specifics)=
, I don't mind using a class suffix. "Abstract"=0A>>feels like Hungarian no=
tation, though.=0A>=0A>>Based on my experiences writing code, I'm currently=
 recommending that we=0A>>do the following:=0A>=0A>> 3. Use adjective/noun =
names for Interfaces such as "Foobarable",=0A>>    "Foobarist"=0A>> 7. Suff=
ix abstract classes with "Base" ("FoobarableBase")=0A>=0A>>The above solve =
most issues - names are reasonably sized, don't smack of=0A>>Hungarian Nota=
tion (okay, so the "Base" verbiage kind of does), and are,=0A>>most importa=
ntly, meaningful. Since we already implement code review for=0A>>any code c=
oming into trunk, I think we can even solve the issues for=0A>>non-native s=
peakers as well.=0A>=0A>>Thoughts? Votes?=0A>=0A>>--=0A>>Matthew Weier O'Ph=
inney=0A>>Project Lead            | [email-masked]=0A>>Zend Framework    =
      | http://framework.zend.com/=0A>>PGP key: http://framework.zend.com/z=
f-matthew-pgp-key.asc=0A>=0A
--0-7632830-1268687035=:127
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">I agree with Matthew on the rest, except that, as with Court, =
I prefer Abstract to Base. Longer term albeit, it makes more sense than Bas=
e which can suggest a broader use meaning (e.g. a non-Abstract super class)=
. Under that meaning, Base can be any parent class so the indication of a c=
lass being Abstract is no longer a certainty without referring to API docs =
(or the code itself).<br><br>Paddy<br><div>&nbsp;</div><span style=3D"color=
: rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new york,tim=
es,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br=
><br></span></font><span style=3D"font-style: italic;"><font style=3D"font-=
family: times new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollo=
w" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: times new roman,new york,times,serif; font-size: 12p=
t;"><font size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><span style=3D"font-=
weight: bold;">From:</span></b> Court Ewing &lt;[email-masked]&gt;<br=
><b><span style=3D"font-weight: bold;">To:</span></b> zf-contributors@lists=
.zend.com<br><b><span style=3D"font-weight: bold;">Sent:</span></b> Mon, Ma=
rch 15, 2010 8:21:26 PM<br><b><span style=3D"font-weight: bold;">Subject:</=
span></b> Re: [zf-contributors] Poll: Interfaces/Abstract class naming  con=
ventions<br></font><br>=0A<meta http-equiv=3D"x-dns-prefetch-control" conte=
nt=3D"off">Howdy,<br><br>I think adjective/noun names for interfaces are id=
eal because they are far more inline with the naming conventions already us=
ed in SPL, and I think that is something we should be striving to do wherev=
er possible.<br>=0A<br>I support prefixes for abstract classes rather than =
suffixes, but it seems that has long been shot down as an option.<br><br>Re=
gardless of whether we do prefixes or suffixes though, I think we should us=
e the word "Abstract" rather than "Base".&nbsp; All programmatic dogma asid=
e, if I were to describe an abstract class to someone else (take an abstrac=
t Triangle class), I would tell the person that this is an abstract represe=
ntation of a triangle; I wouldn't say it is a base representation of a tria=
ngle.&nbsp; If you're going to cite hungarian notation as the reason for no=
t using the word "abstract", then I don't know how you can justify using an=
y keyword to denote that it is abstract.<br>=0A<br>-Court<br><br><div class=
=3D"gmail_quote">On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <=
span dir=3D"ltr">&lt;<a rel=3D"nofollow" ymailto=3D"mailto:[email-masked]=
" target=3D"_blank" href=3D"mailto:[email-masked]">[email-masked]</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt =
0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex=
;">=0AHey, all --<br>=0A<br>=0AI know this has been hashed out a fair bit a=
lready, and we've already<br>=0Aestablished some guidelines, but as I play =
with code for ZF2, I'm<br>=0Abeginning to question the naming conventions f=
or Interfaces and Abstract<br>=0AClasses.<br>=0A<br>=0AWhen we made the dec=
isions before, we were looking at the following<br>=0Athree options for int=
erfaces:<br>=0A<br>=0A&nbsp;1. Prefix interfaces with "I" ("IFoobar").<br>=
=0A&nbsp;2. Suffix interfaces with "Interface" ("FoobarInterface")<br>=0A&n=
bsp;3. Use adjective/noun names such as "Foobarable", "Foobarist"<br>=0A<br=
>=0AFor abstract classes, we looked at:<br>=0A<br>=0A&nbsp;4. Prefix abstra=
ct classes with "A" ("AFoobar")<br>=0A&nbsp;5. Suffix abstract classes with=
 "Abstract" ("FoobarAbstract")<br>=0A&nbsp;6. Prefix abstract classes with =
"Base" ("BaseFoobar")<br>=0A&nbsp;7. Suffix abstract classes with "Base" ("=
FoobarBase")<br>=0A&nbsp;8. Use normal class names ("Foobar")<br>=0A<br>=0A=
Regarding 1, 2, and 4-7, the arguments against were fairly numerous:<br>=0A=
they smack of Hungarian Notation, the long forms lead to really long<br>=0A=
names, etc. Prefixing can lead to similar classes not being grouped when<br=
>=0Adoing directory listings (i.e., all abstract class or interface files<b=
r>=0Aget clustered together). Also, for classes beginning with "I" or "A",<=
br>=0Athere can potentially be confusion over whether or not the given clas=
s<br>=0Ais supposed to be concrete. Finally, during refactoring, if you cho=
ose<br>=0Ato make an interface an abstract class or concrete class, or an a=
bstract<br>=0Aclass an interface or concrete class, you can't do so without=
 renaming<br>=0Afiles and classes. (That said, you'll most likely need to m=
ake other<br>=0Achanges anyways -- and ZF will likely never make an interfa=
ce an<br>=0Aabstract class or vice versa.)<br>=0A<br>=0ARegarding 3 and 8, =
the primary problems are that it's often hard to come<br>=0Aup with meaning=
ful names that do not conflict with concrete<br>=0Aimplementations, and tha=
t for non-native English speakers, this latter<br>=0Aproblem becomes an eve=
n bigger obstacle. Additionally, you can't<br>=0Adetermine which files cont=
ain abstract classes and/or interfaces just by<br>=0Athe filename -- you ha=
ve to look in the file or look in API<br>=0Adocumentation to determine this=
 information.<br>=0A<br>=0ANow, as to the issues I've seen: the word "Inter=
face" becomes a real<br>=0Apain to type (yes, even with autocompletion), an=
d it doesn't really<br>=0Aconnote any real information. When type-hinting, =
I simply know what type<br>=0AI want to use -- the name doesn't need to tel=
l me it's an interface, as<br>=0AI already know that information. If I'm wr=
iting code that consumes or<br>=0Ainteracts with the class, API docs will t=
ell me what I need to do.<br>=0A<br>=0AThat said, I don't use Abstract clas=
ses that often, but considering they<br>=0Aare a foundation on which to bui=
ld concrete classes (presumably to take<br>=0Acare of many of the nitty gri=
tty details and leave the concrete classes<br>=0Ato implement specifics), I=
 don't mind using a class suffix. "Abstract"<br>=0Afeels like Hungarian not=
ation, though.<br>=0A<br>=0ABased on my experiences writing code, I'm curre=
ntly recommending that we<br>=0Ado the following:<br>=0A<br>=0A&nbsp;3. Use=
 adjective/noun names for Interfaces such as "Foobarable",<br>=0A &nbsp; &n=
bsp;"Foobarist"<br>=0A&nbsp;7. Suffix abstract classes with "Base" ("Foobar=
ableBase")<br>=0A<br>=0AThe above solve most issues - names are reasonably =
sized, don't smack of<br>=0AHungarian Notation (okay, so the "Base" verbiag=
e kind of does), and are,<br>=0Amost importantly, meaningful. Since we alre=
ady implement code review for<br>=0Aany code coming into trunk, I think we =
can even solve the issues for<br>=0Anon-native speakers as well.<br>=0A<br>=
=0AThoughts? Votes?<br>=0A<font color=3D"#888888"><br>=0A--<br>=0AMatthew W=
eier O'Phinney<br>=0AProject Lead &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
| <a rel=3D"nofollow" ymailto=3D"mailto:[email-masked]" target=3D"_blank"=
 href=3D"mailto:[email-masked]">[email-masked]</a><br><span>=0AZend Fra=
mework &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| <a target=3D"_blank" href=3D"htt=
p://framework.zend.com/">http://framework.zend.com/</a></span><br><span>=0A=
PGP key: <a target=3D"_blank" href=3D"http://framework.zend.com/zf-matthew-=
pgp-key.asc">http://framework.zend.com/zf-matthew-pgp-key.asc</a></span><br=
>=0A</font></blockquote></div><br>=0A<meta http-equiv=3D"x-dns-prefetch-con=
trol" content=3D"on"></div></div>=0A</div></body></html>
--0-7632830-1268687035=:127--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 8 Dec 2009 05:15:40 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Ralph Schindler <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

--0-1950063925-1260278140=:16073
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>Hi all,=0A>=0A>I'd like to reiterate a few of the points Matthew is making=
... inline:=0A>=0A>> A few things. First, strip_tags and ZF's StripTags sho=
uld _not_ be=0A>> equated with XSS protection. The fact that people do indi=
cates to me a=0A>> documentation and education problem, not necessarily a b=
ona-fide=0A>=0A>There is no security silver-bullet.  There are only securit=
y best practices, and education from the >ongoing battle between applicatio=
n developers and application attackers.=0A>=0A>StripTags is only one 1/2 of=
 the "Filter Input, Escape Output" mantra of application security.  I could=
 =0A>further argue that it is less than half of the equation in that if you=
 decide to permit comments and =0A>certain attributes, then you should furt=
her expect to have to *do more* to assure that the thing you do =0A>decide =
to allow are safe.=0A=0AAgreed.=0A=0A>> I do want to clarify something: the=
 issue reported earlier this year was=0A>> not so much about filtering XSS =
attacks, but about the fact that due to how=0A>> attributes were matched, i=
t _introduced_ an XSS attack vector. Because=0A>> the regex did not take in=
to account newlines, it was possible to break=0A>> an attribute value onto =
multiple lines to prevent it being matched --=0A>> which provided the attac=
k vector, as attributes not in the whitelist=0A>> would be retained in the =
final filtered tag.=0A>=0A>An XSS attack vector is actually a side effect o=
f the real problem.  The real problem is that attributes >that not on the w=
hitelist were not being stripped.  That was the root problem, and as such- =
we fixed =0A>that.  The side effect is that since multiline attributes coul=
d be passed through without being on the =0A>white-list, XSS too (or any da=
ta for that matter), would be emitted.=0A=0AI'd argue the XSS attack vector=
 is the real problem. This is a security issue with a high severity.=0A=0A>=
> I do see your point regarding the "setCommentsAllowed" functionality; it=
=0A>> is, quite simply, a bad idea, as there is no semantic or structural=
=0A>> value to keeping comments; sure, you could use them for conditional=
=0A>> output, but that's a system ripe for abuse. I'm not entirely sure why=
=0A>> this functionality was added in the first place, and agree with you t=
hat=0A>> it should be removed.=0A>=0A>Before ripping it out, we need to ide=
ntify what the original use case was.  XSS is generally a problem with appl=
ications that live in the public domain.=0A>=0A>** There is a significant n=
umber of applications that scratch an itch NOT in the public domain (enterp=
rise software, intranet systems, and so on.)  There might be people in priv=
ate or protected environments that rely on this feature.  Also note, this i=
s an opt in feature, not on by default.=0A=0APrivate use cases are irreleva=
nt as is the opt-in nature of the functionality. It simply does not work. A=
n employee on a closed system capable of introducing XSS is as much a secur=
ity risk as it would be in a public view.=0A=0A P=E1draic Brady=0A=0Ahttp:/=
/blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe F=
oundation Irish Representative=0A=0A=0A=0A=0A=0A___________________________=
_____=0AFrom: Ralph Schindler <[email-masked]>=0ATo: zf-contribut=
[email-masked]=0ASent: Mon, December 7, 2009 4:18:23 PM=0ASubject: Re: =
[zf-contributors] XSS And Malformed HTML Vulnerabilities In Zend_Filter_Str=
ipTags=0A=0AHi all,=0A=0AI'd like to reiterate a few of the points Matthew =
is making... inline:=0A=0A> A few things. First, strip_tags and ZF's StripT=
ags should _not_ be=0A> equated with XSS protection. The fact that people d=
o indicates to me a=0A> documentation and education problem, not necessaril=
y a bona-fide=0A=0AThere is no security silver-bullet.  There are only secu=
rity best practices, and education from the ongoing battle between applicat=
ion developers and application attackers.=0A=0AStripTags is only one 1/2 of=
 the "Filter Input, Escape Output" mantra of application security.  I could=
 further argue that it is less than half of the equation in that if you dec=
ide to permit comments and certain attributes, then you should further expe=
ct to have to *do more* to assure that the thing you do decide to allow are=
 safe.=0A=0A> I do want to clarify something: the issue reported earlier th=
is year was=0A> not so much about filtering XSS attacks, but about the fact=
 that due to how=0A> attributes were matched, it _introduced_ an XSS attack=
 vector. Because=0A> the regex did not take into account newlines, it was p=
ossible to break=0A> an attribute value onto multiple lines to prevent it b=
eing matched --=0A> which provided the attack vector, as attributes not in =
the whitelist=0A> would be retained in the final filtered tag. =0A=0AAn XSS=
 attack vector is actually a side effect of the real problem.  The real pro=
blem is that attributes that not on the whitelist were not being stripped. =
 That was the root problem, and as such- we fixed that.  The side effect is=
 that since multiline attributes could be passed through without being on t=
he white-list, XSS too (or any data for that matter), would be emitted.=0A=
=0A> I do see your point regarding the "setCommentsAllowed" functionality; =
it=0A> is, quite simply, a bad idea, as there is no semantic or structural=
=0A> value to keeping comments; sure, you could use them for conditional=0A=
> output, but that's a system ripe for abuse. I'm not entirely sure why=0A>=
 this functionality was added in the first place, and agree with you that=
=0A> it should be removed.=0A=0ABefore ripping it out, we need to identify =
what the original use case was.  XSS is generally a problem with applicatio=
ns that live in the public domain.=0A=0A** There is a significant number of=
 applications that scratch an itch NOT in the public domain (enterprise sof=
tware, intranet systems, and so on.)  There might be people in private or p=
rotected environments that rely on this feature.  Also note, this is an opt=
 in feature, not on by default.=0A=0A=0A> May I suggest the following:=0A> =
=0A>  * ZF-8483 and ZF-8484 should be resolved ASAP=0A> =0A>  * As part of =
ZF-8484, which calls for better documenting the use cases=0A>    for StripT=
ags, include a <warning> section clearly stating that it is=0A>    not inte=
nded for XSS prevention=0A> =0A>  * Create an HtmlPurifier filter that prox=
ies to PEAR's HTML_Purifier=0A>    package; this would be included in an up=
coming release.=0A=0AI really like this idea.=0A=0A>  * Remove the setComme=
ntsAllowed() functionality (by having it throw an=0A>    exception indicati=
ng the security vulnerabilities it opens)=0A=0AAs noted: lets be careful ab=
out removing features.=0A=0A> Finally, a request: in the future, when repor=
ting suspected security=0A> vulnerabilities, it's customary to notify the p=
roject _privately_ and=0A> allow some time for the project to address the v=
ulnerability before=0A> making it public. As it is, you've created a very l=
arge, public=0A> discussion that will make the project seem (a) reactionary=
, instead of=0A> proactive, and (b) paint us as completely non-security min=
ded. This is=0A> particularly bad in this situation, as, unless there's mor=
e to report,=0A> the primary issue here is one of documentation and educati=
on, not actual=0A> vulnerabilities in the code (with the exception of setCo=
mmentsAllowed()=0A> -- which isn't a vulnerability per-se, but an ill-guide=
d idea from the=0A> outset).=0A=0ACheers,=0ARalph=0A
--0-1950063925-1260278140=:16073
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">&gt;Hi all,<br>&gt;<br>&gt;I'd like to reiterate a few of the =
points Matthew is making... inline:<br>&gt;<br>&gt;&gt; A few things. First=
, strip_tags and ZF's StripTags should _not_ be<br>&gt;&gt; equated with XS=
S protection. The fact that people do indicates to me a<br>&gt;&gt; documen=
tation and education problem, not necessarily a bona-fide<br>&gt;<br>&gt;Th=
ere is no security silver-bullet.&nbsp; There are only security best practi=
ces, and education from the &gt;ongoing battle between application develope=
rs and application attackers.<br>&gt;<br>&gt;StripTags is only one 1/2 of t=
he "Filter Input, Escape Output" mantra of application security.&nbsp; I co=
uld <br>&gt;further argue that it is less than half of the equation in that=
 if you decide to permit comments and <br>&gt;certain attributes, then
 you should further expect to have to *do more* to assure that the thing yo=
u do <br>&gt;decide to allow are safe.<br><br>Agreed.<br><br>&gt;&gt; I do =
want to clarify something: the issue reported earlier this year was<br>&gt;=
&gt; not so much about filtering XSS attacks, but about the fact that due t=
o how<br>&gt;&gt; attributes were matched, it _introduced_ an XSS attack ve=
ctor. Because<br>&gt;&gt; the regex did not take into account newlines, it =
was possible to break<br>&gt;&gt; an attribute value onto multiple lines to=
 prevent it being matched --<br>&gt;&gt; which provided the attack vector, =
as attributes not in the whitelist<br>&gt;&gt; would be retained in the fin=
al filtered tag.<br>&gt;<br>&gt;An XSS attack vector is actually a side eff=
ect of the real problem.&nbsp; The real problem is that attributes &gt;that=
 not on the whitelist were not being stripped.&nbsp; That was the root prob=
lem, and as such- we fixed <br>&gt;that.&nbsp; The side effect is
 that since multiline attributes could be passed through without being on t=
he <br>&gt;white-list, XSS too (or any data for that matter), would be emit=
ted.<br><br>I'd argue the XSS attack vector is the real problem. This is a =
security issue with a high severity.<br><br>&gt;&gt; I do see your point re=
garding the "setCommentsAllowed" functionality; it<br>&gt;&gt; is, quite si=
mply, a bad idea, as there is no semantic or structural<br>&gt;&gt; value t=
o keeping comments; sure, you could use them for conditional<br>&gt;&gt; ou=
tput, but that's a system ripe for abuse. I'm not entirely sure why<br>&gt;=
&gt; this functionality was added in the first place, and agree with you th=
at<br>&gt;&gt; it should be removed.<br>&gt;<br>&gt;Before ripping it out, =
we need to identify what the original use case was.&nbsp; XSS is generally =
a problem with applications that live in the public domain.<br>&gt;<br>&gt;=
** There is a significant number of applications that scratch an
 itch NOT in the public domain (enterprise software, intranet systems, and =
so on.)&nbsp; There might be people in private or protected environments th=
at rely on this feature.&nbsp; Also note, this is an opt in feature, not on=
 by default.<br><br>Private use cases are irrelevant as is the opt-in natur=
e of the functionality. It simply does not work. An employee on a closed sy=
stem capable of introducing XSS is as much a security risk as it would be i=
n a public view.<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"=
><font style=3D"font-family: times new roman,new york,times,serif;" size=3D=
"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font=
><span style=3D"font-style: italic;"><font style=3D"font-family: times new =
roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blan=
k" href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><b=
r><a rel=3D"nofollow" target=3D"_blank"
 href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com=
</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideuro=
pe.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span>=
</span><div><br></div><div style=3D"font-family: times new roman,new york,t=
imes,serif; font-size: 12pt;"><br><div style=3D"font-family: tahoma,new yor=
k,times,serif; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"><hr size=
=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Ralph Schindl=
er &lt;[email-masked]&gt;<br><b><span style=3D"font-weight: bold;=
">To:</span></b> [email-masked]<br><b><span style=3D"font-w=
eight: bold;">Sent:</span></b> Mon, December 7, 2009 4:18:23 PM<br><b><span=
 style=3D"font-weight: bold;">Subject:</span></b> Re: [zf-contributors] XSS=
 And Malformed HTML Vulnerabilities In Zend_Filter_StripTags<br></font><br>=
=0AHi all,<br><br>I'd like to reiterate a few of the points Matthew is maki=
ng... inline:<br><br>&gt; A few things. First, strip_tags and ZF's StripTag=
s should _not_ be<br>&gt; equated with XSS protection. The fact that people=
 do indicates to me a<br>&gt; documentation and education problem, not nece=
ssarily a bona-fide<br><br>There is no security silver-bullet.&nbsp; There =
are only security best practices, and education from the ongoing battle bet=
ween application developers and application attackers.<br><br>StripTags is =
only one 1/2 of the "Filter Input, Escape Output" mantra of application sec=
urity.&nbsp; I could further argue that it is less than half of the equatio=
n in that if you decide to permit comments and certain attributes, then you=
 should further expect to have to *do more* to assure that the thing you do=
 decide to allow are safe.<br><br>&gt; I do want to clarify something: the =
issue reported earlier this year was<br>&gt; not so much about
 filtering XSS attacks, but about the fact that due to how<br>&gt; attribut=
es were matched, it _introduced_ an XSS attack vector. Because<br>&gt; the =
regex did not take into account newlines, it was possible to break<br>&gt; =
an attribute value onto multiple lines to prevent it being matched --<br>&g=
t; which provided the attack vector, as attributes not in the whitelist<br>=
&gt; would be retained in the final filtered tag. <br><br>An XSS attack vec=
tor is actually a side effect of the real problem.&nbsp; The real problem i=
s that attributes that not on the whitelist were not being stripped.&nbsp; =
That was the root problem, and as such- we fixed that.&nbsp; The side effec=
t is that since multiline attributes could be passed through without being =
on the white-list, XSS too (or any data for that matter), would be emitted.=
<br><br>&gt; I do see your point regarding the "setCommentsAllowed" functio=
nality; it<br>&gt; is, quite simply, a bad idea, as there is no
 semantic or structural<br>&gt; value to keeping comments; sure, you could =
use them for conditional<br>&gt; output, but that's a system ripe for abuse=
. I'm not entirely sure why<br>&gt; this functionality was added in the fir=
st place, and agree with you that<br>&gt; it should be removed.<br><br>Befo=
re ripping it out, we need to identify what the original use case was.&nbsp=
; XSS is generally a problem with applications that live in the public doma=
in.<br><br>** There is a significant number of applications that scratch an=
 itch NOT in the public domain (enterprise software, intranet systems, and =
so on.)&nbsp; There might be people in private or protected environments th=
at rely on this feature.&nbsp; Also note, this is an opt in feature, not on=
 by default.<br><br><br>&gt; May I suggest the following:<br>&gt; <br>&gt;&=
nbsp; * ZF-8483 and ZF-8484 should be resolved ASAP<br>&gt; <br>&gt;&nbsp; =
* As part of ZF-8484, which calls for better documenting the use
 cases<br>&gt;&nbsp; &nbsp; for StripTags, include a &lt;warning&gt; sectio=
n clearly stating that it is<br>&gt;&nbsp; &nbsp; not intended for XSS prev=
ention<br>&gt; <br>&gt;&nbsp; * Create an HtmlPurifier filter that proxies =
to PEAR's HTML_Purifier<br>&gt;&nbsp; &nbsp; package; this would be include=
d in an upcoming release.<br><br>I really like this idea.<br><br>&gt;&nbsp;=
 * Remove the setCommentsAllowed() functionality (by having it throw an<br>=
&gt;&nbsp; &nbsp; exception indicating the security vulnerabilities it open=
s)<br><br>As noted: lets be careful about removing features.<br><br>&gt; Fi=
nally, a request: in the future, when reporting suspected security<br>&gt; =
vulnerabilities, it's customary to notify the project _privately_ and<br>&g=
t; allow some time for the project to address the vulnerability before<br>&=
gt; making it public. As it is, you've created a very large, public<br>&gt;=
 discussion that will make the project seem (a) reactionary, instead
 of<br>&gt; proactive, and (b) paint us as completely non-security minded. =
This is<br>&gt; particularly bad in this situation, as, unless there's more=
 to report,<br>&gt; the primary issue here is one of documentation and educ=
ation, not actual<br>&gt; vulnerabilities in the code (with the exception o=
f setCommentsAllowed()<br>&gt; -- which isn't a vulnerability per-se, but a=
n ill-guided idea from the<br>&gt; outset).<br><br>Cheers,<br>Ralph<br></di=
v></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compressed/chunked Mon Dec  7 0=
3:29:14 PST 2009 -->=0A</div></body></html>
--0-1950063925-1260278140=:16073--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 23:41:03 -0500
From: Ralph Schindler <[email-masked]>
To: Matthew Ratzloff <[email-masked]>
CC: Nico Edtinger <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?

I don't think this is actually necessary.  We have very little to gain 
by moving away from the current behavior of normalizing the adapter 
name.  I have not heard anyone really complaining about the adapter name 
as much as I've heard complaining about the adapter namespace.  MySQLi 
instead of Mysqli, or PDO_MySQL instead of Pdo_Mysql.

So this can really wait till 2.0, when the actual adapter can undergo 
their own renaming.

Like I mentioned before, and as you can see in the patch [1], the only 
thing left out was the strtolower() in the adapter name normalization. 
Partly b/c there was no unit test for this actual use case, and most of 
the code that I've ever actually encountered used the 1 to 1 naming 
(whatever it was on the filesystem is exactly how it was written in the 
factory or config file).

So, unless there is a really strong argument for moving away from the 
now current behavior, I say we wait till 2.0 time.

-ralph

[1] http://framework.zend.com/code/changelog/Standard_Library/?cs=18372

Matthew Ratzloff wrote:
> That's a good compromise solution.
> 
> -Matt
> 
> On Wed, Sep 23, 2009 at 4:11 AM, Nico Edtinger <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Matthew Ratzloff wrote:
> 
>         Breaking BC in a mini release is bad news.  I would strongly
>         suggest adding
>         a new option in the config array (second parameter) to control
>         inflection,
>         with the default the old style.  This way, in your config you
>         can say:
> 
>         db.newInflector = true
> 
> 
>     Do we really need a new option? What I've read the problem is people
>     writing 'PDO_MYSQL' or 'pdo_mysql'. It should suffice to convert the
>     name if it's completely uppercase or lowercase and else leave as is.
> 
>     nico
> 
> 

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 16:21:26 -0400
From: Court Ewing <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

--001485f196ec2c5bad0481dca052
Content-Type: text/plain; charset=ISO-8859-1

Howdy,

I think adjective/noun names for interfaces are ideal because they are far
more inline with the naming conventions already used in SPL, and I think
that is something we should be striving to do wherever possible.

I support prefixes for abstract classes rather than suffixes, but it seems
that has long been shot down as an option.

Regardless of whether we do prefixes or suffixes though, I think we should
use the word "Abstract" rather than "Base".  All programmatic dogma aside,
if I were to describe an abstract class to someone else (take an abstract
Triangle class), I would tell the person that this is an abstract
representation of a triangle; I wouldn't say it is a base representation of
a triangle.  If you're going to cite hungarian notation as the reason for
not using the word "abstract", then I don't know how you can justify using
any keyword to denote that it is abstract.

-Court

On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> Hey, all --
>
> I know this has been hashed out a fair bit already, and we've already
> established some guidelines, but as I play with code for ZF2, I'm
> beginning to question the naming conventions for Interfaces and Abstract
> Classes.
>
> When we made the decisions before, we were looking at the following
> three options for interfaces:
>
>  1. Prefix interfaces with "I" ("IFoobar").
>  2. Suffix interfaces with "Interface" ("FoobarInterface")
>  3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> For abstract classes, we looked at:
>
>  4. Prefix abstract classes with "A" ("AFoobar")
>  5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>  6. Prefix abstract classes with "Base" ("BaseFoobar")
>  7. Suffix abstract classes with "Base" ("FoobarBase")
>  8. Use normal class names ("Foobar")
>
> Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
> they smack of Hungarian Notation, the long forms lead to really long
> names, etc. Prefixing can lead to similar classes not being grouped when
> doing directory listings (i.e., all abstract class or interface files
> get clustered together). Also, for classes beginning with "I" or "A",
> there can potentially be confusion over whether or not the given class
> is supposed to be concrete. Finally, during refactoring, if you choose
> to make an interface an abstract class or concrete class, or an abstract
> class an interface or concrete class, you can't do so without renaming
> files and classes. (That said, you'll most likely need to make other
> changes anyways -- and ZF will likely never make an interface an
> abstract class or vice versa.)
>
> Regarding 3 and 8, the primary problems are that it's often hard to come
> up with meaningful names that do not conflict with concrete
> implementations, and that for non-native English speakers, this latter
> problem becomes an even bigger obstacle. Additionally, you can't
> determine which files contain abstract classes and/or interfaces just by
> the filename -- you have to look in the file or look in API
> documentation to determine this information.
>
> Now, as to the issues I've seen: the word "Interface" becomes a real
> pain to type (yes, even with autocompletion), and it doesn't really
> connote any real information. When type-hinting, I simply know what type
> I want to use -- the name doesn't need to tell me it's an interface, as
> I already know that information. If I'm writing code that consumes or
> interacts with the class, API docs will tell me what I need to do.
>
> That said, I don't use Abstract classes that often, but considering they
> are a foundation on which to build concrete classes (presumably to take
> care of many of the nitty gritty details and leave the concrete classes
> to implement specifics), I don't mind using a class suffix. "Abstract"
> feels like Hungarian notation, though.
>
> Based on my experiences writing code, I'm currently recommending that we
> do the following:
>
>  3. Use adjective/noun names for Interfaces such as "Foobarable",
>    "Foobarist"
>  7. Suffix abstract classes with "Base" ("FoobarableBase")
>
> The above solve most issues - names are reasonably sized, don't smack of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
> most importantly, meaningful. Since we already implement code review for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.
>
> Thoughts? Votes?
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--001485f196ec2c5bad0481dca052
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Howdy,<br><br>I think adjective/noun names for interfaces are ideal because=
 they are far more inline with the naming conventions already used in SPL, =
and I think that is something we should be striving to do wherever possible=
.<br>
<br>I support prefixes for abstract classes rather than suffixes, but it se=
ems that has long been shot down as an option.<br><br>Regardless of whether=
 we do prefixes or suffixes though, I think we should use the word &quot;Ab=
stract&quot; rather than &quot;Base&quot;.=A0 All programmatic dogma aside,=
 if I were to describe an abstract class to someone else (take an abstract =
Triangle class), I would tell the person that this is an abstract represent=
ation of a triangle; I wouldn&#39;t say it is a base representation of a tr=
iangle.=A0 If you&#39;re going to cite hungarian notation as the reason for=
 not using the word &quot;abstract&quot;, then I don&#39;t know how you can=
 justify using any keyword to denote that it is abstract.<br>
<br>-Court<br><br><div class=3D"gmail_quote">On Mon, Mar 15, 2010 at 3:58 P=
M, Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:matt=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
Hey, all --<br>
<br>
I know this has been hashed out a fair bit already, and we&#39;ve already<b=
r>
established some guidelines, but as I play with code for ZF2, I&#39;m<br>
beginning to question the naming conventions for Interfaces and Abstract<br=
Classes.<br>
<br>
When we made the decisions before, we were looking at the following<br>
three options for interfaces:<br>
<br>
=A01. Prefix interfaces with &quot;I&quot; (&quot;IFoobar&quot;).<br>
=A02. Suffix interfaces with &quot;Interface&quot; (&quot;FoobarInterface&q=
uot;)<br>
=A03. Use adjective/noun names such as &quot;Foobarable&quot;, &quot;Foobar=
ist&quot;<br>
<br>
For abstract classes, we looked at:<br>
<br>
=A04. Prefix abstract classes with &quot;A&quot; (&quot;AFoobar&quot;)<br>
=A05. Suffix abstract classes with &quot;Abstract&quot; (&quot;FoobarAbstra=
ct&quot;)<br>
=A06. Prefix abstract classes with &quot;Base&quot; (&quot;BaseFoobar&quot;=
)<br>
=A07. Suffix abstract classes with &quot;Base&quot; (&quot;FoobarBase&quot;=
)<br>
=A08. Use normal class names (&quot;Foobar&quot;)<br>
<br>
Regarding 1, 2, and 4-7, the arguments against were fairly numerous:<br>
they smack of Hungarian Notation, the long forms lead to really long<br>
names, etc. Prefixing can lead to similar classes not being grouped when<br=
doing directory listings (i.e., all abstract class or interface files<br>
get clustered together). Also, for classes beginning with &quot;I&quot; or =
&quot;A&quot;,<br>
there can potentially be confusion over whether or not the given class<br>
is supposed to be concrete. Finally, during refactoring, if you choose<br>
to make an interface an abstract class or concrete class, or an abstract<br=
class an interface or concrete class, you can&#39;t do so without renaming<=
br>
files and classes. (That said, you&#39;ll most likely need to make other<br=
changes anyways -- and ZF will likely never make an interface an<br>
abstract class or vice versa.)<br>
<br>
Regarding 3 and 8, the primary problems are that it&#39;s often hard to com=
e<br>
up with meaningful names that do not conflict with concrete<br>
implementations, and that for non-native English speakers, this latter<br>
problem becomes an even bigger obstacle. Additionally, you can&#39;t<br>
determine which files contain abstract classes and/or interfaces just by<br=
the filename -- you have to look in the file or look in API<br>
documentation to determine this information.<br>
<br>
Now, as to the issues I&#39;ve seen: the word &quot;Interface&quot; becomes=
 a real<br>
pain to type (yes, even with autocompletion), and it doesn&#39;t really<br>
connote any real information. When type-hinting, I simply know what type<br=
I want to use -- the name doesn&#39;t need to tell me it&#39;s an interface=
, as<br>
I already know that information. If I&#39;m writing code that consumes or<b=
r>
interacts with the class, API docs will tell me what I need to do.<br>
<br>
That said, I don&#39;t use Abstract classes that often, but considering the=
y<br>
are a foundation on which to build concrete classes (presumably to take<br>
care of many of the nitty gritty details and leave the concrete classes<br>
to implement specifics), I don&#39;t mind using a class suffix. &quot;Abstr=
act&quot;<br>
feels like Hungarian notation, though.<br>
<br>
Based on my experiences writing code, I&#39;m currently recommending that w=
e<br>
do the following:<br>
<br>
=A03. Use adjective/noun names for Interfaces such as &quot;Foobarable&quot=
;,<br>
 =A0 =A0&quot;Foobarist&quot;<br>
=A07. Suffix abstract classes with &quot;Base&quot; (&quot;FoobarableBase&q=
uot;)<br>
<br>
The above solve most issues - names are reasonably sized, don&#39;t smack o=
f<br>
Hungarian Notation (okay, so the &quot;Base&quot; verbiage kind of does), a=
nd are,<br>
most importantly, meaningful. Since we already implement code review for<br=
any code coming into trunk, I think we can even solve the issues for<br>
non-native speakers as well.<br>
<br>
Thoughts? Votes?<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</font></blockquote></div><br>

--001485f196ec2c5bad0481dca052--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 12 Jan 2010 08:15:03 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] CLA approval

-- drm <[email-masked]> wrote
(on Tuesday, 12 January 2010, 09:58 AM +0100):
> I have sent in my CLA almost two months ago now. I have tried to
> contact Matthew on this, but no response. I'm wondering what's going
> on. Do I need to send it in again? Can anybody help me on this?

How did you submit your CLA -- via email, postal service, or FAX? Once I
have that information (forgive me if you've told me before), I'll check
with the person who processes them to determine the status.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: Andrew Thompson <[email-masked]>
Date: Thu, 12 Nov 2009 22:33:15 +0000
From: Andy Thompson <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

*Unified constructor
*Is the overhead in converting to camelCase worth using 
underscore_seperated keys? It would seem more practical to stick to 
camelCase as that requires minimal conversion to function standards.
*
**Exceptions*.
Interesting use of exception intefaces and namespaces, I like the 
possibilities of doing this.

*Design By Contract*.
I agree that ZF should use interfaces a lot more in the library, 
especially for things like Zend_Db_Adapter. There have been many times 
that I've been frustrated that I have to subclass an abstract that I 
have to override all the functions. These cases tend to be where the 
abstract is fullfilling the role of an interface, so an interface placed 
there wont cause additional overhead.

This also helps with writing proxy classes that still need to use the 
framework's implementations.

*Elimination of most singletons*.
I agree, Singletons are just as bad as having globals. In most cases it 
should be up to the developer what should be accessible like this. I 
tend to try to only have a single top level class (Application.php), 
which defines the application's globals, and passes these into the 
component classes.

*Usage of new language features within plugin architectures
*Definitely, I see these features as a much needed improvement to the 
php language, and ZF supporting them just makes it easier

*Autoload-only
*I'm a recent convert to the autoload process, so yes I like this idea

*goto
*(cringe) but I guess if it makes things structurally better sense
*

Regards

Andy
*

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 1 Mar 2010 11:55:18 +0100
From: Giorgio Sironi <[email-masked]>
To: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

--0016e64986d2b495d50480bb15e7
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 1, 2010 at 11:23 AM, Julien Pauli <[email-masked]>wrote:

> +1 for PEAR channel

Agree.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e64986d2b495d50480bb15e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Mar 1, 2010 at 11:23 AM, Julien Pauli <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">doctorrock83@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p=
adding-left: 1ex;">
+1 for PEAR channel<br></blockquote></div><br clear=3D"all">Agree.<br><br>-=
- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br><a href=3D"h=
ttp://giorgiosironi.blogspot.com">http://giorgiosironi.blogspot.com</a><br>
<a href=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgiosiro=
ni</a><br>

--0016e64986d2b495d50480bb15e7--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Oct 2009 13:00:06 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code Freeze Lifted - Start Testing!

Code Freeze for 1.9.4 is now lifted. 

If you want to start testing before official packages are created, you
can point to the tag:

    http://framework.zend.com/svn/framework/standard/tags/release-1.9.4/

I should be posting sanity check packages in 3-4 hours.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 05 Jul 2009 17:56:21 +0200
From: Ralf Eggert <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Two Proposals Ready for Review

Thanks Benjamin,

Benjamin Eberlei schrieb am 05.07.2009 17:31:
> to my knowledge there will definately be a 1.10, and even a slight chance that 
> there will be a 1.11

Ok, but will 2.0 be published after 1.10 or 1.11. or will be both major
release be managed parallel?

Thanks and best regards,

Ralf

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 11 Nov 2009 12:12:07 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0-1689180776-1257970327=:92039
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

+1 to Benjamin's idea - though as a standalone script each maintainer can r=
un in isolation per component (provide time for review/documentation change=
s). This is really a cleanup exercise more than anything - I'm guessing mor=
e than a few maintainers will not be sure of the 5.3 changes just yet. I kn=
ow I messed up a bit on Zend_Feed_Reader scarcely days before the 1.9 relea=
se because of my own lack of attention on 5.3 minutiae.=0A=0AIs 5.3 address=
ed anywhere in the coding standard yet?=0A=0APaddy=0A=0A P=E1draic Brady=0A=
=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID=
 Europe Foundation Irish Representative=0A=0A=0A=0A=0A=0A__________________=
______________=0AFrom: Benjamin Eberlei <[email-masked]>=0ATo: zf-cont=
[email-masked]=0ASent: Wed, November 11, 2009 7:06:10 PM=0ASubject=
: Re: [zf-contributors] Zend Framework 2.0 Roadmap=0A=0Alooks great!=0A=0Ah=
ow will we conceptionally move from php 5.x to 5.3? might it be a good idea=
 =0Ato implement a rough tokenizer =3D> transformer to apply for example th=
e =0Afollowing rules:=0A=0A1. collect all classes and interfaces using Refl=
ection and Zend_Reflection_File.=0A=0APackage_Subpackage_Class =3D> Package=
\Subpackage\Class=0A=0Aif(Class =3D=3D Abstract)=0AClass =3D SubpackageAbst=
ract=0A=0Aif(Class =3D=3D Interface)=0AClass =3D Subpackage=0A=0Aif(Class =
=3D=3D Exception)=0Aclass =3D ExceptionImpl implements Exception=0A+ Interf=
ace Exception=0A=0A2. Define all exceptions to this rule in a simple array =
map (important for most =0Aof the interfaces).=0A=0A3. iterate over the cod=
e with a tokenizer on a file basis, find all INTERFACE =0Aand CLASS tokens =
and when re-applying them to the file change with the new =0Acode.=0A=0AImh=
o this would be better than to ask all the maintainers to make the =0Amigra=
tion, since that will probably take several months and make it incredible =
=0Ahard to work with the trunk.=0A=0Agreetings,=0ABenjamin=0A=0AOn Wednesda=
y 11 November 2009 07:38:57 pm Matthew Weier O'Phinney wrote:=0A> Hey, all =
--=0A>=0A> There have been a ton of questions about the ZF 2.0 roadmap, and=
 my=0A> answer has been consistently, "I'm working on it; I'll have somethi=
ng to=0A> publish soon."=0A>=0A> "Soon" is now:=0A>=0A>    =0A> http://fram=
ework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap=0A>=0A> I'd l=
ike you, as contributors, to look over it, and start discussing the=0A> var=
ious ramifications; we can do that either in comments to the pages or=0A> o=
n this list.=0A>=0A> The roadmap is primarily a conceptual one right now, t=
hough a=0A> proof-of-concept has been created for the proposed MVC. I'd lik=
e to stay=0A> fairly high-level for now, and then start getting a flow of p=
roposals=0A> into the system for specific migration-related tasks.=0A>=0A> =
Thanks everyone who has provided me input over the past many months, and=0A=
> let's get started on the next generation of ZF!=0A=0A=0A-- =0ABenjamin Eb=
erlei=0Ahttp://www.beberlei.de=0A
--0-1689180776-1257970327=:92039
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">+1 to Benjamin's idea - though as a standalone script each mai=
ntainer can run in isolation per component (provide time for review/documen=
tation changes). This is really a cleanup exercise more than anything - I'm=
 guessing more than a few maintainers will not be sure of the 5.3 changes j=
ust yet. I know I messed up a bit on Zend_Feed_Reader scarcely days before =
the 1.9 release because of my own lack of attention on 5.3 minutiae.<br><br=
>Is 5.3 addressed anywhere in the coding standard yet?<br><br>Paddy<br><div=
>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-fam=
ily: times new roman,new york,times,serif;" size=3D"3"><span style=3D"font-=
weight: bold;">P=E1draic Brady<br><br></span></font><span style=3D"font-sty=
le: italic;"><font style=3D"font-family: times new roman,new york,times,ser=
if;"
 size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"http://blog.astru=
mfutura.com">http://blog.astrumfutura.com</a><br><a rel=3D"nofollow" target=
=3D"_blank" href=3D"http://www.survivethedeepend.com">http://www.survivethe=
deepend.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www=
.openideurope.eu/">OpenID Europe Foundation Irish Representative</a><br></f=
ont></span></span><div><br></div><div style=3D"font-family: times new roman=
,new york,times,serif; font-size: 12pt;"><br><div style=3D"font-family: tah=
oma,new york,times,serif; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"=
><hr size=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Benj=
amin Eberlei &lt;[email-masked]&gt;<br><b><span style=3D"font-weight: =
bold;">To:</span></b> [email-masked]<br><b><span style=3D"f=
ont-weight: bold;">Sent:</span></b> Wed, November 11, 2009 7:06:10 PM<br><b=
><span style=3D"font-weight: bold;">Subject:</span></b> Re: [zf-contributor=
s] Zend Framework 2.0
 Roadmap<br></font><br>=0Alooks great!<br><br>how will we conceptionally mo=
ve from php 5.x to 5.3? might it be a good idea <br>to implement a rough to=
kenizer =3D&gt; transformer to apply for example the <br>following rules:<b=
r><br>1. collect all classes and interfaces using Reflection and Zend_Refle=
ction_File.<br><br>Package_Subpackage_Class =3D&gt; Package\Subpackage\Clas=
s<br><br>if(Class =3D=3D Abstract)<br>Class =3D SubpackageAbstract<br><br>i=
f(Class =3D=3D Interface)<br>Class =3D Subpackage<br><br>if(Class =3D=3D Ex=
ception)<br>class =3D ExceptionImpl implements Exception<br>+ Interface Exc=
eption<br><br>2. Define all exceptions to this rule in a simple array map (=
important for most <br>of the interfaces).<br><br>3. iterate over the code =
with a tokenizer on a file basis, find all INTERFACE <br>and CLASS tokens a=
nd when re-applying them to the file change with the new <br>code.<br><br>I=
mho this would be better than to ask all the maintainers to make the <br>mi=
gration, since that will probably take
 several months and make it incredible <br>hard to work with the trunk.<br>=
<br>greetings,<br>Benjamin<br><br>On Wednesday 11 November 2009 07:38:57 pm=
 Matthew Weier O'Phinney wrote:<br>&gt; Hey, all --<br>&gt;<br>&gt; There h=
ave been a ton of questions about the ZF 2.0 roadmap, and my<br>&gt; answer=
 has been consistently, "I'm working on it; I'll have something to<br>&gt; =
publish soon."<br>&gt;<br>&gt; "Soon" is now:<br>&gt;<br>&gt;&nbsp; &nbsp; =
<br><span>&gt; <a target=3D"_blank" href=3D"http://framework.zend.com/wiki/=
display/ZFDEV2/Zend+Framework+2.0+Roadmap">http://framework.zend.com/wiki/d=
isplay/ZFDEV2/Zend+Framework+2.0+Roadmap</a></span><br>&gt;<br>&gt; I'd lik=
e you, as contributors, to look over it, and start discussing the<br>&gt; v=
arious ramifications; we can do that either in comments to the pages or<br>=
&gt; on this list.<br>&gt;<br>&gt; The roadmap is primarily a conceptual on=
e right now, though a<br>&gt; proof-of-concept has been created for the
 proposed MVC. I'd like to stay<br>&gt; fairly high-level for now, and then=
 start getting a flow of proposals<br>&gt; into the system for specific mig=
ration-related tasks.<br>&gt;<br>&gt; Thanks everyone who has provided me i=
nput over the past many months, and<br>&gt; let's get started on the next g=
eneration of ZF!<br><br><br>-- <br>Benjamin Eberlei<br><span><a target=3D"_=
blank" href=3D"http://www.beberlei.de">http://www.beberlei.de</a></span><br=
></div></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compressed/chunked Wed Nov=
 11 03:16:09 PST 2009 -->=0A</div></body></html>
--0-1689180776-1257970327=:92039--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 17:38:38 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Kevin McArthur <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0-2127204276-1258076318=:42886
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>I doubt this greatly, ZF to 1.0 was a huge success and had none of this=0A=
stuff. A decent vetting by interested coders was all it took to keep=0Athe =
quality up. Most of that =0A>code still comprises the code base today,=0Aan=
d it still runs fine. The docs were enough to get interested=0Adevelopers o=
ver the initial hurdles and the rest came through other =0A>sources like bl=
ogs, irc, books and sample code. I'm not saying we go=0Aback to totally unt=
ested code or anything like that, I guess I just see=0Atests like icing, no=
t an =0A>ingredient. If there's tests, great, if not,=0Aput it on the todo =
and move on. Instead we've got tests that are at=0Atimes even counter-produ=
ctive as you describe.=0A=0AThat's a massively misleading statement. I was =
around pre-1.0 too. The number of components and lines-of-code were a tiny =
fraction of what currently exists, and oddly enough, even at that there wer=
e tests and docs. ZF 0.x without those would never have been a success. Cou=
nter-productive tests are a problem - unfortunately overview has been lacki=
ng in the past otherwise they'd have been noticed a lot sooner. Not to drag=
 this into a present context - as far as I know Matthew does review new tes=
t suites as part of the review process.=0A=0A>I'd argue that some of those =
components are bad in part because of the=0Arequirement.=0A=0ANo, they are =
bad in spite of the requirement. Tests, docs or nothing at all - bad code i=
s bad code.=0A=0A>That assumes that a large amount of this work isn't optio=
nal -- when it=0Ais. Those useless tests are there because someone said 'mu=
st have=0Atests', many, possibly most, of =0A>them are totally unneeded exc=
ept to up=0Athe code coverage report statistics. A minority of the ZFW test=
s do any=0Auseful testing, and for those, I'm glad there's tests... and I =
=0A>believe=0Athose tests would still be there if they weren't required to =
be.=0A=0AI agree the code coverage is sometimes horribly artificial (person=
ally I believe a coverage of 60% is acceptable in a lot of cases - I do add=
 stupid little tests to get to 85% like testing getters (ye gods) or worse)=
. It's always a complaint when I run code coverage on a shiny new class and=
 it pops a 55% coverage ;). I know the tests are sufficient but a rule is a=
 rule since, as many tests prove, you really can't trust all developers. Ev=
en I make silly typos at times - even in dumb getters sometimes.=0A=0ANever=
theless, whether the rule adds work or not - the point is that the work mus=
t get done one way or another before any contribution can be committed to t=
runk for the next release.=0A=0A>I suspect many wont expect their contribut=
ions to be accepted -- and=0Ainstead of capitulating to the requirements, w=
ill simply abandon the=0Acontribution.=0A=0AAlready happening to be honest.=
 Unfortunately, I'm unwilling to vet every single contribution and patch, a=
nd so are the contributors. It's going to happen a lot.=0A=0A>I think you j=
ust made my point.=0A=0ARest of quote? ;) The front controller is just anot=
her object - how do you get any other object in whatever class you need it?=
 It's not something magical...=0A=0A>I'd hate to think what it=0Awould take=
 to get a class as complicated as=0AZend_Pdf_Resource_Image_Tiff committed =
today....=0A=0AProbably the same effort - with testing. I'm a fan of TDD th=
ough so I'm totally biased in favour of a test driven approach - I've yet t=
o find anything too complex to handle with it.=0A=0A>We agree here. Today i=
s too complicated... Tomorrow will be too=0Acomplicated... I was hoping wit=
h 2.0 that we would figure out where the=0Aredundancies are and nix em >-->=
 i'd start at the actionstack, but=0Athats just me. Now we're talking FSM's=
, and DI systems... which is cool=0Ain a compsci kinda way, but fantastical=
ly complicated out of >the box.=0A>Is it a SDK, a black box, or are we help=
ing people make applications=0Athey understand? Whats the implication of bl=
ind use of the framework?=0A=0ASame could be said of namespaces, closures, =
all that other compsci ECMA stuff. DI and FSM are not complicated or weird =
or conceptually difficult - they are merely different. What we have at the =
moment is more familiar - and a mess. Unfortunately, ZF or not, MVC is alwa=
ys going to be more complicated as it needs more features. The C part of MV=
C remains the most expensive part of ZF performance wise. That won't change=
, but maybe the new concepts will help. They surely will NOT make it more c=
omplex. Whether it simplifies anything - open question to Matthew? ;)=0A=0A=
>Theres a reason we write books on this stuff instead of user docs.....=0A=
=0ADevs are horrible writers. Unrelated, but true! The manual has become a =
monster read.=0A=0A>"No" is a policy, and its not a very good one.=0A=0ADon=
't get me wrong - I agree it's not the best policy ever, but who's going to=
 contribute the resources to make the policy "yes"? In reality a "no" is th=
e only possible answer in an open source project with limited resources.=0A=
=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://w=
ww.survivethedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=
=0A=0A=0A=0A=0A________________________________=0AFrom: Kevin McArthur <kev=
[email-masked]>=0ATo: P=E1draic Brady <[email-masked]>=0ACc: Zend=
 Framework Contributors <[email-masked]>=0ASent: Fri, Novem=
ber 13, 2009 12:58:43 AM=0ASubject: Re: [zf-contributors] Zend Framework 2.=
0 Roadmap=0A=0A P=E1draic Brady wrote: =0A> =0A>=0A>>The main wall Kevin ju=
st hit is simply never going away. If it ever=0A>did, ZF wouldn't be far be=
hind it as a untested, undocumented morass of=0A>code that (allegedly) does=
 stuff. =0AI doubt this greatly, ZF to 1.0 was a huge success and had none =
of this=0Astuff. A decent vetting by interested coders was all it took to k=
eep=0Athe quality up. Most of that code still comprises the code base today=
,=0Aand it still runs fine. The docs were enough to get interested=0Adevelo=
pers over the initial hurdles and the rest came through other=0Asources lik=
e blogs, irc, books and sample code. I'm not saying we go=0Aback to totally=
 untested code or anything like that, I guess I just see=0Atests like icing=
, not an ingredient. If there's tests, great, if not,=0Aput it on the todo =
and move on. Instead we've got tests that are at=0Atimes even counter-produ=
ctive as you describe.=0A=0A=0AWe=0A>need all the "contribution overhead". =
It is absolutely essential. There=0A>are components in the ZF which, to be =
generous, are pretty bad in terms=0A>of testing, documentation and flexibil=
ity already - and that's with the=0A>requirement! I have worse descriptions=
. Catch me on IRC during a bug=0A>hunt and I'll share some ;).=0A>=0AI'd ar=
gue that some of those components are bad in part because of the=0Arequirem=
ent.=0A=0A=0A>>The fact is, if you cannot handle the additional work that u=
nderpins,=0A>supports and ensures ease of maintenance for a component - the=
n you are=0A>begging for a developer to start swearing over IRC. I had the =
joy of=0A>dealing with such a component a few weeks back. It took me hours =
to=0A>figure out a bug. Why? Because the unit tests DID NOT TEST the=0A>fun=
ctionality of the component. I could have deleted every single test=0A>with=
 no ill effect - they were all busy with XML parsing or something=0A>(perfo=
rmed by a completely different component with its own perfectly=0A>function=
al unit tests).=0A>=0AThat sounds about right.=0A=0A=0A>>But worse than all=
 this, is the assumption that lowering the=0A>contribution overhead is a po=
sitive thing. It's not - it merely shifts=0A>that work onto someone else. =
=0AThat assumes that a large amount of this work isn't optional -- when it=
=0Ais. Those useless tests are there because someone said 'must have=0Atest=
s', many, possibly most, of them are totally unneeded except to up=0Athe co=
de coverage report statistics. A minority of the ZFW tests do any=0Auseful =
testing, and for those, I'm glad there's tests... and I believe=0Athose tes=
ts would still be there if they weren't required to be.=0A=0ASomeone=0A>els=
e with precious little time and a chargeout rate to justify work=0A>with. A=
nd surprise - they won't like that in the slightest. Sometimes=0A>you get l=
ucky - I spent about 10 hours of otherwise chargeable time in=0A>September'=
s bug hunt (which I enjoyed a lot by the way) along with=0A>several evening=
s but generally everyday work will always lean towards=0A>ignoring contribu=
tions where no supporting "contribution overhead" has=0A>also been committe=
d. Such contributions/patches/whatever can be=0A>horrible to work on. No te=
sts, poor explanations, lack of=0A>communication, differing assumptions - u=
gh. If it's not worth=0A>contributing in full, don't expect someone else to=
 do it - they=0A>probably won't.=0A>=0AI suspect many wont expect their con=
tributions to be accepted -- and=0Ainstead of capitulating to the requireme=
nts, will simply abandon the=0Acontribution.=0A=0A=0A>>Sorry for the ranty =
piece - but code doesn't write itself. It is great=0A>to have a contributio=
n - so long as you don't pin it all on someone=0A>else ;).=0A>=0APin what? =
When I developed the Zend PDF image parsers for example, I=0Adidn't write a=
ny tests, I did functional testing to the best I=0Acould.... and we went fr=
om there. Those classes exist in the framework=0Atoday in basically the sam=
e format. That contribution process was very=0Adifferent from today, but it=
 worked great. I'd hate to think what it=0Awould take to get a class as com=
plicated as=0AZend_Pdf_Resource_Image_Tiff committed today....=0A=0A=0A>>Wh=
ich one? Nobody said there would be one front controller.=0AFor 99.999% of =
uses theres only one url, and only a need for one front=0Acontroller. =0A=
=0AMy=0A>guess, is that it will be accessible from your bootstrap, which is=
=0A>registered to the front controller, which is registered to...I'm lost=
=0A>now. =0AI think you just made my point.=0A=0A=0A>>Trace what under the =
hood?=0A>Request->Route->Dispatch->Controller->Action <- stick=0A>plugins i=
n between. It's not rocket science. =0AAdd into that Zend_Application->Zend=
_Config->Get Bootstrap Name=0ASetting->do whatever *secret sauce*->all befo=
re you get to the=0Amvc dispatch process above. Now, from the code source I=
 looked at=0Abefore, its going to require creating some sort of methodinvok=
ers,=0Aevent delegates and hooking into a series of events. Tracing back fr=
om=0Aoutput to figure out where something is happening truly is a science=
=0Athese days -- most of the time I end up pecking around in the leaves,=0A=
instead of tracing from the trunk. It gets even more complicated when=0Ayou=
 start talking partials, helpers( think actionstack ), and the=0Amyriad of =
other ways to inject into the request cycle. =0A=0AIf=0A>you doubled the co=
mplexity of the implementation today, it would still=0A>quack like the same=
 duck it was yesterday. =0AWe agree here. Today is too complicated... Tomor=
row will be too=0Acomplicated... I was hoping with 2.0 that we would figure=
 out where the=0Aredundancies are and nix em --> i'd start at the actionsta=
ck, but=0Athats just me. Now we're talking FSM's, and DI systems... which i=
s cool=0Ain a compsci kinda way, but fantastically complicated out of the b=
ox.=0A=0AIs it a SDK, a black box, or are we helping people make applicatio=
ns=0Athey understand? Whats the implication of blind use of the framework?=
=0A=0ARight=0A>now you can still conceptually grasp MVC and use it, without=
 ever=0A>reading the source code. In fact, right now MVC is a pretty comple=
x=0A>beast in ZF. It would take a serious effort to complicate it further :=
).=0A>=0ATheres a reason we write books on this stuff instead of user docs.=
.... =0A=0A=0A>>>Can a skilled PHP developer contribute a change to the fra=
mework=0A>easily=0A>>>without being involved in the ZFW core politics, cont=
ribution=0A>processes,=0A>>>proposal processes, test writing, doc writing, =
etc.=0A>=0A>>ZF may be one of the few non-political projects around. I've h=
ad some=0A>fun of course butting heads in the past, but the last two years =
have=0A>been politics free. Everything else is answered "no". Who else is g=
oing=0A>to miraculously write someone else's tests/docs/proposals? Not me :=
P.=0A>=0A"No" is a policy, and its not a very good one.=0A=0A$0.02=0A=0AKev=
in=0A
--0-2127204276-1258076318=:42886
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">&gt;I doubt this greatly, ZF to 1.0 was a huge success and had=
 none of this=0Astuff. A decent vetting by interested coders was all it too=
k to keep=0Athe quality up. Most of that <br>&gt;code still comprises the c=
ode base today,=0Aand it still runs fine. The docs were enough to get inter=
ested=0Adevelopers over the initial hurdles and the rest came through other=
=0A<br>&gt;sources like blogs, irc, books and sample code. I'm not saying w=
e go=0Aback to totally untested code or anything like that, I guess I just =
see=0Atests like icing, not an <br>&gt;ingredient. If there's tests, great,=
 if not,=0Aput it on the todo and move on. Instead we've got tests that are=
 at=0Atimes even counter-productive as you describe.<br><br>That's a massiv=
ely misleading statement. I was around pre-1.0 too. The number of component=
s and lines-of-code were a tiny fraction of what currently exists, and oddl=
y enough, even at that there were tests and docs. ZF 0.x without those woul=
d never have been a success. Counter-productive tests are a problem - unfor=
tunately overview has been lacking in the past otherwise they'd have been n=
oticed a lot sooner. Not to drag this into a present context - as far as I =
know Matthew does review new test suites as part of the review process.<br>=
<br>&gt;I'd argue that some of those components are bad in part because of =
the=0Arequirement.<br><br>No, they are bad in spite of the requirement. Tes=
ts, docs or nothing at all - bad code is bad code.<br><br>&gt;That assumes =
that a large amount of this work isn't optional -- when it=0Ais. Those usel=
ess tests are there because someone said 'must have=0Atests', many, possibl=
y most, of <br>&gt;them are totally unneeded except to up=0Athe code covera=
ge report statistics. A minority of the ZFW tests do any=0Auseful testing, =
and for those, I'm glad there's tests... and I <br>&gt;believe=0Athose test=
s would still be there if they weren't required to be.<br><br>I agree the c=
ode coverage is sometimes horribly artificial (personally I believe a cover=
age of 60% is acceptable in a lot of cases - I do add stupid little tests t=
o get to 85% like testing getters (ye gods) or worse). It's always a compla=
int when I run code coverage on a shiny new class and it pops a 55% coverag=
e ;). I know the tests are sufficient but a rule is a rule since, as many t=
ests prove, you really can't trust all developers. Even I make silly typos =
at times - even in dumb getters sometimes.<br><br>Nevertheless, whether the=
 rule adds work or not - the point is that the work must get done one way o=
r another before any contribution can be committed to trunk for the next re=
lease.<br><br>&gt;I suspect many wont expect their contributions to be acce=
pted -- and=0Ainstead of capitulating to the requirements, will simply aban=
don the=0Acontribution.<br><br>Already happening to be honest. Unfortunatel=
y, I'm unwilling to vet every single contribution and patch, and so are the=
 contributors. It's going to happen a lot.<br><br>&gt;I think you just made=
 my point.<br><br>Rest of quote? ;) The front controller is just another ob=
ject - how do you get any other object in whatever class you need it? It's =
not something magical...<br><br>&gt;I'd hate to think what it=0Awould take =
to get a class as complicated as=0AZend_Pdf_Resource_Image_Tiff committed t=
oday....<br><br>Probably the same effort - with testing. I'm a fan of TDD t=
hough so I'm totally biased in favour of a test driven approach - I've yet =
to find anything too complex to handle with it.<br><br>&gt;We agree here. T=
oday is too complicated... Tomorrow will be too=0Acomplicated... I was hopi=
ng with 2.0 that we would figure out where the=0Aredundancies are and nix e=
m &gt;--&gt; i'd start at the actionstack, but=0Athats just me. Now we're t=
alking FSM's, and DI systems... which is cool=0Ain a compsci kinda way, but=
 fantastically complicated out of &gt;the box.<br>=0A&gt;Is it a SDK, a bla=
ck box, or are we helping people make applications=0Athey understand? Whats=
 the implication of blind use of the framework?<br><br>Same could be said o=
f namespaces, closures, all that other compsci ECMA stuff. DI and FSM are n=
ot complicated or weird or conceptually difficult - they are merely differe=
nt. What we have at the moment is more familiar - and a mess. Unfortunately=
, ZF or not, MVC is always going to be more complicated as it needs more fe=
atures. The C part of MVC remains the most expensive part of ZF performance=
 wise. That won't change, but maybe the new concepts will help. They surely=
 will NOT make it more complex. Whether it simplifies anything - open quest=
ion to Matthew? ;)<br><br>&gt;Theres a reason we write books on this stuff =
instead of user docs.....<br><br>Devs are horrible writers. Unrelated, but =
true! The manual has become a monster read.<br><br>&gt;"No" is a policy, an=
d its not a very good one.<br><br>Don't get me wrong - I agree it's not the=
 best policy ever, but who's going to
 contribute the resources to make the policy "yes"? In reality a "no" is th=
e only possible answer in an open source project with limited resources.<br=
><br>Paddy<br><br>&nbsp;<span style=3D"color: rgb(0, 0, 191);"><font style=
=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><span st=
yle=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span style=
=3D"font-style: italic;"><font style=3D"font-family: times new roman,new yo=
rk,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"h=
ttp://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a rel=3D"=
nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com">http:=
//www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_blank" hr=
ef=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Represent=
ative</a><br></font></span></span><div><br></div><div style=3D"font-family:=
 times new roman,new york,times,serif; font-size: 12pt;"><br><div style=3D"=
font-family: times new
 roman,new york,times,serif; font-size: 12pt;"><font face=3D"Tahoma" size=
=3D"2"><hr size=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b=
> Kevin McArthur &lt;[email-masked]&gt;<br><b><span style=3D"font-weigh=
t: bold;">To:</span></b> P=E1draic Brady &lt;[email-masked]&gt;<br=
><b><span style=3D"font-weight: bold;">Cc:</span></b> Zend Framework Contri=
butors &lt;[email-masked]&gt;<br><b><span style=3D"font-wei=
ght: bold;">Sent:</span></b> Fri, November 13, 2009 12:58:43 AM<br><b><span=
 style=3D"font-weight: bold;">Subject:</span></b> Re: [zf-contributors] Zen=
d Framework 2.0 Roadmap<br></font><br>=0A<meta http-equiv=3D"x-dns-prefetch=
-control" content=3D"off">=0A=0A=0A  =0A=0AP=E1draic Brady wrote:=0A<blockq=
uote type=3D"cite">=0A  =0A  <div style=3D"font-family: times new roman,new=
 york,times,serif; font-size: 12pt;"><br>=0AThe main wall Kevin just hit is=
 simply never going away. If it ever=0Adid, ZF wouldn't be far behind it as=
 a untested, undocumented morass of=0Acode that (allegedly) does stuff. </d=
iv>=0A</blockquote>=0AI doubt this greatly, ZF to 1.0 was a huge success an=
d had none of this=0Astuff. A decent vetting by interested coders was all i=
t took to keep=0Athe quality up. Most of that code still comprises the code=
 base today,=0Aand it still runs fine. The docs were enough to get interest=
ed=0Adevelopers over the initial hurdles and the rest came through other=0A=
sources like blogs, irc, books and sample code. I'm not saying we go=0Aback=
 to totally untested code or anything like that, I guess I just see=0Atests=
 like icing, not an ingredient. If there's tests, great, if not,=0Aput it o=
n the todo and move on. Instead we've got tests that are at=0Atimes even co=
unter-productive as you describe.<br>=0A<br>=0A<blockquote type=3D"cite">=
=0A  <div style=3D"font-family: times new roman,new york,times,serif; font-=
size: 12pt;">We=0Aneed all the "contribution overhead". It is absolutely es=
sential. There=0Aare components in the ZF which, to be generous, are pretty=
 bad in terms=0Aof testing, documentation and flexibility already - and tha=
t's with the=0Arequirement! I have worse descriptions. Catch me on IRC duri=
ng a bug=0Ahunt and I'll share some ;).<br>=0A  </div>=0A</blockquote>=0A<b=
r>=0AI'd argue that some of those components are bad in part because of the=
=0Arequirement.<br>=0A<blockquote type=3D"cite">=0A  <div style=3D"font-fam=
ily: times new roman,new york,times,serif; font-size: 12pt;"><br>=0AThe fac=
t is, if you cannot handle the additional work that underpins,=0Asupports a=
nd ensures ease of maintenance for a component - then you are=0Abegging for=
 a developer to start swearing over IRC. I had the joy of=0Adealing with su=
ch a component a few weeks back. It took me hours to=0Afigure out a bug. Wh=
y? Because the unit tests DID NOT TEST the=0Afunctionality of the component=
. I could have deleted every single test=0Awith no ill effect - they were a=
ll busy with XML parsing or something=0A(performed by a completely differen=
t component with its own perfectly=0Afunctional unit tests).<br>=0A  </div>=
=0A</blockquote>=0AThat sounds about right.<br>=0A<blockquote type=3D"cite"=
>=0A  <div style=3D"font-family: times new roman,new york,times,serif; font=
-size: 12pt;"><br>=0ABut worse than all this, is the assumption that loweri=
ng the=0Acontribution overhead is a positive thing. It's not - it merely sh=
ifts=0Athat work onto someone else. </div>=0A</blockquote>=0AThat assumes t=
hat a large amount of this work isn't optional -- when it=0Ais. Those usele=
ss tests are there because someone said 'must have=0Atests', many, possibly=
 most, of them are totally unneeded except to up=0Athe code coverage report=
 statistics. A minority of the ZFW tests do any=0Auseful testing, and for t=
hose, I'm glad there's tests... and I believe=0Athose tests would still be =
there if they weren't required to be.<br>=0A<blockquote type=3D"cite">=0A  =
<div style=3D"font-family: times new roman,new york,times,serif; font-size:=
 12pt;">Someone=0Aelse with precious little time and a chargeout rate to ju=
stify work=0Awith. And surprise - they won't like that in the slightest. So=
metimes=0Ayou get lucky - I spent about 10 hours of otherwise chargeable ti=
me in=0ASeptember's bug hunt (which I enjoyed a lot by the way) along with=
=0Aseveral evenings but generally everyday work will always lean towards=0A=
ignoring contributions where no supporting "contribution overhead" has=0Aal=
so been committed. Such contributions/patches/whatever can be=0Ahorrible to=
 work on. No tests, poor explanations, lack of=0Acommunication, differing a=
ssumptions - ugh. If it's not worth=0Acontributing in full, don't expect so=
meone else to do it - they=0Aprobably won't.<br>=0A  </div>=0A</blockquote>=
=0AI suspect many wont expect their contributions to be accepted -- and=0Ai=
nstead of capitulating to the requirements, will simply abandon the=0Acontr=
ibution.<br>=0A<blockquote type=3D"cite">=0A  <div style=3D"font-family: ti=
mes new roman,new york,times,serif; font-size: 12pt;"><br>=0ASorry for the =
ranty piece - but code doesn't write itself. It is great=0Ato have a contri=
bution - so long as you don't pin it all on someone=0Aelse ;).<br>=0A  </di=
v>=0A</blockquote>=0APin what? When I developed the Zend PDF image parsers =
for example, I=0Adidn't write any tests, I did functional testing to the be=
st I=0Acould.... and we went from there. Those classes exist in the framewo=
rk=0Atoday in basically the same format. That contribution process was very=
=0Adifferent from today, but it worked great. I'd hate to think what it=0Aw=
ould take to get a class as complicated as=0AZend_Pdf_Resource_Image_Tiff c=
ommitted today....<br>=0A<blockquote type=3D"cite">=0A  <div style=3D"font-=
family: times new roman,new york,times,serif; font-size: 12pt;"><br>=0AWhic=
h one? Nobody said there would be one front controller.</div>=0A</blockquot=
e>=0AFor 99.999% of uses theres only one url, and only a need for one front=
=0Acontroller. <br>=0A<blockquote type=3D"cite">=0A  <div style=3D"font-fam=
ily: times new roman,new york,times,serif; font-size: 12pt;">My=0Aguess, is=
 that it will be accessible from your bootstrap, which is=0Aregistered to t=
he front controller, which is registered to...I'm lost=0Anow. </div>=0A</bl=
ockquote>=0AI think you just made my point.<br>=0A<blockquote type=3D"cite"=
>=0A  <div style=3D"font-family: times new roman,new york,times,serif; font=
-size: 12pt;"><br>=0ATrace what under the hood?=0ARequest-&gt;Route-&gt;Dis=
patch-&gt;Controller-&gt;Action &lt;- stick=0Aplugins in between. It's not =
rocket science. </div>=0A</blockquote>=0AAdd into that Zend_Application-&gt=
;Zend_Config-&gt;Get Bootstrap Name=0ASetting-&gt;do whatever *secret sauce=
*-&gt;all before you get to the=0Amvc dispatch process above. Now, from the=
 code source I looked at=0Abefore, its going to require creating some sort =
of methodinvokers,=0Aevent delegates and hooking into a series of events. T=
racing back from=0Aoutput to figure out where something is happening truly =
is a science=0Athese days -- most of the time I end up pecking around in th=
e leaves,=0Ainstead of tracing from the trunk. It gets even more complicate=
d when=0Ayou start talking partials, helpers( think actionstack ), and the=
=0Amyriad of other ways to inject into the request cycle. <br>=0A<blockquot=
e type=3D"cite">=0A  <div style=3D"font-family: times new roman,new york,ti=
mes,serif; font-size: 12pt;">If=0Ayou doubled the complexity of the impleme=
ntation today, it would still=0Aquack like the same duck it was yesterday. =
</div>=0A</blockquote>=0AWe agree here. Today is too complicated... Tomorro=
w will be too=0Acomplicated... I was hoping with 2.0 that we would figure o=
ut where the=0Aredundancies are and nix em --&gt; i'd start at the actionst=
ack, but=0Athats just me. Now we're talking FSM's, and DI systems... which =
is cool=0Ain a compsci kinda way, but fantastically complicated out of the =
box.<br>=0A<br>=0AIs it a SDK, a black box, or are we helping people make a=
pplications=0Athey understand? Whats the implication of blind use of the fr=
amework?<br>=0A<blockquote type=3D"cite">=0A  <div style=3D"font-family: ti=
mes new roman,new york,times,serif; font-size: 12pt;">Right=0Anow you can s=
till conceptually grasp MVC and use it, without ever=0Areading the source c=
ode. In fact, right now MVC is a pretty complex=0Abeast in ZF. It would tak=
e a serious effort to complicate it further :).<br>=0A  </div>=0A</blockquo=
te>=0ATheres a reason we write books on this stuff instead of user docs....=
. <br>=0A<blockquote type=3D"cite">=0A  <div style=3D"font-family: times ne=
w roman,new york,times,serif; font-size: 12pt;"><br>=0A&gt;Can a skilled PH=
P developer contribute a change to the framework=0Aeasily<br>=0A&gt;without=
 being involved in the ZFW core politics, contribution=0Aprocesses,<br>=0A&=
gt;proposal processes, test writing, doc writing, etc.<br>=0A  <br>=0AZF ma=
y be one of the few non-political projects around. I've had some=0Afun of c=
ourse butting heads in the past, but the last two years have=0Abeen politic=
s free. Everything else is answered "no". Who else is going=0Ato miraculous=
ly write someone else's tests/docs/proposals? Not me :P.<br>=0A  </div>=0A<=
/blockquote>=0A"No" is a policy, and its not a very good one.<br>=0A<br>=0A=
$0.02<br>=0A<br>=0AKevin<br>=0A<meta http-equiv=3D"x-dns-prefetch-control" =
content=3D"on"></div></div>=0A<!-- cg4.c902.mail.ac4.yahoo.com compressed/c=
hunked Thu Nov 12 08:24:37 PST 2009 -->=0A</div></body></html>
--0-2127204276-1258076318=:42886--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Eric Clemmons <[email-masked]>
Date: Mon, 15 Mar 2010 16:14:52 -0500
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

--Apple-Mail-4-470199878
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I agree with Abstract as it ties closely with the naming scheme that =
many learned in other OO languages.  Base tends (in Javascript modules =
and PHP) to contain application-specific (non-portable) code while =
Abstract is self-contained.

I am curious about the dangers of "Foobarable" notation, which reminds =
me of the issues Django Admin has when you have a "Company" object which =
is pluralized in "Companies".  Should we perform most new file creation =
through Zend Tool, I would think this would be problematic.

</2 cents>

-Eric Clemmons

On Mar 15, 2010, at 4:03 PM, P=E1draic Brady wrote:

> I agree with Matthew on the rest, except that, as with Court, I prefer =
Abstract to Base. Longer term albeit, it makes more sense than Base =
which can suggest a broader use meaning (e.g. a non-Abstract super =
class). Under that meaning, Base can be any parent class so the =
indication of a class being Abstract is no longer a certainty without =
referring to API docs (or the code itself).
>=20
> Paddy
> =20
> P=E1draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>=20
>=20
> From: Court Ewing <[email-masked]>
> To: [email-masked]
> Sent: Mon, March 15, 2010 8:21:26 PM
> Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming =
conventions
>=20
> Howdy,
>=20
> I think adjective/noun names for interfaces are ideal because they are =
far more inline with the naming conventions already used in SPL, and I =
think that is something we should be striving to do wherever possible.
>=20
> I support prefixes for abstract classes rather than suffixes, but it =
seems that has long been shot down as an option.
>=20
> Regardless of whether we do prefixes or suffixes though, I think we =
should use the word "Abstract" rather than "Base".  All programmatic =
dogma aside, if I were to describe an abstract class to someone else =
(take an abstract Triangle class), I would tell the person that this is =
an abstract representation of a triangle; I wouldn't say it is a base =
representation of a triangle.  If you're going to cite hungarian =
notation as the reason for not using the word "abstract", then I don't =
know how you can justify using any keyword to denote that it is =
abstract.
>=20
> -Court
>=20
> On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney =
<[email-masked]> wrote:
> Hey, all --
>=20
> I know this has been hashed out a fair bit already, and we've already
> established some guidelines, but as I play with code for ZF2, I'm
> beginning to question the naming conventions for Interfaces and =
Abstract
> Classes.
>=20
> When we made the decisions before, we were looking at the following
> three options for interfaces:
>=20
>  1. Prefix interfaces with "I" ("IFoobar").
>  2. Suffix interfaces with "Interface" ("FoobarInterface")
>  3. Use adjective/noun names such as "Foobarable", "Foobarist"
>=20
> For abstract classes, we looked at:
>=20
>  4. Prefix abstract classes with "A" ("AFoobar")
>  5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>  6. Prefix abstract classes with "Base" ("BaseFoobar")
>  7. Suffix abstract classes with "Base" ("FoobarBase")
>  8. Use normal class names ("Foobar")
>=20
> Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
> they smack of Hungarian Notation, the long forms lead to really long
> names, etc. Prefixing can lead to similar classes not being grouped =
when
> doing directory listings (i.e., all abstract class or interface files
> get clustered together). Also, for classes beginning with "I" or "A",
> there can potentially be confusion over whether or not the given class
> is supposed to be concrete. Finally, during refactoring, if you choose
> to make an interface an abstract class or concrete class, or an =
abstract
> class an interface or concrete class, you can't do so without renaming
> files and classes. (That said, you'll most likely need to make other
> changes anyways -- and ZF will likely never make an interface an
> abstract class or vice versa.)
>=20
> Regarding 3 and 8, the primary problems are that it's often hard to =
come
> up with meaningful names that do not conflict with concrete
> implementations, and that for non-native English speakers, this latter
> problem becomes an even bigger obstacle. Additionally, you can't
> determine which files contain abstract classes and/or interfaces just =
by
> the filename -- you have to look in the file or look in API
> documentation to determine this information.
>=20
> Now, as to the issues I've seen: the word "Interface" becomes a real
> pain to type (yes, even with autocompletion), and it doesn't really
> connote any real information. When type-hinting, I simply know what =
type
> I want to use -- the name doesn't need to tell me it's an interface, =
as
> I already know that information. If I'm writing code that consumes or
> interacts with the class, API docs will tell me what I need to do.
>=20
> That said, I don't use Abstract classes that often, but considering =
they
> are a foundation on which to build concrete classes (presumably to =
take
> care of many of the nitty gritty details and leave the concrete =
classes
> to implement specifics), I don't mind using a class suffix. "Abstract"
> feels like Hungarian notation, though.
>=20
> Based on my experiences writing code, I'm currently recommending that =
we
> do the following:
>=20
>  3. Use adjective/noun names for Interfaces such as "Foobarable",
>    "Foobarist"
>  7. Suffix abstract classes with "Base" ("FoobarableBase")
>=20
> The above solve most issues - names are reasonably sized, don't smack =
of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and =
are,
> most importantly, meaningful. Since we already implement code review =
for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.
>=20
> Thoughts? Votes?
>=20
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>=20
>=20

--Apple-Mail-4-470199878
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head><base href=3D"x-msg://67/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div>I agree with Abstract as it ties closely with =
the naming scheme that many learned in other OO languages. &nbsp;Base =
tends (in Javascript modules and PHP) to contain application-specific =
(non-portable) code while Abstract is =
self-contained.</div><div><br></div><div>I am curious about the dangers =
of "Foobarable" notation, which reminds me of the issues Django Admin =
has when you have a "Company" object which is pluralized in "Companies". =
&nbsp;Should we perform most new file creation through Zend Tool, I =
would think this would be problematic.</div><div><br></div><div>&lt;/2 =
cents&gt;</div><div><br></div><div>-Eric Clemmons</div><br><div><div>On =
Mar 15, 2010, at 4:03 PM, P=E1draic Brady wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
font-family: 'times new roman', 'new york', times, serif; font-size: =
12pt; ">I agree with Matthew on the rest, except that, as with Court, I =
prefer Abstract to Base. Longer term albeit, it makes more sense than =
Base which can suggest a broader use meaning (e.g. a non-Abstract super =
class). Under that meaning, Base can be any parent class so the =
indication of a class being Abstract is no longer a certainty without =
referring to API docs (or the code itself).<br><br>Paddy<br><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">&nbsp;</div><span style=3D"color: rgb(0, 0, 191); =
"><font size=3D"3" style=3D"font-family: 'times new roman', 'new york', =
times, serif; "><span style=3D"font-weight: bold; ">P=E1draic =
Brady<br><br></span></font><span style=3D"font-style: italic; "><font =
size=3D"3" style=3D"font-family: 'times new roman', 'new york', times, =
serif; "><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com=
</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish =
Representative</a><br></font></span></span><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font-family: 'times new roman', =
'new york', times, serif; font-size: 12pt; "><br><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
font-family: 'times new roman', 'new york', times, serif; font-size: =
12pt; "><font size=3D"2" face=3D"Tahoma"><hr size=3D"1"><b><span =
style=3D"font-weight: bold; ">From:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Court Ewing &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><b><s=
pan style=3D"font-weight: bold; ">To:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]">[email-masked].=
com</a><br><b><span style=3D"font-weight: bold; ">Sent:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Mon, March 15, 2010 8:21:26 =
PM<br><b><span style=3D"font-weight: bold; ">Subject:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: [zf-contributors] Poll: =
Interfaces/Abstract class naming =
conventions<br></font><br>Howdy,<br><br>I think adjective/noun names for =
interfaces are ideal because they are far more inline with the naming =
conventions already used in SPL, and I think that is something we should =
be striving to do wherever possible.<br><br>I support prefixes for =
abstract classes rather than suffixes, but it seems that has long been =
shot down as an option.<br><br>Regardless of whether we do prefixes or =
suffixes though, I think we should use the word "Abstract" rather than =
"Base".&nbsp; All programmatic dogma aside, if I were to describe an =
abstract class to someone else (take an abstract Triangle class), I =
would tell the person that this is an abstract representation of a =
triangle; I wouldn't say it is a base representation of a =
triangle.&nbsp; If you're going to cite hungarian notation as the reason =
for not using the word "abstract", then I don't know how you can justify =
using any keyword to denote that it is =
abstract.<br><br>-Court<br><br><div class=3D"gmail_quote" =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier =
O'Phinney<span class=3D"Apple-converted-space">&nbsp;</span><span =
dir=3D"ltr">&lt;<a rel=3D"nofollow" ymailto=3D"mailto:[email-masked]" =
target=3D"_blank" =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span><span =
class=3D"Apple-converted-space">&nbsp;</span>wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin-top: 0pt; margin-right: 0pt; =
margin-bottom: 0pt; margin-left: 0.8ex; border-left-width: 1px; =
border-left-style: solid; border-left-color: rgb(204, 204, 204); =
padding-left: 1ex; ">Hey, all --<br><br>I know this has been hashed out =
a fair bit already, and we've already<br>established some guidelines, =
but as I play with code for ZF2, I'm<br>beginning to question the naming =
conventions for Interfaces and Abstract<br>Classes.<br><br>When we made =
the decisions before, we were looking at the following<br>three options =
for interfaces:<br><br>&nbsp;1. Prefix interfaces with "I" =
("IFoobar").<br>&nbsp;2. Suffix interfaces with "Interface" =
("FoobarInterface")<br>&nbsp;3. Use adjective/noun names such as =
"Foobarable", "Foobarist"<br><br>For abstract classes, we looked =
at:<br><br>&nbsp;4. Prefix abstract classes with "A" =
("AFoobar")<br>&nbsp;5. Suffix abstract classes with "Abstract" =
("FoobarAbstract")<br>&nbsp;6. Prefix abstract classes with "Base" =
("BaseFoobar")<br>&nbsp;7. Suffix abstract classes with "Base" =
("FoobarBase")<br>&nbsp;8. Use normal class names =
("Foobar")<br><br>Regarding 1, 2, and 4-7, the arguments against were =
fairly numerous:<br>they smack of Hungarian Notation, the long forms =
lead to really long<br>names, etc. Prefixing can lead to similar classes =
not being grouped when<br>doing directory listings (i.e., all abstract =
class or interface files<br>get clustered together). Also, for classes =
beginning with "I" or "A",<br>there can potentially be confusion over =
whether or not the given class<br>is supposed to be concrete. Finally, =
during refactoring, if you choose<br>to make an interface an abstract =
class or concrete class, or an abstract<br>class an interface or =
concrete class, you can't do so without renaming<br>files and classes. =
(That said, you'll most likely need to make other<br>changes anyways -- =
and ZF will likely never make an interface an<br>abstract class or vice =
versa.)<br><br>Regarding 3 and 8, the primary problems are that it's =
often hard to come<br>up with meaningful names that do not conflict with =
concrete<br>implementations, and that for non-native English speakers, =
this latter<br>problem becomes an even bigger obstacle. Additionally, =
you can't<br>determine which files contain abstract classes and/or =
interfaces just by<br>the filename -- you have to look in the file or =
look in API<br>documentation to determine this information.<br><br>Now, =
as to the issues I've seen: the word "Interface" becomes a real<br>pain =
to type (yes, even with autocompletion), and it doesn't =
really<br>connote any real information. When type-hinting, I simply know =
what type<br>I want to use -- the name doesn't need to tell me it's an =
interface, as<br>I already know that information. If I'm writing code =
that consumes or<br>interacts with the class, API docs will tell me what =
I need to do.<br><br>That said, I don't use Abstract classes that often, =
but considering they<br>are a foundation on which to build concrete =
classes (presumably to take<br>care of many of the nitty gritty details =
and leave the concrete classes<br>to implement specifics), I don't mind =
using a class suffix. "Abstract"<br>feels like Hungarian notation, =
though.<br><br>Based on my experiences writing code, I'm currently =
recommending that we<br>do the following:<br><br>&nbsp;3. Use =
adjective/noun names for Interfaces such as "Foobarable",<br>&nbsp; =
&nbsp;"Foobarist"<br>&nbsp;7. Suffix abstract classes with "Base" =
("FoobarableBase")<br><br>The above solve most issues - names are =
reasonably sized, don't smack of<br>Hungarian Notation (okay, so the =
"Base" verbiage kind of does), and are,<br>most importantly, meaningful. =
Since we already implement code review for<br>any code coming into =
trunk, I think we can even solve the issues for<br>non-native speakers =
as well.<br><br>Thoughts? Votes?<br><font =
color=3D"#888888"><br>--<br>Matthew Weier O'Phinney<br>Project Lead =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<span =
class=3D"Apple-converted-space">&nbsp;</span><a rel=3D"nofollow" =
ymailto=3D"mailto:[email-masked]" target=3D"_blank" =
href=3D"mailto:[email-masked]">[email-masked]</a><br><span>Zend =
Framework &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<span =
class=3D"Apple-converted-space">&nbsp;</span><a target=3D"_blank" =
href=3D"http://framework.zend.com/">http://framework.zend.com/</a></span><=
br><span>PGP key:<span class=3D"Apple-converted-space">&nbsp;</span><a =
target=3D"_blank" =
href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc">http://framework=
.zend.com/zf-matthew-pgp-key.asc</a></span><br></font></blockquote></div><=
br></div></div></div></div></span><br =
class=3D"Apple-interchange-newline"></blockquote></div><br></body></html>=

--Apple-Mail-4-470199878--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 14:20:30 -0500
From: Ryan Albertson <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--0016e649c49019e9c3048071ad34
Content-Type: text/plain; charset=UTF-8

Another consideration of mine would be if Doctrine is used, would ZF use
yaml like symfony does for the generation of schemas and model classes by
making Zend_Tool work with yaml like the symfony CLI?

Ryan Albertson

--0016e649c49019e9c3048071ad34
Content-Type: text/html; charset=UTF-8

Another consideration of mine would be if Doctrine is used, would ZF use yaml like symfony does for the generation of schemas and model classes by making Zend_Tool work with yaml like the symfony CLI?
<div><br></div><div>Ryan Albertson</div>

--0016e649c49019e9c3048071ad34--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 15:26:42 +0100
From: drm <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Hi Matt,

> Your solution for Zend Framework being too complicated for new users
> is to split it up into 7 different, overlapping downloads?  And you
> don't think that would make it much more confusing?
>   
If it's documented right, it will give a better insight of how ZF is
organised and thus how it relates to the user's application of the
framework. I am speaking from my own experience, which is, of course
subjective. Wouldn't you agree that it would be more insightful to have
only maybe a dozen of packages in a starter sandbox than nearly 60?

> I think more documentation is the answer; more diagrams, for starters.
>   

Please note that I did suggest to start with documentation of packages,
not with the separation of packages as downloads. That could be a
"nice-to-have" next step though.

Gerard

(sorry if you got it twice, forgot to reply to the list... again ....)

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 08:59:25 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

Hey, all --

This is the first in a series of emails I'll be posting to this list
with status updates on 2.0. I plan to do these several times a week
throughout the process.

Since branching 2.0 a couple days ago, I've been busy working on
stripping require_once calls from the ZF library.

My initial idea was to simply run the same find/sed script from the
performance guide, but quickly discarded this for two reasons:

 * It only comments out those lines. Yes, it can be modified to remove
   the lines as well, but this does not address other concerns such as
   preceding docblocks.

 * To package individual components, we need some way to determine
   dependencies. Currently, require_once statements can help with that,
   but stripping them makes this harder. My solution is to add @uses
   annotations at the class docblock level. This assists the API docs,
   but also should make it possible to use automated scanners to
   determine dependencies.

To accomodate these concerns, the process has to be manual. I've
currently completed the top-level classes, and all components through
Zend_Config. I'm committing to a local git branch incrementally, and
will be pushing a squashed commit to the development-2.0 branch once
complete.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 4 Jun 2009 16:14:24 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] addScriptPath question

-- till <[email-masked]> wrote
(on Thursday, 04 June 2009, 07:11 PM +0200):
> debugging some code, and I noticed that addScripPath (and ultimately
> _addPath()) in Zend_View_Abstract always prepends the path. I was
> trying to add script paths as a fall back -- if not found in this
> module, fallback to default (or where the other path leads to). Any
> idea if we could add this kind of behavior for 2.0?
> 
> This is the code (from Zend/View/Abstract.php, _addPath()):
> 
>         switch ($type) {
>                 case 'script':
>                     // add to the top of the stack.
>                     array_unshift($this->_path[$type], $dir);
>                     break;

The behaviour of Zend_View is such that what you describe as what you
want is how it should work. Basically, it searches the registered paths
until it finds a matching view script.

Am I missing something here?

> Sort of related, it would be nice if there were no private methods in
> that class. ;-(

Dude, this has been covered *so* many times, and it even has a section
in the manual covering the "why" of the design: 

    http://framework.zend.com/manual/en/zend.view.abstract.html

Short answer: the private methods are not going away, as they are an
important implementation detail.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 26 Jul 2009 18:08:47 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code Freeze starts tomorrow

Greets, all --

Code freeze on the 1.9 release branch starts tomorrow at 10:00 EDT
(UTC-0500). After that point, we ask that you run any merges to the 1.9
release branch by myself, Alex, or Ralph prior to merging; such changes
should *only* be for critical issues until after the 1.9 release -- show
stoppers only, in other words.

Thanks for the enormous amount of testing, documentation, and
translations that have come in over the weekend -- this sort of work
will make the release solid for the end-users of the framework.

If you have any last minute updates to squeeze in -- you have 16 hours
from the time I send this!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 30 Jul 2009 12:32:01 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Speak up now!

Hey, all --

I plan to tag the ZF 1.9.0 release within the next few hours (packaging,
site refresh, etc. will take a number of hours, and thus the official
release will be tomorrow).

We *will* be doing a point-release, 1.9.1, on Tuesday, 11 August 2009,
so any non-critical bugfixes can wait until after the 1.9.0 release.

If you know of any show-stopper issues, *NOW* is the time to let me
know!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: "Ben Scholzen 'DASPRiD'" <[email-masked]>,
	<[email-masked]>
Date: Fri, 26 Feb 2010 08:51:48 +0100
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

I would expect that also the actual component maintainers (for each 
component there is one maintainer defined within jira) and the component 
author (which is sometimes not the component maintainer) have write access.

Actually we have about 500-800 commits per month. It would be a pitty if 
only 3 people have the right to commit these changes.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Ben Scholzen 'DASPRiD'" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 26, 2010 1:32 AM
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Matthew Weier O'Phinney wrote on 25.02.2010 21:48:
>> People clone it, and
>> then issue a pull request to a release master. The release master can
>> track multiple repos from multiple collaborators, and then selectively
>> merge into their own "master" -- and push those patches into the
>> mainline.
>
> Would that mean, that the component maintainers would not have any
> commit access anymore but only the liasions? Or would those component
> maintainers become the release masters? Because if only a handful of
> people (like those 3 liasions) would get commit access, the entire
> colaboration process would become pretty slow.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkuHFqEACgkQ0HfT5Ws789Dg0QCeM8zOjp/14gMLNzgDpfJx+z33
> 52EAn24BDY2Z5G5ioIJ0vtJaV/LWNN9H
> =+uUX
> -----END PGP SIGNATURE----- 

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Oct 2009 22:48:35 +0200
From: till <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Code Review

On Mon, Oct 12, 2009 at 10:38 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Trevor Johns <[email-masked]> wrote
> (...)
>> Personally, the best code review experience I've had is with Gerrit
>> (review.source.android.com), with Rietveld (codereview.appspot.com)
>> coming in second place.
>
> I may look at those.

I remember looking at both and I decided against Rietveld because it's
AppEngine-based and the other is (was?) for GIT-powered projects. I
ended up baking a couple greasemonkey scripts for code review from a
trac install.

But besides -- why is it so hard to find great tools? :-)

Till

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 27 Aug 2009 20:34:54 -0300
From: Rafael Dohms <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in 
	Zend_Entity

--000e0cd3546ece3214047228031e
Content-Type: text/plain; charset=ISO-8859-1

Guys,

Just a quick notice and question.

Isn't this an area where ORMs like Doctrine have already mastered solutions?
aren't they rather easy to integrate into Zend Framework? Wouldnt it be
easier to provide interaction points to doctrine, propel and others instead
of bulging ZF with all stuff needed to fully abstract all databases and
storage stuff.

Sorry if this is waaay out of line, but its just seems to heavy an area to
include.

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br

On Thu, Aug 27, 2009 at 6:58 PM, Bryce Lohr <[email-masked]>wrote:

>
>
> Benjamin Eberlei wrote:
>
>> Hello everyone,
>>
>> i am currently scratching my head on howto abstract the query API for
>> different storages and often think about CouchDb which has a fundamently
>> different Query concept than a RDBMS.
>>
>>
>
> Perhaps it's too early to even try for such an abstraction. 99% of current
> uses will probably be relational DBs. The best abstractions may make
> themselves clearer once we have more real uses.
>
>  For clarification to the not so familiar, it the EntityManager is the sole
>> public API to the user of Zend_Entity and its facilities. It manages the
>> life-
>> cycle of domain objects.
>>
>> Currently, it has the following API for queries:
>>
>> EntityManager::load($entityClass, $id);
>> EntityManager::createNamedQuery($name);
>> EntityManager::createNativeQuery($input, $resultSetMapping);
>> EntityManager::createNativeQueryBuilder($entityClass=null);
>> EntityManager::createQuery($zql); // not implemented yet
>> EntityManager::createQueryBuilder(); // not implemented yet
>>
>>
>>
>
> I have to admit, I haven't looked at the proposal in a while, so I'm not
> sure what all those interfaces imply.
>
>  This is very large and still very RDBMS specific interface. To break that
>> up
>> I was thinking to go the following way, only have three methods:
>>
>> EntityManager::load($entityClass, $id);
>> EntityManager::createNamedQuery($name);
>> EntityManager::createNativeQuery($input, $resultSetMapping);
>>
>> And all the other Query related stuff is implemented and used explicitly
>> by calling for example:
>>
>> $sqlQueryBuilder = new Zend_Db_Mapper_SqlQueryBuilder($entityManager);
>> $queryBuilder = new Zend_Db_Mapper_QueryBuilder($entityManager);
>> $zqlQuery = new Zend_Db_Mapper_ZqlQuery($entityManager);
>>
>>
>
> Again, I'm just guessing at these APIs, and I don't know what ZQL is, but
> wouldn't an SQL builder be sort of an "output" strategy of QueryBuilder, and
> ZQL a kind of "input" strategy for QueryBuilder?
>
>  This way the API can be hinted explicitly in IDEs (since its often quite
>> complex) and storage specific features can be implemented.
>>
>> Now you ask yourself, how is this storage independent? It is via the
>> "createNamedQuery()" method. This method internally uses the plugin loader
>> to instantiate queries via the command pattern. In a storage independent
>> database, all operations have to be build as named query and executed such.
>> For each storage a corresponding implementation has to exist. I can't do
>> more since even newer approaches like LINQ in .NET for example don't lend
>> themselfes to CouchDb at all. I dont see a way to generate a better query
>> API.
>>
>>
>
> Maybe instead of trying to generate a better query API, work out just what
> exactly the EntityManager needs, and extract that into its own interface.
> Provide one implementation that works for relational DBs. People who need to
> support non-relational stores can create their own implementation, and may
> provide valuable feedback in the process. Later, after enough of that kind
> of feedback has coalesced, refactor the interface to add the appropriate
> abstractions. I realize that creates backward compatibility concerns, but
> that's always going to be the case anyway.
>
>  What are your thoughts on this issue? :-)
>>
>> greetings,
>> Benjamin
>>
>>
>>
>
> Regards,
> Bryce Lohr
>
>

--000e0cd3546ece3214047228031e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Guys,<br><br>Just a quick notice and question.<br><br>Isn&#39;t this an are=
a where ORMs like Doctrine have already mastered solutions?<br>aren&#39;t t=
hey rather easy to integrate into Zend Framework? Wouldnt it be easier to p=
rovide interaction points to doctrine, propel and others instead of bulging=
 ZF with all stuff needed to fully abstract all databases and storage stuff=
.<br>
<br>Sorry if this is waaay out of line, but its just seems to heavy an area=
 to include.<br><br><br clear=3D"all"><br>-- <br>Rafael Dohms<br>PHP Evange=
list and Community Leader<br><a href=3D"http://www.rafaeldohms.com.br">http=
://www.rafaeldohms.com.br</a><br>
<a href=3D"http://www.phpsp.org.br">http://www.phpsp.org.br</a><br><br><div=
 class=3D"gmail_quote">On Thu, Aug 27, 2009 at 6:58 PM, Bryce Lohr <span di=
r=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">brycel@patienta=
dvocate.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D"im"=
><br>
<br>
Benjamin Eberlei wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello everyone,<br>
<br>
i am currently scratching my head on howto abstract the query API for diffe=
rent storages and often think about CouchDb which has a fundamently differe=
nt Query concept than a RDBMS.<br>
 =A0<br>
</blockquote>
<br></div>
Perhaps it&#39;s too early to even try for such an abstraction. 99% of curr=
ent uses will probably be relational DBs. The best abstractions may make th=
emselves clearer once we have more real uses.<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For clarification to the not so familiar, it the EntityManager is the sole =
public API to the user of Zend_Entity and its facilities. It manages the li=
fe-<br>
cycle of domain objects.<br>
<br>
Currently, it has the following API for queries:<br>
<br>
EntityManager::load($entityClass, $id);<br>
EntityManager::createNamedQuery($name);<br>
EntityManager::createNativeQuery($input, $resultSetMapping);<br>
EntityManager::createNativeQueryBuilder($entityClass=3Dnull);<br>
EntityManager::createQuery($zql); // not implemented yet<br>
EntityManager::createQueryBuilder(); // not implemented yet<br>
<br>
 =A0<br>
</blockquote>
<br></div>
I have to admit, I haven&#39;t looked at the proposal in a while, so I&#39;=
m not sure what all those interfaces imply.<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is very large and still very RDBMS specific interface. To break that u=
p<br>
I was thinking to go the following way, only have three methods:<br>
<br>
EntityManager::load($entityClass, $id);<br>
EntityManager::createNamedQuery($name);<br>
EntityManager::createNativeQuery($input, $resultSetMapping);<br>
<br>
And all the other Query related stuff is implemented and used explicitly by=
 calling for example:<br>
<br>
$sqlQueryBuilder =3D new Zend_Db_Mapper_SqlQueryBuilder($entityManager);<br=
$queryBuilder =3D new Zend_Db_Mapper_QueryBuilder($entityManager);<br>
$zqlQuery =3D new Zend_Db_Mapper_ZqlQuery($entityManager);<br>
 =A0<br>
</blockquote>
<br></div>
Again, I&#39;m just guessing at these APIs, and I don&#39;t know what ZQL i=
s, but wouldn&#39;t an SQL builder be sort of an &quot;output&quot; strateg=
y of QueryBuilder, and ZQL a kind of &quot;input&quot; strategy for QueryBu=
ilder?<div class=3D"im">
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This way the API can be hinted explicitly in IDEs (since its often quite co=
mplex) and storage specific features can be implemented.<br>
<br>
Now you ask yourself, how is this storage independent? It is via the &quot;=
createNamedQuery()&quot; method. This method internally uses the plugin loa=
der to instantiate queries via the command pattern. In a storage independen=
t database, all operations have to be build as named query and executed suc=
h. For each storage a corresponding implementation has to exist. I can&#39;=
t do more since even newer approaches like LINQ in .NET for example don&#39=
;t lend themselfes to CouchDb at all. I dont see a way to generate a better=
 query API.<br>

 =A0<br>
</blockquote>
<br></div>
Maybe instead of trying to generate a better query API, work out just what =
exactly the EntityManager needs, and extract that into its own interface. P=
rovide one implementation that works for relational DBs. People who need to=
 support non-relational stores can create their own implementation, and may=
 provide valuable feedback in the process. Later, after enough of that kind=
 of feedback has coalesced, refactor the interface to add the appropriate a=
bstractions. I realize that creates backward compatibility concerns, but th=
at&#39;s always going to be the case anyway.<div class=3D"im">
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What are your thoughts on this issue? :-)<br>
<br>
greetings,<br>
Benjamin<br>
<br>
 =A0<br>
</blockquote>
<br></div>
Regards,<br><font color=3D"#888888">
Bryce Lohr<br>
<br>
</font></blockquote></div><br><br>

--000e0cd3546ece3214047228031e--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 20:56:07 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

Ben Scholzen 'DASPRiD' wrote on 26.02.2010 20:53:
> Matthew Weier O'Phinney wrote on 26.02.2010 14:59:
>>  * To package individual components, we need some way to determine
>>    dependencies. Currently, require_once statements can help with that,
>>    but stripping them makes this harder. My solution is to add @uses
>>    annotations at the class docblock level. This assists the API docs,
>>    but also should make it possible to use automated scanners to
>>    determine dependencies.
> 
> The idea is in fact better than tracking depencies through require_once
> calls, since there were still depencies via autoloading, which thus can
> be resolved via the @uses tag.

Tho, you should also take @usedby into your consideration, see:
http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.uses.pkg.html

@usedby may be useful, if there is one parent class, but many sub
classes. refering to the child class is not possible, as there are many,
so the childs have refer to the parent.

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 20 Feb 2010 01:52:44 +0900
To: [email-masked]
From: satoruyoshida <[email-masked]>
Subject: Re: [zf-contributors] Zend_Mail

Thank You for explanation, Shahar,
and thank You for proposal of cooperation, Otto.

Possibly You had found them, there are two components on Issue Tracker
, Zend_Mail and Zend_Mail_Storage.

The IMAP where You are interested in belongs to Zend_Mail_Storage.
Maintainer of the Storage category is Nico Edtinger, and I am in charge
  of Zend_Mail except the category.

I have heard from Nico that he has many tasks to do still more in the
  Storage category like as You aware of TODOs.

I will be happy if You would talk about and help Nico .

I hope this mail could help You.
With Best Regards,

Satoru Yoshida
Home : [email-masked]
Office : [email-masked]
Twitter: satoruyoshida

> On Wed, 10 Feb 2010 13:27:05 +0200, [email-masked] wrote:
>
> I am not the Zend_Mail maintainer but as a side note it sounds like
> there is no need to wait for 2.0 if you'd like to help implementing the
> current missing parts, as long as there is no backwards compatibility
> breakage in the process (and I'm guessing, without knowing the details,
> that for the most part there shouldn't be).
>Shahar.
>
>> On 10/2/10 2:53 AM, [email-masked] wrote:
>> Hi,
>>  in the roadmap for 2.0 you called for participation in the discussion,
>> so here are my thoughts for Zend_Mail. First at all, the most important
>> thing is to complete the existing code. For instance, in the imap
>> component there are many features in the api but marked "not
>> implemented". I'm trying to write an email webclient and found many
>> things which just aren't implemented. Things like search in imap and
>> fetching only contents parts of emails instead of all, aren't working.
>> I also think, that content encoding should be integrated automatically.
>>  To keep it short, at the moment the imap layer in zend is only (too)  
>> basic.
>> I would like to help the Zend_Mail maintainer (whoever that is) and hear
>> your thoughts.
>>  Regards,
>> Otto
>--Shahar Evron <[email-masked]>
>Product Manager
> Zend Technologies  

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 23 Jan 2010 17:48:51 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Date & build-in class Da

hi thomas,

one more general about Zend_Date: (Please correct my if I'm wrong)
Zend_Date handles date & time information. Therefore all date objects
have to handle timezones, too.
But if you only need the date part the timezone makes it confused.

Birthday example:
User A:
  - current timezone =3D +2h (Europe/Berlin - MEST)
  - set his birthday =3D 1983-08-19  =3D 1983-08-19 00:00:00+0200

User B:
  - current timezone =3D -8h (Nevada)
  - display birthday of User A =3D 1983-08-18 14:00:00-0800 =3D 1983-08-1=
8
  =3D 1 day difference

This means the developer have to know which dates have to store/display
with which timezones.

I'm not a python developer but i think within it its solved well. There
3 classes: date, time and datetime.
 - date is for only dates without timezone
 - time is for only times with timezone
 - datetime for both together

Greetings
Marc

Am 23.01.2010 11:58, schrieb Thomas Weidner:
> You are comparing apples with oranges.
> A discussion on such a basis is completly useless.
>
> Actually Zend_Date uses mktime. So when you want to compare one
> implementation to the other you need to compare mktime to DateTime.
>
> And of course you already did a real comparison as you reworked
> Zend_Date. Did you?
>
> Just for information... the lack of performance is due to the reason
> how I was forced to implement the class. A class which is 4500 lines
> long and adds about 200 methods will never be as performant as a
> extension which has has only 15 methods.
>
> When I am not forced to do the API within a few days as with 0.7 and
> am allowed to rework it as it should be done then even the existing
> mktime implementation would be multiple times faster.
>
> PS: Related to mktime DateTime performs also slower. The real benefit
> is only for calculations beside the 32bit unix timestamp.
>
> PPS: Again... as said in past... as long as we are limited to 5.2.4
> there will be no rework due to some major problems which has been
> solved in later releases.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "Benjamin Eberlei"
> <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, January 23, 2010 1:36 AM
> Subject: Re: [zf-contributors] Zend_Date & build-in class Da
>
>
>> =3D?UTF-8?Q?teTime?=3D
>>
>>
>> The only thing DateTime can't handle that Zend_Date can as of 5.3 is
>>
>> localized output
>>
>> and maybe some special features.
>>
>>
>>
>>> From the performance point of view, i have tested three use-cases
>>> against
>>
>> each
>>
>> other:
>>
>>
>>
>> 1. Printing the same instance 100 times
>>
>>
>>
>> $s =3D microtime(true);
>>
>> $d =3D new DateTime("now");
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>   $d->format('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> $date =3D new Zend_Date(1234567890, false);
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>    $date->toString('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> Gives:
>>
>> DateTime 0.0004s
>>
>> Zend_Date 0.0599s
>>
>>
>>
>> 2. Changing the date by Unix-Timestamp on each run for 100 times:
>>
>>
>>
>> $d =3D new DateTime("now");
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>   $d->setTimestamp($now + $i * 7200);
>>
>>   $d->format('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> $date =3D new Zend_Date(1234567890, false);
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>    $date->setTimestamp($now + $i * 7200);
>>
>>    $date->toString('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> Gives:
>>
>> DateTime 0.0010s
>>
>> Zend_Date 0.0591s
>>
>>
>>
>> 3. Changing Date on each call by a defined format (MySQL Database)
>> for 100
>>
>> new instances.
>>
>>
>>
>> Now this is the most evil performance hit.
>>
>>
>>
>> $s =3D microtime(true);
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>   $d =3D DateTime::createFromFormat('Y-m-d H:i:s', '2009-04-01 12:12:1=
2');
>>
>>   $d->format('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> for($i =3D 0; $i < 100; $i++) {
>>
>>    $date =3D new Zend_Date('2009-04-01 12:12:12', Zend_Date::ISO_8601)=
;
>>
>>    $date->toString('d.m.Y, H:i');
>>
>> }
>>
>>
>>
>> DateTime: 0.0020s
>>
>> Zend_Date: 0.1982s
>>
>>
>>
>> DateTime is faster than Zend_Date by a magnitute of 60-100!!
>>
>>
>>
>>
>>
>> On Fri, 22 Jan 2010 15:59:32 -0800 (PST), P=C3=A1draic Brady
>>
>> <[email-masked]> wrote:
>>
>>> Personally I don't see DateTime as massively important to Zend_Date. =
It
>>
>>> would be nice to have, but the class itself is pretty basic that I'm
>>> not
>>
>>> sure what exactly it would add to Zend_Date other than offer a
>>
>> (measured?)
>>
>>> performance boost and some import/export functionality for
>>
>> interoperability
>>
>>> (would have been nicer to have a DateTime interface).
>>
>>>
>>
>>>  P=C3=A1draic Brady
>>
>>>
>>
>>> http://blog.astrumfutura.com
>>
>>> http://www.survivethedeepend.com
>>
>>> OpenID Europe Foundation Irish Representative
>>
>>>
>>
>>>
>>
>>>
>>
>>>
>>
>>>
>>
>>> ________________________________
>>
>>> From: Marc Bennewitz <[email-masked]>
>>
>>> To: [email-masked]
>>
>>> Sent: Fri, January 22, 2010 10:16:02 PM
>>
>>> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>>
>>>
>>
>>>  Hi all,
>>
>>>
>>
>>> Does is matter that Zend_Date doesn't extends the build-in DateTime
>>
>>> class ?
>>
>>> -> The DateTime class is available since PHP
>>
>>> 5.2.0 and ZF require PHP 5.2.4.
>>
>>>
>>
>>> It would be very nice because than Zend_Date would be compatible to
>>
>>> other php libraries using DateTime and within ZF tests like the
>>
>>> following can simplify:
>>
>>>
>>
>>> if ($date instanceof Zend_Date_DateObject) {
>>
>>>     $timestamp =3D $date->getUnixTimestamp();
>>
>>> } elseif ($date instanceof DateTime) {
>>
>>>     $timestamp =3D $date->getTimestamp();
>>
>>> } else {
>>
>>>     $timestamp =3D (float)$date;
>>
>>> }
>>
>>>
>>
>>> Greetings,
>>
>>> Marc=20
>
>

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 27 Aug 2009 17:58:26 -0400
From: Bryce Lohr <[email-masked]>
Organization: Patient Advocate Foundation
To: Benjamin Eberlei <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in
	Zend_Entity

Benjamin Eberlei wrote:
> Hello everyone,
>
> i am currently scratching my head on howto abstract the query API for different 
> storages and often think about CouchDb which has a fundamently different Query 
> concept than a RDBMS.
>   

Perhaps it's too early to even try for such an abstraction. 99% of 
current uses will probably be relational DBs. The best abstractions may 
make themselves clearer once we have more real uses.

> For clarification to the not so familiar, it the EntityManager is the sole 
> public API to the user of Zend_Entity and its facilities. It manages the life-
> cycle of domain objects.
>
> Currently, it has the following API for queries:
>
> EntityManager::load($entityClass, $id);
> EntityManager::createNamedQuery($name);
> EntityManager::createNativeQuery($input, $resultSetMapping);
> EntityManager::createNativeQueryBuilder($entityClass=null);
> EntityManager::createQuery($zql); // not implemented yet
> EntityManager::createQueryBuilder(); // not implemented yet
>
>   

I have to admit, I haven't looked at the proposal in a while, so I'm not 
sure what all those interfaces imply.

> This is very large and still very RDBMS specific interface. To break that up
> I was thinking to go the following way, only have three methods:
>
> EntityManager::load($entityClass, $id);
> EntityManager::createNamedQuery($name);
> EntityManager::createNativeQuery($input, $resultSetMapping);
>
> And all the other Query related stuff is implemented and used explicitly by 
> calling for example:
>
> $sqlQueryBuilder = new Zend_Db_Mapper_SqlQueryBuilder($entityManager);
> $queryBuilder = new Zend_Db_Mapper_QueryBuilder($entityManager);
> $zqlQuery = new Zend_Db_Mapper_ZqlQuery($entityManager);
>   

Again, I'm just guessing at these APIs, and I don't know what ZQL is, 
but wouldn't an SQL builder be sort of an "output" strategy of 
QueryBuilder, and ZQL a kind of "input" strategy for QueryBuilder?

> This way the API can be hinted explicitly in IDEs (since its often quite 
> complex) and storage specific features can be implemented.
>
> Now you ask yourself, how is this storage independent? It is via the 
> "createNamedQuery()" method. This method internally uses the plugin loader to 
> instantiate queries via the command pattern. In a storage independent 
> database, all operations have to be build as named query and executed such. 
> For each storage a corresponding implementation has to exist. I can't do more 
> since even newer approaches like LINQ in .NET for example don't lend 
> themselfes to CouchDb at all. I dont see a way to generate a better query API.
>   

Maybe instead of trying to generate a better query API, work out just 
what exactly the EntityManager needs, and extract that into its own 
interface. Provide one implementation that works for relational DBs. 
People who need to support non-relational stores can create their own 
implementation, and may provide valuable feedback in the process. Later, 
after enough of that kind of feedback has coalesced, refactor the 
interface to add the appropriate abstractions. I realize that creates 
backward compatibility concerns, but that's always going to be the case 
anyway.

> What are your thoughts on this issue? :-)
>
> greetings,
> Benjamin
>
>   

Regards,
Bryce Lohr

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 1 Feb 2010 04:03:48 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: [email-masked]
Cc: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Re: [fw-mvc] Zend_Session_SaveHandler_Cookies

--0-1666582539-1265025828=:7601
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Unfortunately, I'd say many of us were simply busy with 1.10. I would leave=
 as is for a few more days (I'll review later and comment at least).=0A=0AI=
've copied this to the contributors mailing list for some attention ;).=0A=
=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://w=
ww.survivethedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=
=0A=0A=0A=0A=0A________________________________=0AFrom: Romain Lalaut <roma=
[email-masked]>=0ATo: [email-masked]=0ASent: Mon, February 1,=
 2010 10:15:00 AM=0ASubject: [fw-mvc] Zend_Session_SaveHandler_Cookies=0A=
=0AHi,=0A=0AI posted a month ago a page on the wiki about a new session sav=
e handler =0Ausing cookies to store the data : =0Ahttp://framework.zend.com=
/wiki/display/ZFPROP/Zend_Session_SaveHandler_Cookies+-+Romain+Lalaut=0A=0A=
I didn't have any review from the community. So maybe should I send it to t=
he =0Asection "Ready for Recommandation" ?=0A=0ARegards,=0A=0ARomain
--0-1666582539-1265025828=:7601
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:Courier New,courier,monaco,monospace,san=
s-serif;font-size:10pt"><span style=3D"font-family: times new roman,new yor=
k,times,serif;"><font size=3D"3">Unfortunately, I'd say many of us were sim=
ply busy with 1.10. I would leave as is for a few more days (I'll review la=
ter and comment at least).<br><br>I've copied this to the contributors mail=
ing list for some attention ;).<br><br>Paddy<br></font></span><div>&nbsp;</=
div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: time=
s new roman,new york,times,serif;" size=3D"3"><span style=3D"font-weight: b=
old;">P=E1draic Brady<br><br></span></font><span style=3D"font-style: itali=
c;"><font style=3D"font-family: times new roman,new york,times,serif;" size=
=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"http://blog.astrumfutu=
ra.com">http://blog.astrumfutura.com</a><br><a rel=3D"nofollow" target=3D"_=
blank"
 href=3D"http://www.survivethedeepend.com">http://www.survivethedeepend.com=
</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.openideuro=
pe.eu/">OpenID Europe Foundation Irish Representative</a><br></font></span>=
</span><div><br></div><div style=3D"font-family: Courier New,courier,monaco=
,monospace,sans-serif; font-size: 10pt;"><br><div style=3D"font-family: tah=
oma,new york,times,serif; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"=
><hr size=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Roma=
in Lalaut &lt;[email-masked]&gt;<br><b><span style=3D"font-weigh=
t: bold;">To:</span></b> [email-masked]<br><b><span style=3D"font-we=
ight: bold;">Sent:</span></b> Mon, February 1, 2010 10:15:00 AM<br><b><span=
 style=3D"font-weight: bold;">Subject:</span></b> [fw-mvc] Zend_Session_Sav=
eHandler_Cookies<br></font><br>=0AHi,<br><br>I posted a month ago a page on=
 the wiki about a new session save handler <br>using cookies to store the d=
ata : <br><span><a target=3D"_blank" href=3D"http://framework.zend.com/wiki=
/display/ZFPROP/Zend_Session_SaveHandler_Cookies+-+Romain+Lalaut">http://fr=
amework.zend.com/wiki/display/ZFPROP/Zend_Session_SaveHandler_Cookies+-+Rom=
ain+Lalaut</a></span><br><br>I didn't have any review from the community. S=
o maybe should I send it to the <br>section "Ready for Recommandation" ?<br=
><br>Regards,<br><br>Romain<br><br></div></div>=0A<!-- cg2.c902.mail.ac4.ya=
hoo.com compressed/chunked Fri Jan 29 07:26:26 PST 2010 -->=0A</div></body>=
</html>
--0-1666582539-1265025828=:7601--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Alan Wagstaff <[email-masked]>
Date: Tue, 29 Sep 2009 22:28:21 +0100
To: Graham Anderson <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Google Wave Invites

--00c09ffb4c5f21ac1b0474be1948
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've just been watching the hour and a half(!) video on the Google Wave sit=
e
and whilst it looks very nice from a technical stand point, I'm not entirel=
y
sure what I'd ever use it for.
But... I signed up on the website anyway as it's always fun to have a new
toy to play with :)

2009/9/29 Graham Anderson <[email-masked]>

> The first wave (pardon the pun) of mass invites for Google Wave are going
> out
> tomorrow, people with existing accounts and new invitees will be allocate=
d
> 8
> additional invites.
>
> If you don't already have a wave account and have *not* signed up to get
> one,
> I'll send out my 8 invites in on a first come first served basis on this
> list.
>
> Graham
> --
> =E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=
=9D
>  =E2=98=98 Oscar Wilde

--00c09ffb4c5f21ac1b0474be1948
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I&#39;ve just been watching the hour and a half(!) video on the Google Wave=
 site and whilst it looks very nice from a technical stand point, I&#39;m n=
ot entirely sure what I&#39;d ever use it for.<div><br></div><div>But... I =
signed up on the website anyway as it&#39;s always fun to have a new toy to=
 play with :)<br>

<br><div class=3D"gmail_quote">2009/9/29 Graham Anderson <span dir=3D"ltr">=
&lt;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex;">

The first wave (pardon the pun) of mass invites for Google Wave are going o=
ut<br>
tomorrow, people with existing accounts and new invitees will be allocated =
8<br>
additional invites.<br>
<br>
If you don&#39;t already have a wave account and have *not* signed up to ge=
t one,<br>
I&#39;ll send out my 8 invites in on a first come first served basis on thi=
s list.<br>
<br>
Graham<br>
<font color=3D"#888888">--<br>
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D<=
br>
=C2=A0=E2=98=98 Oscar Wilde<br>
</font></blockquote></div><br></div>

--00c09ffb4c5f21ac1b0474be1948--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Wed, 8 Apr 2009 12:03:53 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: RE: [zf-contributors] Zend Framework 1.8 Preview Release is released

Hi all!

Online documentation at framework.zend.com is updated, so it also
includes extras documentation now.

With best regards,
   Alexander Veremyev.

> -----Original Message-----
> From: Matthew Weier O'Phinney [mailto:[email-masked]]
> Sent: Wednesday, April 08, 2009 6:21 AM
> To: [email-masked]
> Subject: [zf-contributors] Zend Framework 1.8 Preview Release is
released
>=20
> Greetings, all!
>=20
> I've just finished releasing the 1.8 preview release, and you can
> download it from http://framework.zend.com/download/latest. The manual
> has also been updated to reflect the new functionality.
>=20
> On that note, there was a snafu when merging in the ZendX
documentation.
> Alex will hit that first thing in the morning so that it's present. If
> you see any other anomolies, please send an email in reply to this
one.
>=20
> Thanks everyone for all the hard work in getting contributions ready
for
> this milestone. Let's work on polishing it and getting additional
> bugfixes in before the final release later this month!
>=20
> --
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 11:56:24 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0016e6d644f52633ed04788efa4a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 17, 2009 at 10:31 AM, drm <[email-masked]> wrote:

> As a beginner, you could start off with the "Starter" package, to get
> started learning the core of the MVC framework, without being confused by
> packages like GData and InfoCard, to avoid the "What does this button
> do?"-effect. I also think, one of the USP's of ZF is that it is usable as a
> full-stacked framework, and as a code library (or both). I think packaging
> might reflect (and encourage) this better. All strictly unnessecary
> dependencies would ideally be eliminated to avoid cascading and recursive
> dependencies to achieve this. All necessary dependencies could be documented
> and registered in a package builder, or just documentation.
>
> I think that is one of the issues that will help reel people in getting
> more involved, because it will help understanding the framework's basic
> structure, and get them up and running quickly ( < 1MB starter sandbox? )
>
> I am aware of the fact that it might be rather time-consuming to maintain
> this structure, but we could get started by documenting a dependency tree
> for each of the directories in the current 1.9 minimal package, and automate
> some build process for it?
>
>
 Currently there is an unofficial packageizer which works with
require_once() stetements:
http://epic.codeutopia.net/pack/
It is very useful since for instance if you want to use Zend_Form there are
a lot of classes from different components to check out, from Zend_View in
primis.
Since 2.0 will be autoloading base, we must have another mechanism to define
dependencies (php brutal code parsing or 'use' statements) if we want to
generate packages.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d644f52633ed04788efa4a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Nov 17, 2009 at 10:31 AM, drm <span dir=
=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As a beginner, you could start off with the &quot;Starter&quot; package, to=
 get started learning the core of the MVC framework, without being confused=
 by packages like GData and InfoCard, to avoid the &quot;What does this but=
ton do?&quot;-effect. I also think, one of the USP&#39;s of ZF is that it i=
s usable as a full-stacked framework, and as a code library (or both). I th=
ink packaging might reflect (and encourage) this better. All strictly unnes=
secary dependencies would ideally be eliminated to avoid cascading and recu=
rsive dependencies to achieve this. All necessary dependencies could be doc=
umented and registered in a package builder, or just documentation.<br>

<br>
I think that is one of the issues that will help reel people in getting mor=
e involved, because it will help understanding the framework&#39;s basic st=
ructure, and get them up and running quickly ( &lt; 1MB starter sandbox? )<=
br>

<br>
I am aware of the fact that it might be rather time-consuming to maintain t=
his structure, but we could get started by documenting a dependency tree fo=
r each of the directories in the current 1.9 minimal package, and automate =
some build process for it?<br>

<br></blockquote><div>=A0</div><div>=A0Currently there is an unofficial pac=
kageizer which works with require_once() stetements:<br><a href=3D"http://e=
pic.codeutopia.net/pack/">http://epic.codeutopia.net/pack/</a><br>It is ver=
y useful since for instance if you want to use Zend_Form there are a lot of=
 classes from different components to check out, from Zend_View in primis.<=
br>
Since 2.0 will be autoloading base, we must have another mechanism to defin=
e dependencies (php brutal code parsing or &#39;use&#39; statements) if we =
want to generate packages.<br><br></div></div><br clear=3D"all"><br>-- <br>
Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br><a href=3D"http://=
giorgiosironi.blogspot.com">http://giorgiosironi.blogspot.com</a><br><a hre=
f=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgiosironi</a>=
<br>

--0016e6d644f52633ed04788efa4a--

nFrom nobody Wed Apr  7 08:46:14 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 16:58:43 -0800
From: Kevin McArthur <[email-masked]>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

This is a multi-part message in MIME format.
--------------020100090807050905010309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

P=E1draic Brady wrote:
>
> The main wall Kevin just hit is simply never going away. If it ever=20
> did, ZF wouldn't be far behind it as a untested, undocumented morass=20
> of code that (allegedly) does stuff.
I doubt this greatly, ZF to 1.0 was a huge success and had none of this=20
stuff. A decent vetting by interested coders was all it took to keep the=20
quality up. Most of that code still comprises the code base today, and=20
it still runs fine. The docs were enough to get interested developers=20
over the initial hurdles and the rest came through other sources like=20
blogs, irc, books and sample code. I'm not saying we go back to totally=20
untested code or anything like that, I guess I just see tests like=20
icing, not an ingredient. If there's tests, great, if not, put it on the=20
todo and move on. Instead we've got tests that are at times even=20
counter-productive as you describe.

> We need all the "contribution overhead". It is absolutely essential.=20
> There are components in the ZF which, to be generous, are pretty bad=20
> in terms of testing, documentation and flexibility already - and=20
> that's with the requirement! I have worse descriptions. Catch me on=20
> IRC during a bug hunt and I'll share some ;).

I'd argue that some of those components are bad in part because of the=20
requirement.
>
> The fact is, if you cannot handle the additional work that underpins,=20
> supports and ensures ease of maintenance for a component - then you=20
> are begging for a developer to start swearing over IRC. I had the joy=20
> of dealing with such a component a few weeks back. It took me hours to=20
> figure out a bug. Why? Because the unit tests DID NOT TEST the=20
> functionality of the component. I could have deleted every single test=20
> with no ill effect - they were all busy with XML parsing or something=20
> (performed by a completely different component with its own perfectly=20
> functional unit tests).
That sounds about right.
>
> But worse than all this, is the assumption that lowering the=20
> contribution overhead is a positive thing. It's not - it merely shifts=20
> that work onto someone else.
That assumes that a large amount of this work isn't optional -- when it=20
is. Those useless tests are there because someone said 'must have=20
tests', many, possibly most, of them are totally unneeded except to up=20
the code coverage report statistics. A minority of the ZFW tests do any=20
useful testing, and for those, I'm glad there's tests... and I believe=20
those tests would still be there if they weren't required to be.
> Someone else with precious little time and a chargeout rate to justify=20
> work with. And surprise - they won't like that in the slightest.=20
> Sometimes you get lucky - I spent about 10 hours of otherwise=20
> chargeable time in September's bug hunt (which I enjoyed a lot by the=20
> way) along with several evenings but generally everyday work will=20
> always lean towards ignoring contributions where no supporting=20
> "contribution overhead" has also been committed. Such=20
> contributions/patches/whatever can be horrible to work on. No tests,=20
> poor explanations, lack of communication, differing assumptions - ugh.=20
> If it's not worth contributing in full, don't expect someone else to=20
> do it - they probably won't.
I suspect many wont expect their contributions to be accepted -- and=20
instead of capitulating to the requirements, will simply abandon the=20
contribution.
>
> Sorry for the ranty piece - but code doesn't write itself. It is great=20
> to have a contribution - so long as you don't pin it all on someone=20
> else ;).
Pin what? When I developed the Zend PDF image parsers for example, I=20
didn't write any tests, I did functional testing to the best I could....=20
and we went from there. Those classes exist in the framework today in=20
basically the same format. That contribution process was very different=20
from today, but it worked great. I'd hate to think what it would take to=20
get a class as complicated as Zend_Pdf_Resource_Image_Tiff committed=20
today....
>
> Which one? Nobody said there would be one front controller.
For 99.999% of uses theres only one url, and only a need for one front=20
controller.
> My guess, is that it will be accessible from your bootstrap, which is=20
> registered to the front controller, which is registered to...I'm lost=20
> now.
I think you just made my point.
>
> Trace what under the hood?=20
> Request->Route->Dispatch->Controller->Action <- stick plugins in=20
> between. It's not rocket science.
Add into that Zend_Application->Zend_Config->Get Bootstrap Name=20
Setting->do whatever *secret sauce*->all before you get to the mvc=20
dispatch process above. Now, from the code source I looked at before,=20
its going to require creating some sort of methodinvokers, event=20
delegates and hooking into a series of events. Tracing back from output=20
to figure out where something is happening truly is a science these days=20
-- most of the time I end up pecking around in the leaves, instead of=20
tracing from the trunk. It gets even more complicated when you start=20
talking partials, helpers( think actionstack ), and the myriad of other=20
ways to inject into the request cycle.
> If you doubled the complexity of the implementation today, it would=20
> still quack like the same duck it was yesterday.
We agree here. Today is too complicated... Tomorrow will be too=20
complicated... I was hoping with 2.0 that we would figure out where the=20
redundancies are and nix em --> i'd start at the actionstack, but thats=20
just me. Now we're talking FSM's, and DI systems... which is cool in a=20
compsci kinda way, but fantastically complicated out of the box.

Is it a SDK, a black box, or are we helping people make applications=20
they understand? Whats the implication of blind use of the framework?
> Right now you can still conceptually grasp MVC and use it, without=20
> ever reading the source code. In fact, right now MVC is a pretty=20
> complex beast in ZF. It would take a serious effort to complicate it=20
> further :).
Theres a reason we write books on this stuff instead of user docs.....
>
> >Can a skilled PHP developer contribute a change to the framework easil=
y
> >without being involved in the ZFW core politics, contribution processe=
s,
> >proposal processes, test writing, doc writing, etc.
>
> ZF may be one of the few non-political projects around. I've had some=20
> fun of course butting heads in the past, but the last two years have=20
> been politics free. Everything else is answered "no". Who else is=20
> going to miraculously write someone else's tests/docs/proposals? Not=20
> me :P.
"No" is a policy, and its not a very good one.

$0.02

Kevin

--------------020100090807050905010309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
P&aacute;draic Brady wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <style type="text/css"><!-- DIV {margin:0px;} --></style>
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
The main wall Kevin just hit is simply never going away. If it ever
did, ZF wouldn't be far behind it as a untested, undocumented morass of
code that (allegedly) does stuff. </div>
</blockquote>
I doubt this greatly, ZF to 1.0 was a huge success and had none of this
stuff. A decent vetting by interested coders was all it took to keep
the quality up. Most of that code still comprises the code base today,
and it still runs fine. The docs were enough to get interested
developers over the initial hurdles and the rest came through other
sources like blogs, irc, books and sample code. I'm not saying we go
back to totally untested code or anything like that, I guess I just see
tests like icing, not an ingredient. If there's tests, great, if not,
put it on the todo and move on. Instead we've got tests that are at
times even counter-productive as you describe.<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">We
need all the "contribution overhead". It is absolutely essential. There
are components in the ZF which, to be generous, are pretty bad in terms
of testing, documentation and flexibility already - and that's with the
requirement! I have worse descriptions. Catch me on IRC during a bug
hunt and I'll share some ;).<br>
  </div>
</blockquote>
<br>
I'd argue that some of those components are bad in part because of the
requirement.<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
The fact is, if you cannot handle the additional work that underpins,
supports and ensures ease of maintenance for a component - then you are
begging for a developer to start swearing over IRC. I had the joy of
dealing with such a component a few weeks back. It took me hours to
figure out a bug. Why? Because the unit tests DID NOT TEST the
functionality of the component. I could have deleted every single test
with no ill effect - they were all busy with XML parsing or something
(performed by a completely different component with its own perfectly
functional unit tests).<br>
  </div>
</blockquote>
That sounds about right.<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
But worse than all this, is the assumption that lowering the
contribution overhead is a positive thing. It's not - it merely shifts
that work onto someone else. </div>
</blockquote>
That assumes that a large amount of this work isn't optional -- when it
is. Those useless tests are there because someone said 'must have
tests', many, possibly most, of them are totally unneeded except to up
the code coverage report statistics. A minority of the ZFW tests do any
useful testing, and for those, I'm glad there's tests... and I believe
those tests would still be there if they weren't required to be.<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Someone
else with precious little time and a chargeout rate to justify work
with. And surprise - they won't like that in the slightest. Sometimes
you get lucky - I spent about 10 hours of otherwise chargeable time in
September's bug hunt (which I enjoyed a lot by the way) along with
several evenings but generally everyday work will always lean towards
ignoring contributions where no supporting "contribution overhead" has
also been committed. Such contributions/patches/whatever can be
horrible to work on. No tests, poor explanations, lack of
communication, differing assumptions - ugh. If it's not worth
contributing in full, don't expect someone else to do it - they
probably won't.<br>
  </div>
</blockquote>
I suspect many wont expect their contributions to be accepted -- and
instead of capitulating to the requirements, will simply abandon the
contribution.<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
Sorry for the ranty piece - but code doesn't write itself. It is great
to have a contribution - so long as you don't pin it all on someone
else ;).<br>
  </div>
</blockquote>
Pin what? When I developed the Zend PDF image parsers for example, I
didn't write any tests, I did functional testing to the best I
could.... and we went from there. Those classes exist in the framework
today in basically the same format. That contribution process was very
different from today, but it worked great. I'd hate to think what it
would take to get a class as complicated as
Zend_Pdf_Resource_Image_Tiff committed today....<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
Which one? Nobody said there would be one front controller.</div>
</blockquote>
For 99.999% of uses theres only one url, and only a need for one front
controller. <br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">My
guess, is that it will be accessible from your bootstrap, which is
registered to the front controller, which is registered to...I'm lost
now. </div>
</blockquote>
I think you just made my point.<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
Trace what under the hood?
Request-&gt;Route-&gt;Dispatch-&gt;Controller-&gt;Action &lt;- stick
plugins in between. It's not rocket science. </div>
</blockquote>
Add into that Zend_Application-&gt;Zend_Config-&gt;Get Bootstrap Name
Setting-&gt;do whatever *secret sauce*-&gt;all before you get to the
mvc dispatch process above. Now, from the code source I looked at
before, its going to require creating some sort of methodinvokers,
event delegates and hooking into a series of events. Tracing back from
output to figure out where something is happening truly is a science
these days -- most of the time I end up pecking around in the leaves,
instead of tracing from the trunk. It gets even more complicated when
you start talking partials, helpers( think actionstack ), and the
myriad of other ways to inject into the request cycle. <br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">If
you doubled the complexity of the implementation today, it would still
quack like the same duck it was yesterday. </div>
</blockquote>
We agree here. Today is too complicated... Tomorrow will be too
complicated... I was hoping with 2.0 that we would figure out where the
redundancies are and nix em --&gt; i'd start at the actionstack, but
thats just me. Now we're talking FSM's, and DI systems... which is cool
in a compsci kinda way, but fantastically complicated out of the box.<br>
<br>
Is it a SDK, a black box, or are we helping people make applications
they understand? Whats the implication of blind use of the framework?<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Right
now you can still conceptually grasp MVC and use it, without ever
reading the source code. In fact, right now MVC is a pretty complex
beast in ZF. It would take a serious effort to complicate it further :).<br>
  </div>
</blockquote>
Theres a reason we write books on this stuff instead of user docs..... <br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
&gt;Can a skilled PHP developer contribute a change to the framework
easily<br>
&gt;without being involved in the ZFW core politics, contribution
processes,<br>
&gt;proposal processes, test writing, doc writing, etc.<br>
  <br>
ZF may be one of the few non-political projects around. I've had some
fun of course butting heads in the past, but the last two years have
been politics free. Everything else is answered "no". Who else is going
to miraculously write someone else's tests/docs/proposals? Not me :P.<br>
  </div>
</blockquote>
"No" is a policy, and its not a very good one.<br>
<br>
$0.02<br>
<br>
Kevin<br>
</body>
</html>

--------------020100090807050905010309--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 2 Jun 2009 14:56:30 -0400
From: "Sean P. O. MacCath-Moran" <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Seeking "ZF Contributor" Mentor

Greetings ZF Community,

I'm looking for a mentor for my first foray into Open Source development.

I am a Zend Certified Engineer with over a decade development
experience (ref http://www.emanaton.com/cv). My CLA has been received
and approved. I've read through the various entries on the
framework.zend site for how the contribution process and proposal
life-cycles function. I'm currently developing code for a project that
mirrors a Component Proposal, but that proposal has been dormant for
some time (i.e.
http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+Rob+Allen).
I wrote to that proposal's author, Rob Allen, and received word that
he is no longer working on that project, giving the go ahead to work
on it. Therefore, I would like to go through the process of proposing,
discussing, developing, and submitting this code.

All that aside, I've never contributed directly to an open source
project before. So, rather than flailing about for the answers
anymore, I'd like to proposition an experienced member(s) of the team
for a bit of guidance. I'm probably not going to require much
hand-holding, but I would very much like to have someone(s) I can
touch base with and make sure that I'm heading in the right direction
from time to time.

Is there anyone who would feel comfortable fullfilling such a role?
Should I just use this list and get general feedback? If the latter,
would anyone care to advise me on my next step? e.g., should I create
a new proposal, or should I be taking over the original one somehow?

Thanks in advance!

Sean P. O. MacCath-Moran
www.emanaton.com

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 12 Jan 2010 08:14:00 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] PHP error in framework docs search results.

-- Ryan Vennell <[email-masked]> wrote
(on Monday, 11 January 2010, 04:09 PM -0600):
> I put in the search term "timezone" in the reference guide, and got a whole
> page full of errors:
> http://framework.zend.com/manual/search?query=timezone&language=en&search=
> Search+Manual!
> 
> Example:
> Notice: Undefined offset: 159 in /var/www/website-release-1.9.7/framework/
> library/Zend/Search/Lucene/Search/Query/MultiTerm.php on line 480
> 
> They're all pretty much identical, but the offset changes for each error.

The site got checked into production with a bad value for
display_errors; I've corrected that in production at this point.

Regarding the undefined offset notices, I'll be discussing these with
Alex, as they're indicative of potential issues in the Lucene component.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 10:50:57 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Discussion about Quality/Review Process -
	Community RM proposal

-- till <[email-masked]> wrote
(on Wednesday, 23 September 2009, 04:40 PM +0200):
> On Wed, Sep 23, 2009 at 4:20 PM, Carlton Gibson
> <[email-masked]> wrote:
> > (...)
> > Fair enough. Perhaps the ability to comment will be enough --- my concern is
> > simply that of lowering the barrier to entry... :-)
> 
> Two cents on documentation and user interfaction.
> 
> IMHO, user comments could be a great way to...
> 
>  * spot obvious issues/shortcomings with the existing documentation
> (e.g. if people are asking the same thing over and over maybe we need
> an additional example, or rephrase whatever is written in the manual)
>  * gather general feedback and additional tips
> 
> In the end responsible people (who signed a CLA) could transform these
> comments into jira issues (API?).

Yes -- that's exactly the intention with having comments.

> I think one of the greatest advantages of PHP's documentation system
> is that people can leave comments.

Exactly -- and that's why we want to open it up in this way. PHP's
comment system is a true gem in the OSS world, and a great model to
build off.

> Of course they may need to be moderated and therefor not only provide
> advantages but also disadvantages (time is always tight), but maybe
> the advantages overrule the possible disadvantages.

We can mitigate some of the moderation by using captchas and akismet,
but will still require some interaction. We'll see how much is needed
once we implement it. :)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 24 Mar 2009 23:17:04 +0100
From: Tobias Gies <[email-masked]>
To: Wil Sinclair <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Release date for 1.8

*ahem*

Even if it is not well-promoted (and, AFAIK, not archived) this
mailing list is public - so I doubt your aim towards secrecy will last
for too long.

Anyways, I won't be the whistleblower. ;-)

Best regards,
Tobias

2009/3/24 Wil Sinclair <[email-masked]>:
> Hi all, I=92m going to do something a little new for this release, but I =
ask
> that you all do me a favor in return. I=92m announcing the dates for the
> release. The favor that I ask is that you do not discuss these dates outs=
ide
> of this list. Yes, I know that the dates will likely get out anyways- I=
=92m
> just asking you not to immediately go out and tweet/blog them. J Let=92s =
try
> to build some suspense with our users.
>
> With no further do:
>
>
>
> Preview Release on 4/7: All features going in to ZF 1.8 must be committed=
 by
> EOD 4/5. We are currently working to get through all the pending proposal=
s
> by EOW, but feel free to ping me if you=92re concerned about a specific
> proposal.
>
>
>
> Final Release on 4/28: Code freeze on 4/21. That=92s a hard-stop so have
> everything ready to go by that date or be prepared to wait months for the
> next minor release.
>
>
>
> These dates won=92t be a death-march, but I do put a lot of effort in to
> making sure that we don=92t miss dates that other teams within Zend or at=
 our
> partners are depending on.
>
> Feel free to mail me directly if you have any concerns.
>
>
>
> Thanks! It will be an exciting next month or so.
>
> ,Wil

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 18 Nov 2009 08:29:47 +0100
To: [email-masked]
From: Lars Kneschke <[email-masked]>
Organization: Metaways Infosystems GmbH
Subject: [zf-contributors] Zend_json_Client or How to start contributing

--b1_1b4c4b2fa3316c6a8434addc50c4ed50
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: quoted-printable

Hello!

For our project Tine 2.0, we implemented Zend_Json_Client. It's modelled
after Zend_XmlRpc_Client and I would like to contribute it.

I signed the CLA. That was easy. But now I'm searching for the best, to =
get
in contact with right person to merge my work with the existsing
Zend_Json_Server codbase.

The code is available at http://svn.tine20.org/svn/trunk/tine20/Zend/Json/ =
.

We also have extended Zend_Json_Server to handle batched request.=20

What is the right way to move forward on this issue?=20
What is the right way to discuss the needed changes with the maintainer of
Zend_Json?

For the future there are also some other minor issues we like to help =
with.
--
Lars Kneschke
Team Leader Business Solutions
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

Tine 2.0 now with Calendar, Email and ActiveSync=3D> =
http://www.tine20.org/

E-Mail: mailto:[email-masked]
Web: http://www.metaways.de
Tel: +49 (0) 40 317031-21
Fax: +49 (0) 40 317031-921
Mobile: +49 (0) 175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsb=C3=BCttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Gesch=C3=A4ftsf=C3=BChrung: Hermann Thaele, L=C3=BCder-H.Thaele

--b1_1b4c4b2fa3316c6a8434addc50c4ed50
Content-Type: text/html; charset = "utf-8"
Content-Transfer-Encoding: quoted-printable

Hello!<br />
<br />
For our project Tine 2.0, we implemented Zend_Json_Client. It's modelled =
after Zend_XmlRpc_Client and I would like to contribute it.<br />
<br />
I signed the CLA. That was easy. But now I'm searching for the best, to =
get in contact with right person to merge my work with the existsing =
Zend_Json_Server codbase.<br />
<br />
The code is available at http://svn.tine20.org/svn/trunk/tine20/Zend/Json/ =
.<br />
<br />
We also have extended Zend_Json_Server to handle batched request. <br />
<br />
What is the right way to move forward on this issue? <br />
What is the right way to discuss the needed changes with the maintainer of =
Zend_Json?<br />
<br />
For the future there are also some other minor issues we like to help =
with.<hr style=3D"border:dotted 1px silver; width:90%; border:dotted 1px =
silver;">Lars Kneschke<br />
Team Leader Business Solutions<br />
Metaways Infosystems GmbH<br />
Pickhuben 2-4, D-20457 Hamburg<br />
<br />
Tine 2.0 now with Calendar, Email and ActiveSync=3D&gt; =
http://www.tine20.org/<br />
<br />
E-Mail: mailto:[email-masked]<br />
Web: http://www.metaways.de<br />
Tel: +49 (0) 40 317031-21<br />
Fax: +49 (0) 40 317031-921<br />
Mobile: +49 (0) 175 9304324<br />
<br />
Metaways Infosystems GmbH - Sitz: D-22967 Tremsb&uuml;ttel<br />
Handelsregister: Amtsgericht Ahrensburg HRB 4508<br />
Gesch&auml;ftsf&uuml;hrung: Hermann Thaele, L&uuml;der-H.Thaele

--b1_1b4c4b2fa3316c6a8434addc50c4ed50--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 15:36:54 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: "[email-masked]" <[email-masked]>
Mail-Followup-To: "[email-masked]"
	<[email-masked]>
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

-- Jon Whitcraft <[email-masked]> wrote
(on Friday, 10 April 2009, 03:11 PM -0400):
> If I understand you correctly I could rename  
> Zend_Service_Amazon_Abstract to Zend_Service_Amazon_Awsobject and have  
> the ec2 and s3 classes extend it?

Zend_Service_Amazon_AwsObject, yes (note camelCasing). That's the basic
idea.

> On Apr 10, 2009, at 2:24 PM, Matthew Weier O'Phinney <[email-masked]> 
> wrote:
>
>> Greetings, all --
>>
>> Below is a proposal I am making to modify the Zend Framework Coding
>> Standards conventions for the naming of Interfaces and Abstract  
>> classes.
>>
>> This decision is basically already made, but I'd appreciate any  
>> feedback
>> that you may have on the matter.
>>
>> Thanks!
>>
>> The problem
>> ===========
>> PHP 5.3 introduces namespaces to the PHP language. While this won't  
>> have an
>> impact much on userland code, it will have an impact on library and  
>> framework
>> code, as it provides a useful paradigm for organizing components as  
>> well as
>> simplifying syntax. Instead of having to say things like:
>>
>>    $analyzer = new  
>> Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
>>
>> we can instead do something like this:
>>
>>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>>
>>    $analyzer = new Common_TextNum();
>>
>> or even:
>>
>>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>>
>>    class Common_TextNum extends Common
>>    {
>>    }
>>
>> The problem that arises for Zend Framework has to do with how we name 
>> abstract
>> classes and interfaces. Currently, the final segment of such classes  
>> are
>> expected to end with _Abstract and _Interface, respectively. This will 
>> not work
>> when we migrate to utilize namespaces, for two reasons.
>>
>> First, and most obviously, 'abstract' and 'interface' are reserved PHP 
>> keywords.
>> As such, in situations such as the following:
>>
>>    namespace Zend\Controller\Request;
>>
>>    class Abstract
>>    {
>>    }
>>
>>    // or:
>>
>>    namespace Zend\Controller\Dispatcher;
>>
>>    interface Interface
>>    {
>>    }
>>
>> we'll run into issues.
>>
>> Second, and less obvious, is that perhaps the easiest solution breaks 
>> one of the
>> key principles of namespaces (which are designed to help encapsulate
>> components). This one's harder to explain, so let's look at examples. 
>> Consider a
>> component such as Zend_Controller_Request. The simplest solution would 
>> be to
>> name the abstract class or interface Zend\Controller\Request, and then 
>> have the
>> various concrete implementations under that namespace:
>>
>>    namespace Zend\Controller;
>>
>>    interface Request
>>    {
>>    }
>>
>>    // and concrete ones:
>>
>>    namespace Zend\Controller\Request;
>>
>>    class Http
>>    {
>>    }
>>
>> What's the problem here? The interface is not in the same namespace as 
>> the
>> concrete implementations.
>>
>> Potential solutions and recommendation
>> ======================================
>> So, how should Zend Framework "solve" these issues? A number of  
>> proposals and
>> recommendations have been floated around, both within ZF circles and  
>> in the
>> greater PHP community.
>>
>> Considerations include:
>>
>> * Avoiding the use of PHP reserved keywords (already noted).
>> * Avoiding Hungarian Notation (i.e., having the name or a portion of  
>> the name
>>   describe its type -- which, to a degree, the current naming  
>> conventions
>>   already violate). (See 
>> http://en.wikipedia.org/wiki/Hungarian_Notation, the
>>   sections "Disadvantages of Systems Hungarian" and "Notable Opinions" 
>> for some
>>   of the arguments against using Hungarian Notation.)
>>
>> Approaches that have been considered include:
>>
>> * Using 'I' to prefix interfaces. This derives from standards in other
>>   programming languages (.Net and python, in particular). This is just 
>> another
>>   form of Hungarian Notation, however.
>>
>> * Using "Interface" or "Abstract" as a class name suffix:  
>> RequestInterface,
>>   RequestAbstract. Again, however this is Hungarian Notation.
>>
>> * Using the term "Base" for abstract classes: BaseRequest,  
>> RequestBase, Base.
>>   This is just substituting the word Base for Abstract, however, and  
>> is really
>>   not much different than the above.
>>
>> * Use generic, descriptive names indicative of functionality or  
>> behavior. As
>>   examples from the SPL, "Countable", "Iterator", "ArrayObject".
>>
>> My recommendation is to use the latter, as it solves all  
>> considerations. It will
>> take more thought when naming, but will ensure that components can  
>> live in a
>> self-contained namespace, do not use reserved keywords, and avoid  
>> Hungarian
>> Notation.
>>
>> Plan for implementation
>> =======================
>> I recommend that the Coding Standards documentation be updated to  
>> reflect this
>> approach.
>>
>> All new components going into 1.8 and onwards should adopt these  
>> standards. In
>> releases 1.9 and forward, we will begin migrating existing  
>> interfaces/abstract
>> classe. First, new classes/interfaces will be created that follow  
>> these
>> conventions and which extend the originals; later, any type-hinting  
>> based on the
>> original class/interface names will be updated to point to the new  
>> names; and
>> finally, in 2.0, we will remove the old interfaces/abstract classes  
>> entirely.
>>
>> -- 
>> Matthew Weier O'Phinney
>> Software Architect      | [email-masked]
>> Zend Framework          | http://framework.zend.com/
>

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 02 Feb 2010 00:43:12 +0530
From: Sudheer Satyanarayana <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Status of Zend_Service_ShortenUrl?

Hi,

What's the status of the proposal 
http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_ShortenUrl+-+Martin+Hujer 
?

Looking at the Wiki, it appears, the proposal requires review from Zend 
liaison.

-- 

With warm regards,
Sudheer. S
Tech stuff: http://techchorus.net
Business: http://binaryvibes.co.in

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 1 Apr 2010 13:19:10 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

Ralph and I were just talking about this, and had a realization.

is_callable() returns true for objects that implement __invoke().

What this means is: even for filter chains and the like, we simply test
to see if what was passed is callable. If not, we throw an exception or
use another strategy. (In Phly_PubSub, if I get a non-callable first
argument, I check for a second argument, which would be the method to
call on the first argument.)

As such, he and I are leaning towards no definition of __invoke() in the
interface, but defining it in the abstract classes and/or concrete
classes that implement the interface. This solves the issue of ensuring
clear interfaces, while also solving the issue of using __invoke() as a
general-purpose, consistent callback paradigm within the framework.

Thoughts?

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Thursday, 01 April 2010, 11:43 AM -0400):
> -- Dolf Schimmel <[email-masked]> wrote
> (on Thursday, 01 April 2010, 04:48 PM +0200):
> > > Now, since the Symfony Live conference, I've also been thinking abo=
ut
> > > something Fabien said about Symfony 2: "less magic." To clarify, th=
e
> > > idea is to design components so that they are explicit about what t=
hey
> > > can do. As an example, instead of using __get() and __set(), using
> > > explicit getters and setters; instead of using __call(), explicitly
> > > defining methods; instead of having __call() proxy to helpers, havi=
ng a
> > > broker from which you pull them as needed.
> >=20
> > Apparently the rumors on twitter were in place; the conference did
> > have a bad influence on you :D
>=20
> Umm... there are good ideas everywhere, and bad ones as well. Neither Z=
F
> nor SF have a monopoloy on either.
>=20
> > More seriously, I think this can in no way be compared with SF's
> > "magic" (does the fact that our Zend_Magic only is imaginative mean Z=
F
> > does at this moment not contain any magic?).
>=20
> I wasn't trying to explicitly link the two. In fact, the examples I gav=
e
> were examples of applying Fabien's ideas to ZF.
>=20
> > Firstly, if you have a class called foo\Filter which contains an
> > __invoke() method,
> > that method should obviously filter. As long as it does that and only
> > that, there's no magic imho involved.=20
>=20
> I can see this POV. For somebody who doesn't know what the interface's
> purpose is, however, it's less clear. Let me point that out with your
> next examples:
>=20
> > Same goes for foo\Validator (its
> > __invoke() method is supposed to validate), and foo\Bootstrap (guess
> > what: __invoke() should bootstrap here).=20
>=20
> Validator defines two method types: validation, and error message
> retrieval. In the original interface, this is pretty clear: isValid()
> and getMessages(). If we change to __invoke() and getMessages(), the
> latter method is clear, but the former is not -- what exactly is
> happening here?
>=20
> Looking at the bootstrap, this is also a bit more unclear: right now, w=
e
> have a bootstrap() method and a run() method: which one does __invoke()
> define? Resources might be a bit more clear: the init() method might
> make sense to instead map to __invoke() -- but the intent is less clear=
.
> init() at least implies that we're initializing something; what does
> __invoke() do?
>=20
> > If we can get it done consistently I'm pretty sure everybody will be
> > used to it within the first 5 seconds they look at a random piece of
> > code.
>=20
> I *do* want to see consistency. I just don't want to sacrifice end-user
> comprehension of the code. Our current usage of __call(), __get(), and
> __set() throughout the framework *does* make the code less easy to
> understand. I've had plenty of people indicate that they have had
> trouble understanding view helpers because they can't find the methods
> in the view object; I don't want the same thing happening with usage of
> __invoke().
>=20
> > Secondly Symfony's magic is on an entirely different scale of
> > magnitude than the naming of one type of method.  Compare
> > $random->method() generating an entire application for you with
> > $object() which exactly does what the name of the object implies.
>=20
> Please see my notes above. I wasn't talking about this type of magic.
>=20
> > Situations in which you have two methods doing exactly the same are
> > often/usually a result of willing to change, but also struggling with
> > inability to do so due to backwards compatibility constraints.
> > However, now that we're busy on something where potentially all BC ma=
y
> > be broken, I really don't think having two methods doing exactly the
> > same would be beneficial to anybody. In fact, it would increase the
> > amount of options to do something with (give or take) N! which is an
> > awful lot, without any added value.
>=20
> This is the primary argument I can see against having both an explicit
> method name defined and __invoke(), and it hits home with other
> complaints about the current state of ZF: understanding how ZF is
> difficult when there's more than one way to do things.
>=20
> I want to be clear that the primary reason for using __invoke() in the
> first place is for dynamic calls using call_user_func() and
> call_user_func_array(). While using __invoke() with these is faster tha=
n
> a traditional callback, it's still way slower than calling the method
> directly -- around 3 times slower. __invoke() simply provides a slight
> optimization in a pattern that we're likely to use many, many times
> throughout a given request.
>=20
> For single usage, though, would you rather do this:
>=20
>     $value =3D $plugin($data);
>=20
>     or:
>=20
>     $value =3D $plugin->filter($data);
>=20
> I realize it's a bit contrived -- you might name the object to better
> describe its purpose. However, the latter more clearly explains what
> you're doing to the data: you're filtering it. Let's look at a
> validator:
>=20
>     $test =3D $plugin($value);
>=20
>     or:
>=20
>     $test =3D $plugin->isValid($value);
>=20
> I actually think this one benefits a ton -- even with a well-named
> variable:
>=20
>     $test =3D $validator($value);
>=20
> What is "$validator"? and what is it doing here? When we call the
> method, we know we're checking for validity; when we call it via
> __invoke(), we could be filtering it, validating it, pushing in a
> value... who knows?
>=20
> In my earlier post, I probably should have made it more clear: I see
> __invoke() as a way to more easily and efficiently define and execute
> *callbacks*, and hence my rationale that it makes sense to define both
> an explicit method as well as __invoke() for those class types that wil=
l
> be used with filter chains and/or brokers.
>=20
>=20
> > On Thu, Apr 1, 2010 at 3:07 PM, Matthew Weier O'Phinney
> > <[email-masked]> wrote:
> > > I've been following this thread as well as discussions on IRC with
> > > interest, as, honestly, I can completely buy into all arguments, wh=
ich
> > > are, to sum things up:
> > >
> > > =A0* Use only __invoke()
> > > =A0* Use a method name specific to the interface
> > > =A0* Use a standardized method name, such as "run" or "execute"
> > > =A0* Use a combination of __invoke() and either a meaningful or
> > > =A0 standardized method name.
> > >
> > > I got to thinking about why I suggested "__invoke()" in the first p=
lace,
> > > and went back to the plugin architecture page:
> > >
> > > =A0* http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architect=
ures
> > >
> > > The original rationale was for using pubsub/filter chain systems. I=
n
> > > such systems, you attach callbacks:
> > >
> > > =A0 =A0$chain->attach($callback);
> > >
> > > If your objects implement __invoke(), $callback can simply be your
> > > object -- you're done. Otherwise, you also have to provide the meth=
od:
> > >
> > > =A0 =A0$chain->attach($object, $method);
> > >
> > > Interestingly, in this document, I also recommended that for existi=
ng
> > > interfaces, __invoke() be added as an _additional_ method, and that=
 it
> > > should proxy to the appropriate interface method. In this case, we'=
d
> > > simply be taking advantage of a language feature in places it makes
> > > sense.
> > >
> > > Now, since the Symfony Live conference, I've also been thinking abo=
ut
> > > something Fabien said about Symfony 2: "less magic." To clarify, th=
e
> > > idea is to design components so that they are explicit about what t=
hey
> > > can do. As an example, instead of using __get() and __set(), using
> > > explicit getters and setters; instead of using __call(), explicitly
> > > defining methods; instead of having __call() proxy to helpers, havi=
ng a
> > > broker from which you pull them as needed.
> > >
> > > This has several implications:
> > >
> > > =A0* Less need for explicit documentation. If you have behaviors re=
lying
> > > =A0 on the magic methods, developers *must* read the the documentat=
ion in
> > > =A0 order to know how a class/component works. If everything is exp=
licit,
> > > =A0 the class is self-documenting, and you can get the information =
you
> > > =A0 need from API docs, your IDE, etc.
> > >
> > > =A0* Performance. Magic methods are reportedly less performant than=
 using
> > > =A0 straight method calls (more on this later).
> > >
> > > These are important factors, and the test-driven developer in me
> > > particularly likes less magic; it's much easier to test when you ha=
ve
> > > explicit behaviors.
> > >
> > > That said, I decided to run some tests. These were the scenarios:
> > >
> > > =A0* No Proxying:
> > > =A0 * Defined "filter" method returns value
> > > =A0 * Defined "__call" method returns value
> > > =A0 * Defined "__invoke" method returns value
> > > =A0* Proxying:
> > > =A0 * Defined "filter" method returns value
> > > =A0 * Defined "__call" method proxies to "filter"
> > > =A0 * Defined "__invoke" method proxies to "filter"
> > > =A0* Inverse proxying
> > > =A0 * Defined "filter" method calls invoke (as "$this();")
> > > =A0 * Defined "__invoke" method returns value
> > > =A0* call_user_func_array()
> > > =A0 * Using array($obj, 'filter') callback
> > > =A0 * Using __invoke() with no proxying
> > > =A0 * Using __invoke() with proxying
> > >
> > > The results were quite interesting. Across the board, using __call(=
) is
> > > awful -- even if you simply return a value, it's on average 6x slow=
er
> > > than a straight method call; proxying to another method, however,
> > > doesn't take significantly longer (so long as you're not using
> > > call_user_func_array() internally, that is).
> > >
> > > __invoke(), however, turns out to be quite different. When not prox=
ying,
> > > it's actually *faster* than a method call (about 25% on average).
> > > Proxing __invoke() to a method call or doing the inverse are roughl=
y the
> > > same speed -- about 2.5x slower than a straight method call (which,=
 as
> > > you'll note, is still over twice as fast as using __call()).
> > >
> > > What was *really* interesting, however, was using
> > > call_user_func_array(), which is commonly used in filter chains and=
/or
> > > brokers. =A0__invoke(), with or without proxying, *always* was arou=
nd 30%
> > > *faster* than using an explicit array($obj, $method) callback.
> > >
> > > So, what does this tell me?
> > >
> > > =A0* AVOID using __call(), particularly for often-used method calls=
. For
> > > =A0 helper systems, it will always be better to use a helper broker=
 and
> > > =A0 command pattern.
> > >
> > > =A0* For classes meant to be used primarily with filter chains or b=
rokers,
> > > =A0 DO use __invoke(), even if it simply proxies to another interfa=
ce
> > > =A0 method.
> > >
> > > So, based on the design goals and the performance benchmarking, I'm
> > > going to recommend that Filter and Validator (we renamed Validate t=
o
> > > Validator) define an __invoke() method in addition to a more explic=
it
> > > interface method, and that helpers also follow this pattern.
> > >
> > > -- Matthew Weier O'Phinney <[email-masked]> wrote
> > > (on Wednesday, 31 March 2010, 10:21 AM -0400):
> > >> Greetings, all --
> > >>
> > >> Per the roadmap, one change we're planning on making is making plu=
gin
> > >> usage consistent across components: plugins will implement __invok=
e(),
> > >> which makes them inherently callable.
> > >>
> > >> In our refactoring branch, I've done this now with Zend_Filter. Ho=
wever,
> > >> it required a ton of refactoring on the unit tests (had to either =
call
> > >> __invoke() directly, or $filter($value)), and it got me to thinkin=
g:
> > >>
> > >> Would it make sense to keep the original interfaces (filter, isVal=
id,
> > >> render, etc.), but also implement __invoke() -- having it proxy to=
 the
> > >> appropriate interface method?
> > >>
> > >> As an example:
> > >>
> > >> =A0 =A0 interface Filter
> > >> =A0 =A0 {
> > >> =A0 =A0 =A0 =A0 public function filter($value);
> > >> =A0 =A0 =A0 =A0 public function __invoke($value);
> > >> =A0 =A0 }
> > >>
> > >> =A0 =A0 class Digits implements Filter
> > >> =A0 =A0 {
> > >> =A0 =A0 =A0 =A0 public function filter($value)
> > >> =A0 =A0 =A0 =A0 {
> > >> =A0 =A0 =A0 =A0 =A0 =A0 // ... logic...
> > >> =A0 =A0 =A0 =A0 }
> > >>
> > >> =A0 =A0 =A0 =A0 public function __invoke($value)
> > >> =A0 =A0 =A0 =A0 {
> > >> =A0 =A0 =A0 =A0 =A0 =A0 return $this->filter($value);
> > >> =A0 =A0 =A0 =A0 }
> > >> =A0 =A0 }
> > >>
> > >> The benefits:
> > >>
> > >> =A0* Fewer changes necessary to existing unit tests
> > >> =A0* interface method names may be more descriptive of intent
> > >>
> > >> Problems:
> > >>
> > >> =A0* Using __invoke() introduces overhead -- 2 method calls instea=
d of one
> > >> =A0* Redundancy (two methods doing the same thing)
> > >> =A0* A few extra tests to write (to ensure __invoke works as expec=
te)
> > >>
> > >> After discussion with Ralph and Alex, I'm leaning towards having
> > >> __invoke() as an _additional_ method, instead of replacing existin=
g
> > >> methods.
> > >>
> > >> Any thoughts or comments?
> > >>
> > >> --
> > >> Matthew Weier O'Phinney
> > >> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> > >> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> > >> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> > >>
> > >
> > > --
> > > Matthew Weier O'Phinney
> > > Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> > > Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> > > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> > >
> >=20
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 20 May 2009 22:38:00 +0200
From: till <[email-masked]>
To: Vincent de Lau <[email-masked]>
Cc: Ralph Schindler <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Zend_Session

On Wed, May 20, 2009 at 10:22 PM, Vincent de Lau <[email-masked]> wrote:
>> So question is, do we really need exceptions here at all costs or
>> could we utilize PHP's error handler (e.g. E_NOTICE, E_USER_WARNING)
>> etc.. Point taken, it may be harder to grasp for the novice developer
>> but display_errors, log_errors etc. are all sort of no-brainers and I
>> see them as beginners stuff when it comes to developing PHP. I'd be
>> very much in favor of ditching exceptions all together in this
>> package.
>>
>> (This is more or less a RFC, of course.)
>
> I don't think the biggest problem lies within the session package itself.
> Exceptions can be raised by external components, like Zend_Db. These must
> also be available at save time.

Probably didn't make myself too clear last night - I want to trap
those exceptions and expose them via trigger_error() instead.

Till

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Mon, 25 Jan 2010 18:45:49 +0100
To: Kevin McArthur <[email-masked]>
Cc: Diego Henrique Oliveira <[email-masked]>,
	[email-masked]
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

I would indeed like to see some (reproducable) benchmarks that show a
significant improvement

-- Freeaqingme

On Mon, Jan 25, 2010 at 5:39 PM, Kevin McArthur <[email-masked]> wrote:
> The performance difference between a * and selected columns will be almos=
t
> nil.... short of something like an unmaterialized and complex view [in th=
e
> db sense] that is.
>
> I'd think this would add a fair amount of complication to the api and
> codebase for what will be, for most people, practically zero benefit.
> In-fact, for most, the additional requirement of a couple method invocati=
ons
> and string operations will likely negate the effect of not returning the
> extraneous columns in the first place.
>
> I'd vote no on this change.
>
> Kevin
>
>
> Diego Henrique Oliveira wrote:
>>
>> In the adapter DbTable, the generated query to the database is a 'select
>> *', and as it was being a bottleneck in my application (users table with
>> many fields), i made these changes in the component
>> Zend_Auth_Adapter_DbTable.
>>
>>
>> class Zend_Auth_Adapter_DbTable
>> {
>> =C2=A0 =C2=A0 =C2=A0protected $_returnedFields;
>> =C2=A0 =C2=A0 =C2=A0public function setReturnedFields( array $fields )
>> =C2=A0 =C2=A0{
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_returnedFields =3D $fields;
>> =C2=A0 =C2=A0}
>> =C2=A0 =C2=A0 =C2=A0public function getReturnedFields()
>> =C2=A0 =C2=A0{
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (is_null($this->_returnedFields))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return array('*');
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0return $this->_returnedFields;
>> =C2=A0 =C2=A0}
>> =C2=A0 =C2=A0 =C2=A0/**
>> =C2=A0 =C2=A0 * _authenticateCreateSelect() - This method creates a Zend=
_Db_Select
>> object that
>> =C2=A0 =C2=A0 * is completely configured to be queried against the datab=
ase.
>> =C2=A0 =C2=A0 *
>> =C2=A0 =C2=A0 * @return Zend_Db_Select
>> =C2=A0 =C2=A0 */
>> =C2=A0 =C2=A0protected function _authenticateCreateSelect()
>> =C2=A0 =C2=A0{
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0// build credential expression
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (empty($this->_credentialTreatment) ||
>> (strpos($this->_credentialTreatment, '?') =3D=3D=3D false)) {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_credentialTreatment =3D=
 '?';
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0$credentialExpression =3D new Zend_Db_Expr(
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'(CASE WHEN ' .
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_zendDb->quoteInto(
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_zendDb->q=
uoteIdentifier($this->_credentialColumn,
>> true)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. ' =3D ' . $this=
->_credentialTreatment, $this->_credential
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. ' THEN 1 ELSE 0 END) AS '
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. $this->_zendDb->quoteIdentifi=
er(
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->_zendDb->f=
oldCase('zend_auth_credential_match')
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0);
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0// get select
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0$fields =C2=A0 =3D $this->getReturnedFields()=
;
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0array_push( $fields, $credentialExpression );
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0$dbSelect =3D clone $this->getDbSelect();
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0$dbSelect->from($this->_tableName, $fields)
>>
>> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . =
' =3D
>> ?', $this->_identity);
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0return $dbSelect;
>> =C2=A0 =C2=A0}
>> =C2=A0 }
>>
>>
>>
>> What you guys think about these changes? And should I submit them to the
>> project?
>>
>>
>> Cheers
>>
>> Diego
>> http://diegoholiveira.com
>>
>

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 05:36:46 -0800
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Your solution for Zend Framework being too complicated for new users
is to split it up into 7 different, overlapping downloads?  And you
don't think that would make it much more confusing?

I think more documentation is the answer; more diagrams, for starters.

-Matt

On Tuesday, November 17, 2009, drm <[email-masked]> wrote:
> Hi,
>
>
> It helps me to regress to the point where I started using Zend Framework.=
 One of this first things I found confusing was the grand amount of directo=
ries and classes, while ZF in fact is quite a light-weight framework, (I me=
an, the MVC framework, which is probably what most people talk about anyway=
, when talking about ZF). It also annoyed me a little bit, since I had to u=
pload large amounts of files (especially Zend_Locale and Zend_GData), which=
 could cost a lot of time in my case, where I build many relatively small w=
ebsites on both shared and single servers, sometimes only with FTP access.
>
> I was thinking it might be nice to get some packaging done in 2.0, at lea=
st in the documentation, and maybe in release packages. The "minimal" packa=
ge, really isn't that "minimal" (20 MB unpacked, about 2300 files). I was t=
hinking it might be nice to split things up in a few builds that would make=
 ZF a bit simpler for the first-timer, and more effective for repetetive us=
ers.
>
> Core components (Config, Loader)
> MVC (Core + Controller, Application, View, Layout and all related depende=
ncies)
> MVC+ (MVC + Form, Filter, Validate, Db and all related dependencies)
> Starter (MVC+ + Tool, CodeGenerator and related dependencies + binscripts=
)
> Common libraries (Acl, Auth, Mail, Mime, Cache)
> Data libraries (Currency, Locale, Date, Measure)
> Utility libraries (All remaining packages from current minimal)
>
> As a beginner, you could start off with the "Starter" package, to get sta=
rted learning the core of the MVC framework, without being confused by pack=
ages like GData and InfoCard, to avoid the "What does this button do?"-effe=
ct. I also think, one of the USP's of ZF is that it is usable as a full-sta=
cked framework, and as a code library (or both). I think packaging might re=
flect (and encourage) this better. All strictly unnessecary dependencies wo=
uld ideally be eliminated to avoid cascading and recursive dependencies to =
achieve this. All necessary dependencies could be documented and registered=
 in a package builder, or just documentation.
>
> I think that is one of the issues that will help reel people in getting m=
ore involved, because it will help understanding the framework's basic stru=
cture, and get them up and running quickly ( < 1MB starter sandbox? )
>
> I am aware of the fact that it might be rather time-consuming to maintain=
 this structure, but we could get started by documenting a dependency tree =
for each of the directories in the current 1.9 minimal package, and automat=
e some build process for it?
>
>
> Regards,
> Gerard
>
>
> Matthew Weier O'Phinney wrote:
>
> -- Jurri=C3=ABn Stutterheim <[email-masked]> wrote
> (on Sunday, 15 November 2009, 08:21 PM +0100):
>
>
> The ideas and discussions for ZF 2.0 have been great so far, and I'm
> really looking forward to the actual release!
>
> There's a non-technical issue that ZF 2.0 should try to tackle. This
> issue is getting beginners up to speed quickly, and to get people more
> involved in the community.
>
>
>
> This is an initiative the Zend team is currently working on, actually.
> We have begun writing a series of tutorials that will be a part of the
> manual:
>
>  =C2=A0 =C2=A0http://framework.zend.com/svn/framework/standard/branches/u=
ser/zf-devteam/documentation/en/
>
> We're getting some "core" tutorials out there, but then plan to use the
> proposal process to get new content in (either to request new content,
> or submit new content).
>
> That said, it needs to be a core requirement for 2.0 as well,
> particularly since some areas will be changing dramatically.
>
>
>
> First off, developers should get the tools and knowledge to get
> started with developing right away. The Quickstart is doing great with
> this, but it could probably use a dedicated chapter for setting up a
> development environment. That is, Zend Server and PDT/ZSfE or
> Netbeans, with full debugging support etc.
>
>
>
> This is a good point. I've had to answer a number of questions regarding
> setting up virtual hosts over the past months -- something I took for
> granted as a basic skill. I'll add this to my current TODO.
>
>
>
> What comes next is probably where ZF is currently lacking most.
> Currently the documentation we have are the quickstart, followed by
> the reference guide. For me - someone who's been using ZF since around
> v0.2 - that's perfectly fine, but the step is too big for a beginner.
>
>
>
> The tutorials we're creating will be in a "Learning Zend Framework"
> section that follows the introduction; this will be followed by the
> current "Reference Guide" section. The way it will be shown is:
>
>  =C2=A0 =C2=A0 I. Introduction to Zend Framework
>  =C2=A0 =C2=A0II. Learning Zend Framework
>  =C2=A0 III. Reference Guide
>  =C2=A0 =C2=A0IV. Appendixes
>
>
>
> Basically two things need to be made clear to someone who just
> finished the quickstart: how does the ZF community work (where can I
> get help, how can I help, etc.), and where do I go from here?
>
>
> Good point on the community stuff. However, that part has traditionally
> been the realm of the main website and wiki -- not the manual.
>
>
>
> Paddy has been doing some amazing work on the latter question with his
> Survive The Deep End book, that's freely available online
> (http://www.survivethedeepend.com/). Why not make this a permanent
> link on the ZF homepage, between quickstart and reference guide? =C2=A0Th=
e
> former ("where can I get help/how can I help") could be made more
> clear to make links to the mailing lists and #zftalk and #zftalk.dev
> more visible on the ZF frontpage.
>
>
> There have been a few notes about the mailing list visibility on the
> website, and I'm hoping to address that soon.
>
>
>
> Expanding on the community point a bit, it might be a good thing to
> keep the level of experience of developers in mind on the wiki and the
> mailing list. Paddy and Kevin touched this topic in their discussion
> in this thread, and I've read the term "too compsci-y" somewhere in
> that discussion too. To be perfectly honest, I'm completely fine with
> discussions and proposals that expect some compsci experience from the
> reader. That said, it might be a good thing to get people without a
> compsci degree in on the discussions as well, which is probably
> actually quite a large group of people in the PHP world. For example,
> the Zend_Controller 2.0 proposal mentions an FSM. For people that do
> not know what an FSM is, a reference to an introductory article on
> FSMs might be interesting. In a discussion I had with a friend we
> couldn't agree on how this could be achieved best, without dumbing
> things down too much. I'd be interested to hear your opinions on this.
>
>
>
> I can agree with this to a point. Right now, I'm trying to get primarily
> architectural feedback, which really requires a fair bit of discussion
> of design patterns and CS concepts.
> When it's time for official proposals, we'll be focussing primarily on
> use cases -- and *that* is where we can make things simpler and address
> the full range of ZF developers. I figure the following:
>
>  =C2=A0 =C2=A0$application =3D new \zend\Application(
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0APPLICATION_ENV,  =C2=A0 =C2=A0 =C2=A0 =C2=A0=
APPLICATION_PATH . '/configs/application.ini'
>  =C2=A0 =C2=A0);
>  =C2=A0 =C2=A0$application->bootstrap()
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0->run();
>
> and:
>
>  =C2=A0 =C2=A0// Add a listener for pre-action dispatch:
>  =C2=A0 =C2=A0$manager =3D $this->getResource('event_manager');
>  =C2=A0 =C2=A0$pubsub =C2=A0=3D $manager->getPubSub();
>  =C2=A0 =C2=A0$pubsub->subscribe('mvc.dispatcher.pre', 'my\plugins\Contex=
tNegotiation');
>
> and:
>
>  =C2=A0 =C2=A0// Indicate it's time to send the response:
>  =C2=A0 =C2=A0$e->setState('response');
>  =C2=A0 =C2=A0return;
>
> are concepts the end-user can easily grasp without needing to know a
> whole lot about how it actually works internally.
>
>
>
>
> On Nov 11, 2009, at 19:38 , Matthew Weier O'Phinney wrote:
>
>
>
> Hey, all --
>
> There have been a ton of questions about the ZF 2.0 roadmap, and my
> answer has been consistently, "I'm working on it; I'll have something to
> publish soon."
>
> "Soon" is now:
>
>  =C2=A0 http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+=
Roadmap
>
> I'd like you, as contributors, to look over it, and start discussing the
> various ramifications; we can do that either in comments to the pages or
> on this list.
>
> The roadmap is primarily a conceptual one right now, though a
> proof-of-concept has been created for the proposed MVC. I'd like to stay
> fairly high-level for now, and then start getting a flow of proposals
> into the system for specific migration-related tasks.
>
> Thanks everyone who has provided me input over the past many months, and
> let's get started on the next generation of ZF!
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 08 May 2009 09:36:39 -0500
From: Ralph Schindler <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Session

I am all for a rewrite here, but I think we need to determine the scope, 
and list out the decidedly "good" requirements.

>  * separation of setting PHP's session.* INI values into a single
>    component
>  * Ability to specify the source array to which the session object will
>    proxy (i.e., allowing specifying a different array than $_SESSION);
>    most likely, this will need to be by reference.  This will be
>    necessary to allow easy testing.

I think what Matthew is referencing here is moving the core of 
Zend_Session, which is ext/session, into an adapter.  This would allow 
Zend_Session to specify an interface for develpers to write their own 
adapters.

The only caveat is that developers will have to be very mindful of the 
"glue" aspect of sessions.  This is, not only how data is stored, but 
also how to manage the cookies (url rewriters, but not so much since 
those are out of style), and other web persistence (or any other 
environment) mechanisms.

>    * __destruct() should then write the source array

__destruct() was also my first guess on the first writing of the 
component, but this proves to be VERY difficult.  In PHP, there is no 
"logical" destruction order.  Destruction order is determined by the 
number of outstanding references there are left to an object. 
Typically, destruction is triggered either when the last reference is 
destroyed, OR automagically at PHP SHUTDOWN time.

The other problem is that since __destruct happens at PHP shutdown time, 
you cannot throw any exception or you will get an E_FATAL, no stack 
pointer error.

The last issues is that since namespaces ultimately represent 
related/recursive/tree data, writing one without writing another might 
cause inconsistencies in the session datastore.

>  * Keeping Zend_Session_Namespace as BC as possible with the above
>    guidelines
> 

Yes, the namespace data object is the gem of Zend_Session.  In OO- 
applications it affords different modules/elements/aspects of a singular 
codebase some data security.

So, all that said... I am very interested to see what you can come up with!

-ralph

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 17:21:03 -0800 (PST)
From: Diego Henrique Oliveira <[email-masked]>
To: Ralph Schindler <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

--0-473735921-1264468863=:50933
Content-Type: text/plain; charset=us-ascii

I agree with you about breaking the table users in several tables is the best solution. However the application I'm working on is just a part of another larger application, which is developed by another company, so I can't just break the database tables.

The bank in question is MySQL and the bottleneck that I was having is the return of unnecessary data. Maybe I could be wrong and seeing the need for performance where it does not exist (hypothesis not discarded).

My point in posting here was just to ask the opinion of everyone, who obviously has more experience than me.

Regards.

________________________________
From: Ralph Schindler <[email-masked]>
To: Diego Henrique Oliveira <[email-masked]>
Cc: [email-masked]
Sent: Mon, January 25, 2010 6:58:43 PM
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

I am not sure I see a lot of value here.  What kind of bottleneck are you seeing?  Considering this function should only be run once during the lifespan of a user's session, I am not sure why it would be that big of an issue.

Returning 20 vs. 4 columns generally has no consequence on the result at all, what vendor DB are you using where this is a concern?

Furthermore, perhaps you should break out authentication information from the user table itself and instead use a join with the select object? Just a thought.

-ralph

Diego Henrique Oliveira wrote:
> In the adapter DbTable, the generated query to the database is a 'select *', and as it was being a bottleneck in my application (users table with many fields), i made these changes in the component Zend_Auth_Adapter_DbTable.
> 
> 
> class Zend_Auth_Adapter_DbTable
> {
>        protected $_returnedFields;
>        public function setReturnedFields( array $fields )
>     {
>         $this->_returnedFields = $fields;
>     }
>        public function getReturnedFields()
>     {
>         if (is_null($this->_returnedFields))
>         {
>             return array('*');
>         }
>         return $this->_returnedFields;
>     }
>        /**
>      * _authenticateCreateSelect() - This method creates a Zend_Db_Select object that
>      * is completely configured to be queried against the database.
>      *
>      * @return Zend_Db_Select
>      */
>     protected function _authenticateCreateSelect()
>     {
>         // build credential expression
>         if (empty($this->_credentialTreatment) || (strpos($this->_credentialTreatment, '?') === false)) {
>             $this->_credentialTreatment = '?';
>         }
> 
>         $credentialExpression = new Zend_Db_Expr(
>             '(CASE WHEN ' .
>             $this->_zendDb->quoteInto(
>                 $this->_zendDb->quoteIdentifier($this->_credentialColumn, true)
>                 . ' = ' . $this->_credentialTreatment, $this->_credential
>                 )
>             . ' THEN 1 ELSE 0 END) AS '
>             . $this->_zendDb->quoteIdentifier(
>                 $this->_zendDb->foldCase('zend_auth_credential_match')
>                 )
>             );
> 
>         // get select
>         $fields   = $this->getReturnedFields();
>         array_push( $fields, $credentialExpression );
>         $dbSelect = clone $this->getDbSelect();
>         $dbSelect->from($this->_tableName, $fields)
>                  ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . ' = ?', $this->_identity);
> 
>         return $dbSelect;
>     }
>    }
> 
> 
> 
> What you guys think about these changes? And should I submit them to the project?
> 
> 
> Cheers
> 
> Diego
> http://diegoholiveira.com
> 

--0-473735921-1264468863=:50933
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:verdana,helvetica,sans-serif;font-size:10pt"><div>I agree with you about breaking the table users in several tables is the best solution. However the application I'm working on is just a part of another larger application, which is developed by another company, so I can't just break the database tables.<br><br>The bank in question is MySQL and the bottleneck that I was having is the return of unnecessary data. Maybe I could be wrong and seeing the need for performance where it does not exist (hypothesis not discarded).<br><br>My point in posting here was just to ask the opinion of everyone, who obviously has more experience than me.<br><br>Regards.<br><br><br></div><div style="font-family: verdana,helvetica,sans-serif; font-size: 10pt;"><br><div style="font-family: verdana,helvetica,sans-serif; font-size: 10pt;"><font face="Tahoma" size="2"><hr
 size="1"><b><span style="font-weight: bold;">From:</span></b> Ralph Schindler &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">To:</span></b> Diego Henrique Oliveira &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">Cc:</span></b> [email-masked]<br><b><span style="font-weight: bold;">Sent:</span></b> Mon, January 25, 2010 6:58:43 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable<br></font><br>
I am not sure I see a lot of value here.&nbsp; What kind of bottleneck are you seeing?&nbsp; Considering this function should only be run once during the lifespan of a user's session, I am not sure why it would be that big of an issue.<br><br>Returning 20 vs. 4 columns generally has no consequence on the result at all, what vendor DB are you using where this is a concern?<br><br>Furthermore, perhaps you should break out authentication information from the user table itself and instead use a join with the select object? Just a thought.<br><br>-ralph<br><br><br><br>Diego Henrique Oliveira wrote:<br>&gt; In the adapter DbTable, the generated query to the database is a 'select *', and as it was being a bottleneck in my application (users table with many fields), i made these changes in the component Zend_Auth_Adapter_DbTable.<br>&gt; <br>&gt; <br>&gt; class Zend_Auth_Adapter_DbTable<br>&gt; {<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; protected
 $_returnedFields;<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; public function setReturnedFields( array $fields )<br>&gt;&nbsp; &nbsp;  {<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  $this-&gt;_returnedFields = $fields;<br>&gt;&nbsp; &nbsp;  }<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; public function getReturnedFields()<br>&gt;&nbsp; &nbsp;  {<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  if (is_null($this-&gt;_returnedFields))<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  {<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  return array('*');<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  }<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  return $this-&gt;_returnedFields;<br>&gt;&nbsp; &nbsp;  }<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; /**<br>&gt;&nbsp; &nbsp; &nbsp; * _authenticateCreateSelect() - This method creates a Zend_Db_Select object that<br>&gt;&nbsp; &nbsp; &nbsp; * is completely configured to be queried against the database.<br>&gt;&nbsp; &nbsp; &nbsp; *<br>&gt;&nbsp; &nbsp; &nbsp; * @return
 Zend_Db_Select<br>&gt;&nbsp; &nbsp; &nbsp; */<br>&gt;&nbsp; &nbsp;  protected function _authenticateCreateSelect()<br>&gt;&nbsp; &nbsp;  {<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  // build credential expression<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  if (empty($this-&gt;_credentialTreatment) || (strpos($this-&gt;_credentialTreatment, '?') === false)) {<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  $this-&gt;_credentialTreatment = '?';<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  }<br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  $credentialExpression = new Zend_Db_Expr(<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  '(CASE WHEN ' .<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  $this-&gt;_zendDb-&gt;quoteInto(<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  $this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_credentialColumn, true)<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  . ' = ' . $this-&gt;_credentialTreatment,
 $this-&gt;_credential<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  )<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  . ' THEN 1 ELSE 0 END) AS '<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  . $this-&gt;_zendDb-&gt;quoteIdentifier(<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  $this-&gt;_zendDb-&gt;foldCase('zend_auth_credential_match')<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  )<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  );<br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  // get select<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  $fields&nbsp;  = $this-&gt;getReturnedFields();<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  array_push( $fields, $credentialExpression );<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  $dbSelect = clone $this-&gt;getDbSelect();<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  $dbSelect-&gt;from($this-&gt;_tableName, $fields)<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 -&gt;where($this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_identityColumn, true) . ' = ?', $this-&gt;_identity);<br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  return $dbSelect;<br>&gt;&nbsp; &nbsp;  }<br>&gt;&nbsp; &nbsp; }<br>&gt; <br>&gt; <br>&gt; <br>&gt; What you guys think about these changes? And should I submit them to the project?<br>&gt; <br>&gt; <br>&gt; Cheers<br>&gt; <br>&gt; Diego<br><span>&gt; <a target="_blank" href="http://diegoholiveira.com">http://diegoholiveira.com</a></span><br>&gt; <br></div></div>
<!-- cg17.c2.mail.re1.yahoo.com compressed/chunked Fri Jan 22 15:30:01 PST 2010 -->
</div><br>

      </body></html>
--0-473735921-1264468863=:50933--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 11:20:00 +0100
From: Giorgio Sironi <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

On Tue, Mar 16, 2010 at 8:53 AM, Andy Thompson <[email-masked]> wrote:
> Suffixing the class name with its intent seems like the best way in my
> opinion. In my own libraries, I've been frustrated with the way I might have
> 3 or 4 of the same filenames open e.g. Field\DateTime.php,
> Filter\DateTime.php, Validate\DateTime.php and Element\DateTime.php (though
> that last one I've now renamed to DateTimeSelect).

A single-word suffix really adds significance to the name. In Doctrine
2, which has a namespaced codebase, Roman told me the policy is the
basename of a class should always have a meaning by itself (i.e.
Doctrine\ORM\Persisters\SingleTablePersister;
Doctrine\ORM\Mapping\OneToOneMapping).
At least if it's not an internal class of a component, this is a
useful convention; no one cares about Doctrine\ORM\Query\TreeWalker
not being QueryTreeWalker because it's not meant to be referred out of
Doctrine\ORM\Query.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 17:46:54 +0100
From: Giorgio Sironi <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: [zf-contributors] ZF 2.0 development begins!

--0016e6d64082cc554a04806f87f2
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]>wrote:

> I like the idea (as David Caunt mentioned) of releasing a 1.X branch with
> Doctrine 1 to test the waters and judging by the amount of work required
> decide to go with Doc2+ZF2 when the time comes.
>

Beware that Doctrine 1 and Doctrine 2 are very different: the fomer is
ActiveRecord-based while the latter on the UnitOfWork pattern. Their
metadata management is not the same and 2.x is a complete rewrite of 1.x.

Regards,
-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d64082cc554a04806f87f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><div class=3D"gmail_quote"><div class=3D"im">On =
Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&=
gt;</span> wrote:<br>
</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"border-l=
eft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:=
 1ex;">
I like the idea (as David Caunt mentioned) of releasing a 1.X branch with D=
octrine 1 to test the waters and judging by the amount of work required dec=
ide to go with Doc2+ZF2 when the time comes.<br clear=3D"all"></blockquote>

</div><div><br>Beware that Doctrine 1 and Doctrine 2 are very different: th=
e fomer is ActiveRecord-based while the latter on the UnitOfWork pattern. T=
heir metadata management is not the same and 2.x is a complete rewrite of 1=
.x.<br>

</div></div><div><div></div><br clear=3D"all"></div></div>Regards,<br>-- <b=
r>Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br><a href=3D"http:=
//giorgiosironi.blogspot.com">http://giorgiosironi.blogspot.com</a><br><a h=
ref=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgiosironi</=
a><br>

--0016e6d64082cc554a04806f87f2--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Sat, 28 Mar 2009 18:05:32 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.7.8 sanity check packages are now available

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B00A.6E541D5A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all!

=20

The sanity check packages for ZF 1.7.8 are now available here:

http://framework.zend.com/releases/preview/ZendFramework-1.7.8.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8.zip

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-apidoc.ta
r.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-apidoc.zi
p

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-de
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-de
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-en
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-en
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-fr
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-fr
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-ja
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-ja
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-ru
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-ru
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-zh
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.7.8-manual-zh
.zip

=20

Note that this is *NOT* the official release of 1.7.8. If we find no
major issues with these builds, we will issue official 1.7.8 release
from this tag soon.=20

Please do *NOT* log any issues found in these archives in the issue
tracker; instead post any major functional or packaging issues to this
list or mail them to me directly ([email-masked]).

=20

With best regards,

   Alexander Veremyev.

=20

------_=_NextPart_001_01C9B00A.6E541D5A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@SimSun";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:2.0cm 69.6pt 2.0cm 69.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Hi all!</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>The sanity check packages for ZF 1.7.8 are =
now
available here:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8.ta=
r.gz">http://framework.zend.com/releases/preview/ZendFramework-1.7.8.tar.=
gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8.zi=
p">http://framework.zend.com/releases/preview/ZendFramework-1.7.8.zip</a>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ap=
idoc.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-1.7=
.8-apidoc.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ap=
idoc.zip">http://framework.zend.com/releases/preview/ZendFramework-1.7.8-=
apidoc.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-de.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.7.8-manual-de.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-de.zip">http://framework.zend.com/releases/preview/ZendFramework-1.7=
.8-manual-de.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-en.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.7.8-manual-en.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-en.zip">http://framework.zend.com/releases/preview/ZendFramework-1.7=
.8-manual-en.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-fr.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.7.8-manual-fr.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-fr.zip">http://framework.zend.com/releases/preview/ZendFramework-1.7=
.8-manual-fr.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-ja.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.7.8-manual-ja.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-ja.zip">http://framework.zend.com/releases/preview/ZendFramework-1.7=
.8-manual-ja.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-ru.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.7.8-manual-ru.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-ru.zip">http://framework.zend.com/releases/preview/ZendFramework-1.7=
.8-manual-ru.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-zh.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.7.8-manual-zh.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.7.8-ma=
nual-zh.zip">http://framework.zend.com/releases/preview/ZendFramework-1.7=
.8-manual-zh.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Note that this is *NOT* the official release =
of 1.7.8.
If we find no major issues with these builds, we will issue official =
1.7.8
release from this tag soon. </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Please do *NOT* log any issues found in these =
archives
in the issue tracker; instead post any major functional or packaging =
issues to
this list or mail them to me directly =
([email-masked]).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>With best regards,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Alexander =
Veremyev.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9B00A.6E541D5A--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 14:39:58 +0100
From: =?UTF-8?B?0KHQsNGI0LAg0KHRgtCw0LzQtdC90LrQvtCy0LjRmw==?=
	<[email-masked]>
To: Matthew Ratzloff <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0016e6d7eb46217e6a04789143d5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think flexibility is the biggest downside and upside at the same time for
zf.

More flexibility -> harder to get in.

For advanced developers, zf is perfect choice, never will get into any
limitations.

Regards,
Sa=C5=A1a Stamenkovi=C4=87

On Tue, Nov 17, 2009 at 2:36 PM, Matthew Ratzloff
<[email-masked]>wrote:

> Your solution for Zend Framework being too complicated for new users
> is to split it up into 7 different, overlapping downloads?  And you
> don't think that would make it much more confusing?
>
> I think more documentation is the answer; more diagrams, for starters.
>
> -Matt
>
> On Tuesday, November 17, 2009, drm <[email-masked]> wrote:
> > Hi,
> >
> >
> > It helps me to regress to the point where I started using Zend Framewor=
k.
> One of this first things I found confusing was the grand amount of
> directories and classes, while ZF in fact is quite a light-weight framewo=
rk,
> (I mean, the MVC framework, which is probably what most people talk about
> anyway, when talking about ZF). It also annoyed me a little bit, since I =
had
> to upload large amounts of files (especially Zend_Locale and Zend_GData),
> which could cost a lot of time in my case, where I build many relatively
> small websites on both shared and single servers, sometimes only with FTP
> access.
> >
> > I was thinking it might be nice to get some packaging done in 2.0, at
> least in the documentation, and maybe in release packages. The "minimal"
> package, really isn't that "minimal" (20 MB unpacked, about 2300 files). =
I
> was thinking it might be nice to split things up in a few builds that wou=
ld
> make ZF a bit simpler for the first-timer, and more effective for repetet=
ive
> users.
> >
> > Core components (Config, Loader)
> > MVC (Core + Controller, Application, View, Layout and all related
> dependencies)
> > MVC+ (MVC + Form, Filter, Validate, Db and all related dependencies)
> > Starter (MVC+ + Tool, CodeGenerator and related dependencies +
> binscripts)
> > Common libraries (Acl, Auth, Mail, Mime, Cache)
> > Data libraries (Currency, Locale, Date, Measure)
> > Utility libraries (All remaining packages from current minimal)
> >
> > As a beginner, you could start off with the "Starter" package, to get
> started learning the core of the MVC framework, without being confused by
> packages like GData and InfoCard, to avoid the "What does this button
> do?"-effect. I also think, one of the USP's of ZF is that it is usable as=
 a
> full-stacked framework, and as a code library (or both). I think packagin=
g
> might reflect (and encourage) this better. All strictly unnessecary
> dependencies would ideally be eliminated to avoid cascading and recursive
> dependencies to achieve this. All necessary dependencies could be documen=
ted
> and registered in a package builder, or just documentation.
> >
> > I think that is one of the issues that will help reel people in getting
> more involved, because it will help understanding the framework's basic
> structure, and get them up and running quickly ( < 1MB starter sandbox? )
> >
> > I am aware of the fact that it might be rather time-consuming to mainta=
in
> this structure, but we could get started by documenting a dependency tree
> for each of the directories in the current 1.9 minimal package, and autom=
ate
> some build process for it?
> >
> >
> > Regards,
> > Gerard
> >
> >
> > Matthew Weier O'Phinney wrote:
> >
> > -- Jurri=C3=ABn Stutterheim <[email-masked]> wrote
> > (on Sunday, 15 November 2009, 08:21 PM +0100):
> >
> >
> > The ideas and discussions for ZF 2.0 have been great so far, and I'm
> > really looking forward to the actual release!
> >
> > There's a non-technical issue that ZF 2.0 should try to tackle. This
> > issue is getting beginners up to speed quickly, and to get people more
> > involved in the community.
> >
> >
> >
> > This is an initiative the Zend team is currently working on, actually.
> > We have begun writing a series of tutorials that will be a part of the
> > manual:
> >
> >
> http://framework.zend.com/svn/framework/standard/branches/user/zf-devteam=
/documentation/en/
> >
> > We're getting some "core" tutorials out there, but then plan to use the
> > proposal process to get new content in (either to request new content,
> > or submit new content).
> >
> > That said, it needs to be a core requirement for 2.0 as well,
> > particularly since some areas will be changing dramatically.
> >
> >
> >
> > First off, developers should get the tools and knowledge to get
> > started with developing right away. The Quickstart is doing great with
> > this, but it could probably use a dedicated chapter for setting up a
> > development environment. That is, Zend Server and PDT/ZSfE or
> > Netbeans, with full debugging support etc.
> >
> >
> >
> > This is a good point. I've had to answer a number of questions regardin=
g
> > setting up virtual hosts over the past months -- something I took for
> > granted as a basic skill. I'll add this to my current TODO.
> >
> >
> >
> > What comes next is probably where ZF is currently lacking most.
> > Currently the documentation we have are the quickstart, followed by
> > the reference guide. For me - someone who's been using ZF since around
> > v0.2 - that's perfectly fine, but the step is too big for a beginner.
> >
> >
> >
> > The tutorials we're creating will be in a "Learning Zend Framework"
> > section that follows the introduction; this will be followed by the
> > current "Reference Guide" section. The way it will be shown is:
> >
> >      I. Introduction to Zend Framework
> >     II. Learning Zend Framework
> >    III. Reference Guide
> >     IV. Appendixes
> >
> >
> >
> > Basically two things need to be made clear to someone who just
> > finished the quickstart: how does the ZF community work (where can I
> > get help, how can I help, etc.), and where do I go from here?
> >
> >
> > Good point on the community stuff. However, that part has traditionally
> > been the realm of the main website and wiki -- not the manual.
> >
> >
> >
> > Paddy has been doing some amazing work on the latter question with his
> > Survive The Deep End book, that's freely available online
> > (http://www.survivethedeepend.com/). Why not make this a permanent
> > link on the ZF homepage, between quickstart and reference guide?  The
> > former ("where can I get help/how can I help") could be made more
> > clear to make links to the mailing lists and #zftalk and #zftalk.dev
> > more visible on the ZF frontpage.
> >
> >
> > There have been a few notes about the mailing list visibility on the
> > website, and I'm hoping to address that soon.
> >
> >
> >
> > Expanding on the community point a bit, it might be a good thing to
> > keep the level of experience of developers in mind on the wiki and the
> > mailing list. Paddy and Kevin touched this topic in their discussion
> > in this thread, and I've read the term "too compsci-y" somewhere in
> > that discussion too. To be perfectly honest, I'm completely fine with
> > discussions and proposals that expect some compsci experience from the
> > reader. That said, it might be a good thing to get people without a
> > compsci degree in on the discussions as well, which is probably
> > actually quite a large group of people in the PHP world. For example,
> > the Zend_Controller 2.0 proposal mentions an FSM. For people that do
> > not know what an FSM is, a reference to an introductory article on
> > FSMs might be interesting. In a discussion I had with a friend we
> > couldn't agree on how this could be achieved best, without dumbing
> > things down too much. I'd be interested to hear your opinions on this.
> >
> >
> >
> > I can agree with this to a point. Right now, I'm trying to get primaril=
y
> > architectural feedback, which really requires a fair bit of discussion
> > of design patterns and CS concepts.
> > When it's time for official proposals, we'll be focussing primarily on
> > use cases -- and *that* is where we can make things simpler and address
> > the full range of ZF developers. I figure the following:
> >
> >     $application =3D new \zend\Application(
> >         APPLICATION_ENV,         APPLICATION_PATH .
> '/configs/application.ini'
> >     );
> >     $application->bootstrap()
> >                 ->run();
> >
> > and:
> >
> >     // Add a listener for pre-action dispatch:
> >     $manager =3D $this->getResource('event_manager');
> >     $pubsub  =3D $manager->getPubSub();
> >     $pubsub->subscribe('mvc.dispatcher.pre',
> 'my\plugins\ContextNegotiation');
> >
> > and:
> >
> >     // Indicate it's time to send the response:
> >     $e->setState('response');
> >     return;
> >
> > are concepts the end-user can easily grasp without needing to know a
> > whole lot about how it actually works internally.
> >
> >
> >
> >
> > On Nov 11, 2009, at 19:38 , Matthew Weier O'Phinney wrote:
> >
> >
> >
> > Hey, all --
> >
> > There have been a ton of questions about the ZF 2.0 roadmap, and my
> > answer has been consistently, "I'm working on it; I'll have something t=
o
> > publish soon."
> >
> > "Soon" is now:
> >
> >
> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
> >
> > I'd like you, as contributors, to look over it, and start discussing th=
e
> > various ramifications; we can do that either in comments to the pages o=
r
> > on this list.
> >
> > The roadmap is primarily a conceptual one right now, though a
> > proof-of-concept has been created for the proposed MVC. I'd like to sta=
y
> > fairly high-level for now, and then start getting a flow of proposals
> > into the system for specific migration-related tasks.
> >
> > Thanks everyone who has provided me input over the past many months, an=
d
> > let's get started on the next generation of ZF!
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead            | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> >
> >
> >
> >
> >
> >
> >
>

--0016e6d7eb46217e6a04789143d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think flexibility is the biggest downside and upside at the same time for=
 zf.<div><br></div><div>More flexibility -&gt; harder to get in.</div><div>=
<br></div><div>For advanced developers, zf is perfect choice, never will ge=
t into any limitations.<br clear=3D"all">
<br>Regards,<br>Sa=C5=A1a Stamenkovi=C4=87<br>
<br><br><div class=3D"gmail_quote">On Tue, Nov 17, 2009 at 2:36 PM, Matthew=
 Ratzloff <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
Your solution for Zend Framework being too complicated for new users<br>
is to split it up into 7 different, overlapping downloads? =C2=A0And you<br=
don&#39;t think that would make it much more confusing?<br>
<br>
I think more documentation is the answer; more diagrams, for starters.<br>
<br>
-Matt<br>
<div><div></div><div class=3D"h5"><br>
On Tuesday, November 17, 2009, drm &lt;<a href=3D"mailto:[email-masked]">drm@m=
elp.nl</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; It helps me to regress to the point where I started using Zend Framewo=
rk. One of this first things I found confusing was the grand amount of dire=
ctories and classes, while ZF in fact is quite a light-weight framework, (I=
 mean, the MVC framework, which is probably what most people talk about any=
way, when talking about ZF). It also annoyed me a little bit, since I had t=
o upload large amounts of files (especially Zend_Locale and Zend_GData), wh=
ich could cost a lot of time in my case, where I build many relatively smal=
l websites on both shared and single servers, sometimes only with FTP acces=
s.<br>

&gt;<br>
&gt; I was thinking it might be nice to get some packaging done in 2.0, at =
least in the documentation, and maybe in release packages. The &quot;minima=
l&quot; package, really isn&#39;t that &quot;minimal&quot; (20 MB unpacked,=
 about 2300 files). I was thinking it might be nice to split things up in a=
 few builds that would make ZF a bit simpler for the first-timer, and more =
effective for repetetive users.<br>

&gt;<br>
&gt; Core components (Config, Loader)<br>
&gt; MVC (Core + Controller, Application, View, Layout and all related depe=
ndencies)<br>
&gt; MVC+ (MVC + Form, Filter, Validate, Db and all related dependencies)<b=
r>
&gt; Starter (MVC+ + Tool, CodeGenerator and related dependencies + binscri=
pts)<br>
&gt; Common libraries (Acl, Auth, Mail, Mime, Cache)<br>
&gt; Data libraries (Currency, Locale, Date, Measure)<br>
&gt; Utility libraries (All remaining packages from current minimal)<br>
&gt;<br>
&gt; As a beginner, you could start off with the &quot;Starter&quot; packag=
e, to get started learning the core of the MVC framework, without being con=
fused by packages like GData and InfoCard, to avoid the &quot;What does thi=
s button do?&quot;-effect. I also think, one of the USP&#39;s of ZF is that=
 it is usable as a full-stacked framework, and as a code library (or both).=
 I think packaging might reflect (and encourage) this better. All strictly =
unnessecary dependencies would ideally be eliminated to avoid cascading and=
 recursive dependencies to achieve this. All necessary dependencies could b=
e documented and registered in a package builder, or just documentation.<br=

&gt;<br>
&gt; I think that is one of the issues that will help reel people in gettin=
g more involved, because it will help understanding the framework&#39;s bas=
ic structure, and get them up and running quickly ( &lt; 1MB starter sandbo=
x? )<br>

&gt;<br>
&gt; I am aware of the fact that it might be rather time-consuming to maint=
ain this structure, but we could get started by documenting a dependency tr=
ee for each of the directories in the current 1.9 minimal package, and auto=
mate some build process for it?<br>

&gt;<br>
&gt;<br>
&gt; Regards,<br>
&gt; Gerard<br>
&gt;<br>
&gt;<br>
&gt; Matthew Weier O&#39;Phinney wrote:<br>
&gt;<br>
&gt; -- Jurri=C3=ABn Stutterheim &lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt; wrote<br>
&gt; (on Sunday, 15 November 2009, 08:21 PM +0100):<br>
&gt;<br>
&gt;<br>
&gt; The ideas and discussions for ZF 2.0 have been great so far, and I&#39=
;m<br>
&gt; really looking forward to the actual release!<br>
&gt;<br>
&gt; There&#39;s a non-technical issue that ZF 2.0 should try to tackle. Th=
is<br>
&gt; issue is getting beginners up to speed quickly, and to get people more=
<br>
&gt; involved in the community.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; This is an initiative the Zend team is currently working on, actually.=
<br>
&gt; We have begun writing a series of tutorials that will be a part of the=
<br>
&gt; manual:<br>
&gt;<br>
&gt; =C2=A0=C2=A0 =C2=A0<a href=3D"http://framework.zend.com/svn/framework/=
standard/branches/user/zf-devteam/documentation/en/" target=3D"_blank">http=
://framework.zend.com/svn/framework/standard/branches/user/zf-devteam/docum=
entation/en/</a><br>

&gt;<br>
&gt; We&#39;re getting some &quot;core&quot; tutorials out there, but then =
plan to use the<br>
&gt; proposal process to get new content in (either to request new content,=
<br>
&gt; or submit new content).<br>
&gt;<br>
&gt; That said, it needs to be a core requirement for 2.0 as well,<br>
&gt; particularly since some areas will be changing dramatically.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; First off, developers should get the tools and knowledge to get<br>
&gt; started with developing right away. The Quickstart is doing great with=
<br>
&gt; this, but it could probably use a dedicated chapter for setting up a<b=
r>
&gt; development environment. That is, Zend Server and PDT/ZSfE or<br>
&gt; Netbeans, with full debugging support etc.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; This is a good point. I&#39;ve had to answer a number of questions reg=
arding<br>
&gt; setting up virtual hosts over the past months -- something I took for<=
br>
&gt; granted as a basic skill. I&#39;ll add this to my current TODO.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; What comes next is probably where ZF is currently lacking most.<br>
&gt; Currently the documentation we have are the quickstart, followed by<br=
&gt; the reference guide. For me - someone who&#39;s been using ZF since ar=
ound<br>
&gt; v0.2 - that&#39;s perfectly fine, but the step is too big for a beginn=
er.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; The tutorials we&#39;re creating will be in a &quot;Learning Zend Fram=
ework&quot;<br>
&gt; section that follows the introduction; this will be followed by the<br=
&gt; current &quot;Reference Guide&quot; section. The way it will be shown =
is:<br>
&gt;<br>
&gt; =C2=A0=C2=A0 =C2=A0 I. Introduction to Zend Framework<br>
&gt; =C2=A0=C2=A0 =C2=A0II. Learning Zend Framework<br>
&gt; =C2=A0=C2=A0 III. Reference Guide<br>
&gt; =C2=A0=C2=A0 =C2=A0IV. Appendixes<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Basically two things need to be made clear to someone who just<br>
&gt; finished the quickstart: how does the ZF community work (where can I<b=
r>
&gt; get help, how can I help, etc.), and where do I go from here?<br>
&gt;<br>
&gt;<br>
&gt; Good point on the community stuff. However, that part has traditionall=
y<br>
&gt; been the realm of the main website and wiki -- not the manual.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Paddy has been doing some amazing work on the latter question with his=
<br>
&gt; Survive The Deep End book, that&#39;s freely available online<br>
&gt; (<a href=3D"http://www.survivethedeepend.com/" target=3D"_blank">http:=
//www.survivethedeepend.com/</a>). Why not make this a permanent<br>
&gt; link on the ZF homepage, between quickstart and reference guide? =C2=
=A0The<br>
&gt; former (&quot;where can I get help/how can I help&quot;) could be made=
 more<br>
&gt; clear to make links to the mailing lists and #zftalk and #zftalk.dev<b=
r>
&gt; more visible on the ZF frontpage.<br>
&gt;<br>
&gt;<br>
&gt; There have been a few notes about the mailing list visibility on the<b=
r>
&gt; website, and I&#39;m hoping to address that soon.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Expanding on the community point a bit, it might be a good thing to<br=
&gt; keep the level of experience of developers in mind on the wiki and the=
<br>
&gt; mailing list. Paddy and Kevin touched this topic in their discussion<b=
r>
&gt; in this thread, and I&#39;ve read the term &quot;too compsci-y&quot; s=
omewhere in<br>
&gt; that discussion too. To be perfectly honest, I&#39;m completely fine w=
ith<br>
&gt; discussions and proposals that expect some compsci experience from the=
<br>
&gt; reader. That said, it might be a good thing to get people without a<br=
&gt; compsci degree in on the discussions as well, which is probably<br>
&gt; actually quite a large group of people in the PHP world. For example,<=
br>
&gt; the Zend_Controller 2.0 proposal mentions an FSM. For people that do<b=
r>
&gt; not know what an FSM is, a reference to an introductory article on<br>
&gt; FSMs might be interesting. In a discussion I had with a friend we<br>
&gt; couldn&#39;t agree on how this could be achieved best, without dumbing=
<br>
&gt; things down too much. I&#39;d be interested to hear your opinions on t=
his.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I can agree with this to a point. Right now, I&#39;m trying to get pri=
marily<br>
&gt; architectural feedback, which really requires a fair bit of discussion=
<br>
&gt; of design patterns and CS concepts.<br>
&gt; When it&#39;s time for official proposals, we&#39;ll be focussing prim=
arily on<br>
&gt; use cases -- and *that* is where we can make things simpler and addres=
s<br>
&gt; the full range of ZF developers. I figure the following:<br>
&gt;<br>
&gt; =C2=A0=C2=A0 =C2=A0$application =3D new \zend\Application(<br>
&gt; =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0APPLICATION_ENV, =C2=A0=C2=A0 =C2=A0 =
=C2=A0 =C2=A0APPLICATION_PATH . &#39;/configs/application.ini&#39;<br>
&gt; =C2=A0=C2=A0 =C2=A0);<br>
&gt; =C2=A0=C2=A0 =C2=A0$application-&gt;bootstrap()<br>
&gt; =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-&gt;run(=
);<br>
&gt;<br>
&gt; and:<br>
&gt;<br>
&gt; =C2=A0=C2=A0 =C2=A0// Add a listener for pre-action dispatch:<br>
&gt; =C2=A0=C2=A0 =C2=A0$manager =3D $this-&gt;getResource(&#39;event_manag=
er&#39;);<br>
&gt; =C2=A0=C2=A0 =C2=A0$pubsub =C2=A0=3D $manager-&gt;getPubSub();<br>
&gt; =C2=A0=C2=A0 =C2=A0$pubsub-&gt;subscribe(&#39;mvc.dispatcher.pre&#39;,=
 &#39;my\plugins\ContextNegotiation&#39;);<br>
&gt;<br>
&gt; and:<br>
&gt;<br>
&gt; =C2=A0=C2=A0 =C2=A0// Indicate it&#39;s time to send the response:<br>
&gt; =C2=A0=C2=A0 =C2=A0$e-&gt;setState(&#39;response&#39;);<br>
&gt; =C2=A0=C2=A0 =C2=A0return;<br>
&gt;<br>
&gt; are concepts the end-user can easily grasp without needing to know a<b=
r>
&gt; whole lot about how it actually works internally.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Nov 11, 2009, at 19:38 , Matthew Weier O&#39;Phinney wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Hey, all --<br>
&gt;<br>
&gt; There have been a ton of questions about the ZF 2.0 roadmap, and my<br=
&gt; answer has been consistently, &quot;I&#39;m working on it; I&#39;ll ha=
ve something to<br>
&gt; publish soon.&quot;<br>
&gt;<br>
&gt; &quot;Soon&quot; is now:<br>
&gt;<br>
&gt; =C2=A0=C2=A0 <a href=3D"http://framework.zend.com/wiki/display/ZFDEV2/=
Zend+Framework+2.0+Roadmap" target=3D"_blank">http://framework.zend.com/wik=
i/display/ZFDEV2/Zend+Framework+2.0+Roadmap</a><br>
&gt;<br>
&gt; I&#39;d like you, as contributors, to look over it, and start discussi=
ng the<br>
&gt; various ramifications; we can do that either in comments to the pages =
or<br>
&gt; on this list.<br>
&gt;<br>
&gt; The roadmap is primarily a conceptual one right now, though a<br>
&gt; proof-of-concept has been created for the proposed MVC. I&#39;d like t=
o stay<br>
&gt; fairly high-level for now, and then start getting a flow of proposals<=
br>
&gt; into the system for specific migration-related tasks.<br>
&gt;<br>
&gt; Thanks everyone who has provided me input over the past many months, a=
nd<br>
&gt; let&#39;s get started on the next generation of ZF!<br>
&gt;<br>
&gt; --<br>
&gt; Matthew Weier O&#39;Phinney<br>
&gt; Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"mai=
lto:[email-masked]">[email-masked]</a><br>
&gt; Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://f=
ramework.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>

--0016e6d7eb46217e6a04789143d5--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 1 Apr 2010 09:07:44 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

I've been following this thread as well as discussions on IRC with
interest, as, honestly, I can completely buy into all arguments, which
are, to sum things up:

 * Use only __invoke()
 * Use a method name specific to the interface
 * Use a standardized method name, such as "run" or "execute"
 * Use a combination of __invoke() and either a meaningful or
   standardized method name.

I got to thinking about why I suggested "__invoke()" in the first place,
and went back to the plugin architecture page:

 * http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures

The original rationale was for using pubsub/filter chain systems. In
such systems, you attach callbacks:

    $chain->attach($callback);

If your objects implement __invoke(), $callback can simply be your
object -- you're done. Otherwise, you also have to provide the method:

    $chain->attach($object, $method);

Interestingly, in this document, I also recommended that for existing
interfaces, __invoke() be added as an _additional_ method, and that it
should proxy to the appropriate interface method. In this case, we'd
simply be taking advantage of a language feature in places it makes
sense.

Now, since the Symfony Live conference, I've also been thinking about
something Fabien said about Symfony 2: "less magic." To clarify, the
idea is to design components so that they are explicit about what they
can do. As an example, instead of using __get() and __set(), using
explicit getters and setters; instead of using __call(), explicitly
defining methods; instead of having __call() proxy to helpers, having a
broker from which you pull them as needed.

This has several implications:

 * Less need for explicit documentation. If you have behaviors relying
   on the magic methods, developers *must* read the the documentation in
   order to know how a class/component works. If everything is explicit,
   the class is self-documenting, and you can get the information you
   need from API docs, your IDE, etc.

 * Performance. Magic methods are reportedly less performant than using
   straight method calls (more on this later). 

These are important factors, and the test-driven developer in me
particularly likes less magic; it's much easier to test when you have
explicit behaviors.

That said, I decided to run some tests. These were the scenarios:

 * No Proxying:
   * Defined "filter" method returns value
   * Defined "__call" method returns value
   * Defined "__invoke" method returns value
 * Proxying:
   * Defined "filter" method returns value
   * Defined "__call" method proxies to "filter"
   * Defined "__invoke" method proxies to "filter"
 * Inverse proxying
   * Defined "filter" method calls invoke (as "$this();")
   * Defined "__invoke" method returns value
 * call_user_func_array()
   * Using array($obj, 'filter') callback
   * Using __invoke() with no proxying
   * Using __invoke() with proxying

The results were quite interesting. Across the board, using __call() is
awful -- even if you simply return a value, it's on average 6x slower
than a straight method call; proxying to another method, however,
doesn't take significantly longer (so long as you're not using
call_user_func_array() internally, that is).

__invoke(), however, turns out to be quite different. When not proxying,
it's actually *faster* than a method call (about 25% on average).
Proxing __invoke() to a method call or doing the inverse are roughly the
same speed -- about 2.5x slower than a straight method call (which, as
you'll note, is still over twice as fast as using __call()).

What was *really* interesting, however, was using
call_user_func_array(), which is commonly used in filter chains and/or
brokers.  __invoke(), with or without proxying, *always* was around 30%
*faster* than using an explicit array($obj, $method) callback. 

So, what does this tell me?

 * AVOID using __call(), particularly for often-used method calls. For
   helper systems, it will always be better to use a helper broker and
   command pattern.

 * For classes meant to be used primarily with filter chains or brokers,
   DO use __invoke(), even if it simply proxies to another interface
   method.

So, based on the design goals and the performance benchmarking, I'm
going to recommend that Filter and Validator (we renamed Validate to
Validator) define an __invoke() method in addition to a more explicit
interface method, and that helpers also follow this pattern.

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Wednesday, 31 March 2010, 10:21 AM -0400):
> Greetings, all --
> 
> Per the roadmap, one change we're planning on making is making plugin
> usage consistent across components: plugins will implement __invoke(),
> which makes them inherently callable.
> 
> In our refactoring branch, I've done this now with Zend_Filter. However,
> it required a ton of refactoring on the unit tests (had to either call
> __invoke() directly, or $filter($value)), and it got me to thinking:
> 
> Would it make sense to keep the original interfaces (filter, isValid,
> render, etc.), but also implement __invoke() -- having it proxy to the
> appropriate interface method?
> 
> As an example:
> 
>     interface Filter
>     {
>         public function filter($value);
>         public function __invoke($value);
>     }
> 
>     class Digits implements Filter
>     {
>         public function filter($value)
>         {
>             // ... logic...
>         }
> 
>         public function __invoke($value)
>         {
>             return $this->filter($value);
>         }
>     }
> 
> The benefits:
> 
>  * Fewer changes necessary to existing unit tests
>  * interface method names may be more descriptive of intent
> 
> Problems:
> 
>  * Using __invoke() introduces overhead -- 2 method calls instead of one
>  * Redundancy (two methods doing the same thing)
>  * A few extra tests to write (to ensure __invoke works as expecte)
> 
> After discussion with Ralph and Alex, I'm leaning towards having
> __invoke() as an _additional_ method, instead of replacing existing
> methods.
> 
> Any thoughts or comments?
> 
> -- 
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 10:44:54 -0600
From: Luke Crouch <[email-masked]>
To: Julien Pauli <[email-masked]>
Cc: Anthony Shireman <[email-masked]>,
	zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

Maybe I'm turning into a crotchety old programmer, but I'm not really
impressed with git. We switched from svn to git at my day job and I
haven't really seen any big benefits aside from a few sweet syntactic
shortcuts like git stash. For larger projects with well-organized
branching I just haven't seen much additional value from git.

-L

On Thu, Feb 25, 2010 at 10:27 AM, Julien Pauli <[email-masked]> wro=
te:
> Well, as far as there is a reference guide for GIT for those who never
> used it (me, for example), why not...
>
> J.Pauli
>
> On Thu, Feb 25, 2010 at 5:24 PM, Anthony Shireman <[email-masked]> w=
rote:
>> Moving from SVN to Git seems like quite a major switch. But, with the st=
ep
>> from 1.X to 2.0 it seems like a good time to do it. I like the idea (as
>> David Caunt mentioned) of releasing a 1.X branch with Doctrine 1 to test=
 the
>> waters and judging by the amount of work required decide to go with Doc2=
+ZF2
>> when the time comes. It's an exciting time to work with ZF and I'm looki=
ng
>> forward to a time when ZF2 uses Git and Doctrine 2.
>>
>>
>> On Thu, Feb 25, 2010 at 5:20 AM, Matthew Weier O'Phinney <[email-masked]=
om>
>> wrote:
>>>
>>> -- David Caunt <[email-masked]> wrote
>>> (on Thursday, 25 February 2010, 11:13 AM +0000):
>>> > Integration of Doctrine 1 with ZF 1.11 might be a good way to test th=
e
>>> > water and then community feedback may inform ZF2's integration with
>>> > Doctrine 2.
>>> >
>>> > As keen as I am for ZF2, I think the amount of work to be done on the
>>> > core is substantial and probably leaves enough time for a 1.11
>>> > release.
>>>
>>> Well, that's what we're trying to gauge at this point. It seems like a
>>> substantial amount of work, but if the initial development I outlined
>>> goes quickly, we may find ourselves working on the various
>>> rewrites/refactors much sooner, which could lead to an earlier release.
>>> Then again, it may take much longer, meaning a delay. I don't want to
>>> make a call either way yet, and thus the uncertainty about a 1.11
>>> release.
>>>
>>> If we end up deciding to do a 1.11 branch, we'll very likely look at
>>> doing integration with Doctrine 1.2 for the very reasons you describe,
>>> but also to serve as an upgrade path for ZF users.
>>>
>>> > Are there any plans to maintain the 1.x series once 2.0 is released?
>>>
>>> This is another area we're trying to gauge -- whether to continue
>>> maintenance on the 1.X branch following a 2.0 release.
>>>
>>> My personal feeling is that if we do, any future releases would address
>>> only critical bugs or security issues, and no new features. As long as
>>> we develop new features on the 1.X series, we'll hamper adoption of 2.0=
.
>>> In this vein, we'd likely do like the PHP project did, and do a new
>>> minor release on the version 1 branch simultaneous to 2.0 that would be
>>> for tracking those issues.
>>>
>>> If we do, I'll likely look for a small team from the community to assis=
t
>>> as release masters for that branch.
>>>
>>>
>>> > On 25 February 2010 10:46, Giorgio Sironi
>>> > <[email-masked]>
>>> > wrote:
>>> >
>>> > =A0 =A0 On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley
>>> > <[email-masked]>
>>> > =A0 =A0 wrote:
>>> >
>>> > =A0 =A0 =A0 =A0 In my opinion if Doctrine integration is to be left u=
ntil ZF
>>> > 2.0, then
>>> > =A0 =A0 =A0 =A0 the integrated version of Doctrine should be the 2.0 =
version.
>>> > Since
>>> > =A0 =A0 =A0 =A0 both 2.0 versions will require PHP 5.3.
>>> >
>>> >
>>> > =A0 =A0 I agree. Doctrine 2 will fill the lack of model infrastructur=
e in
>>> > Zend
>>> > =A0 =A0 Framework.
>>> > =A0 =A0 Anyway, the set of changes listed by Matthew is already a big=
 step
>>> > towards
>>> > =A0 =A0 simpler development (exploiting phpunit new features for exam=
ple.)
>>> >
>>> > =A0 =A0 Regards,
>>> > =A0 =A0 --
>>> > =A0 =A0 Giorgio Sironi
>>> > =A0 =A0 Piccolo Principe & Web Engineer
>>> > =A0 =A0 http://giorgiosironi.blogspot.com
>>> > =A0 =A0 http://twitter.com/giorgiosironi
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Save Water...Drink Ouzo !
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
>>> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>
>>
>

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 29 Jan 2010 12:01:59 -0600
From: Ralph Schindler <[email-masked]>
To: H2Lsoft <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] how can I unsuscribe ?

Instructions can be located here:

http://framework.zend.com/wiki/display/ZFDEV/Contributing+to+Zend+Framework#ContributingtoZendFramework-Howtounsubscribe

Cheers!

H2Lsoft wrote:
> Hi,
> 
> Please, how can I unsuscribe ?
> 
> thanks
> 

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 07:59:19 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

-- Benjamin Eberlei <[email-masked]> wrote
(on Tuesday, 16 March 2010, 11:25 AM +0100):
> I disagree with FQN for other packages. Its very verbose and the importing
> is pretty much why we want to port to namespaces in the first place.

Well said -- +1.

> My argument for importing all classes is easy: You have a central place
> where all dependencies of a class are listed. This is a very powerful
> concept to see classes that have too much dependencies or see what
> dependencies are required at all.

Exactly.

> Plus IDEs make it easy to see where a class was imported from.
> 
> greetings,
> Benjamin
> 
> On Tue, 16 Mar 2010 09:35:28 +0000, Rob Allen <[email-masked]> wrote:
> > On 16 Mar 2010, at 06:26, Ralph Schindler wrote:
> >> 
> >> 
> >> Should library/framework specific code be more expressive using fully
> >> qualified names in method signatures and consequently in docblocks? Or
> is
> >> using unqualified names just as easy to understand and/or more
> readable?
> > 
> > I think that within a component, aliasing to the component should be
> used
> > as you know where you are. If other components are used, then fully
> > qualified names should be used for clarity.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
From: "Sean P. O. MacCath-Moran" <[email-masked]>
Date: Sun, 22 Nov 2009 15:19:40 -0500
To: [email-masked]
Subject: [zf-contributors] Future of Zend_Db_Schema_Manager

--000e0cd5cad6edffa10478fb6ec0
Content-Type: text/plain; charset=ISO-8859-1

Greetings ZF Community,

Some time ago I'd began constructing a Zend DB Schema Manager with the
intention of building up something similar to the database management suite
available in RoR. I have a basic version of this running successfully in a
production environment, but it was made quickly and is a bit hackish.
However, I built on that idea in creating a proposal for an expanded set of
components, viewable at:

http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+Sean+P.+O.+MacCath-Moran?focusedCommentId=18219191#comment-18219191

As I speced this out, I realized I'd made the component a bit to big for a
first attempt, and began refactoring it, but then got distracted by other
more urgent projects (gots to pay the bills, after all). I'm now tending
back towards working on this again, but I'm uncertain if it is worth
proceeding with at this time. With that in mind, I welcome feedback on the
following:

1. IYHO, is this a component that the ZF community wants or needs?

2. My needs are to have a system whereby multiple developers may
successfully submit code that modifies databases in a controlled and
non-conflicting fashion (e.g. much like suite of DB management tools
provided by an RoR environment). I've looked for components in the works at
ZF which address this need, but do not see any such (e.g. Doctrine
integration seems promising on the surface, but doesn't seem to support
multiple developers making incremental database changes that may be applied
and backed out of). However, I've been hearing rumblings hither and thither
of DB management projects for ZF. Further, it sounds like we're all moving
on to the development of ZF 2.0. On that vain, can anyone weigh in on
whether it is useful for me to continue development of this component at
this time?

Thanks in advance!

Sean P. O. MacCath-Moran
www.emanaton.com

--000e0cd5cad6edffa10478fb6ec0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings ZF Community,<br><br>Some time ago I&#39;d began constructing a
Zend DB Schema Manager with the intention of building up something
similar to the database management suite available in RoR. I have a
basic version of this running successfully in a production environment,
but it was made quickly and is a bit hackish. However, I built on that
idea in creating a proposal for an expanded set of components, viewable
at:<br>
<br><a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema=
_Manager+-+Sean+P.+O.+MacCath-Moran?focusedCommentId=3D18219191#comment-182=
19191" target=3D"_blank">http://framework.zend.com/wiki/display/ZFPROP/Zend=
_Db_Schema_Manager+-+Sean+P.+O.+MacCath-Moran?focusedCommentId=3D18219191#c=
omment-18219191</a><br>

<br>As I speced this out, I realized I&#39;d made the component a bit to
big for a first attempt, and began refactoring it, but then got
distracted by other more urgent projects (gots to pay the bills, after
all). I&#39;m now tending back towards working on this again, but I&#39;m
uncertain if it is worth proceeding with at this time. With that in
mind, I welcome feedback on the following:<br>
<br>1. IYHO, is this a component that the ZF community wants or needs?<br><=
br>2.
My needs are to have a system whereby multiple developers may
successfully submit code that modifies databases in a controlled and
non-conflicting fashion (e.g. much like suite of DB management tools
provided by an RoR environment). I&#39;ve looked for components in the
works at ZF which address this need, but do not see any such (e.g.
Doctrine integration seems promising on the surface, but doesn&#39;t seem
to support multiple developers making incremental database changes that
may be applied and backed out of). However, I&#39;ve been hearing rumblings
hither and thither of DB management projects for ZF. Further, it sounds
like we&#39;re all moving on to the development of ZF 2.0. On that vain,
can anyone weigh in on whether it is useful for me to continue
development of this component at this time?<br>
<br>Thanks in advance!<br><font color=3D"#888888"><br>Sean P. O. MacCath-Mo=
ran<br><a href=3D"http://www.emanaton.com/" target=3D"_blank">www.emanaton.=
com</a></font>

--000e0cd5cad6edffa10478fb6ec0--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 15 Jul 2009 16:41:05 +0200
From: till <[email-masked]>
To: Ralph Schindler <[email-masked]>
Cc: Rob Allen <[email-masked]>, 
	"Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend_Db_Adapter_Sqlsrv ready for review

Just want to second, Ralph.

I do know a lot of people who will want to use this! :-)

On Tue, Jul 14, 2009 at 5:39 PM, Ralph
Schindler<[email-masked]> wrote:
> This is an awesome addition for the windows devlopment environment.
>
> Nice work!
> -ralph
>
> Rob Allen wrote:
>>
>> Hi all,
>>
>> Juozas and myself worked on an adapter for the MS SQL Server Driver for
>> PHP during the euro-win-php competition. As this is a useful component for
>> anyone working on Windows with SQL Server, we've created a proposal which is
>> now ready for review:
>>
>>
>> http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Adapter_Sqlsrv+-+Juozas+Kaziukenas+and+Rob+Allen
>>
>> There's also working source code at https://zfmssql.svn.codeplex.com/svn/
>>
>> We'd appreciate any and all comments on it :)
>>
>> Regards,
>>
>> Rob...
>>
>>
>

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 6 Feb 2010 03:38:24 +1100
From: Nigel Chapman <[email-masked]>
To: Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

On Sat, Feb 6, 2010 at 1:10 AM, Maarten Balliauw
<[email-masked]> wrote:

> Also check http://phplinq.codeplex.com for that matter. It's an abstraction
> over arrays and optionally also over Zend_Db_Table, Windows Azure Table
> Storage, ...
>
> Maarten
>
> On Fri, Feb 5, 2010 at 3:00 PM, Juan Felipe Alvarez Saldarriaga
> <[email-masked]> wrote:
>>
>> Hey, nice proposal, a little bit like LINQ right? my concern is about
>> performance too.

Hi Juan and Maarten,

Haven't seen Linq for ages; a different approach to a similar problem.
I think arrays work more elegantly with closures than selects. Let me
illustrate by taking the example from the Linq homepage and doing the
same thing in Ruby, then Zend_Array.

-- %< --

== LINQ ==

$names = array("John", "Peter", "Joe", "Patrick", "Donald", "Eric");
$result = from('$name')->in($names)
            ->where('$name => strlen($name) < 5')
            ->select('$name');

== RUBY ==

["John", "Peter", "Joe", "Patrick", "Donald", "Eric"].find_all{|s| s.length < 5}

== ZEND_ARRAY ==

$names = Zend_Array::takeWords('John Peter Joe Patrick Donald Eric');
$filtered = $names->filter(create_function('$s', 'return strlen($s) < 5;'));

Or in PHP 5.3 (I *think*)...

$filtered = $names->filter(function($s) { return strlen($s) < 5; });

-- %< --

I've considered complementing Zend_Array with Zend_Function, to
provide a convenient source of common anonymous functions.

$f = new Zend_Function();
$filtered = $names->filter($f->strlen(0,4));

Though I think allowing filter() to accept Zend_Validate objects would
be a neater (and Zendlier) solution. (Here Zend_Validate would work
with filter() and Zend_Filter with map().)

$max4chars = new Zend_Validate_StringLength(0,4);
$filtered = $names->filter($max4chars);

How do you find this wort of idiom for reading?

-- Nigel.

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 15:26:26 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] New Sections for Zend Framework 2.0 Roadmap

-- Kevin McArthur <[email-masked]> wrote
(on Tuesday, 17 November 2009, 11:44 AM -0800):
> Inline.
> 
>     PRG is something that can be built around forms, but has nothing to do
>     with the main purpose of the form component, which is to encapsulate
>     form element metadata and validation, and to facilitate rendering. PRG
>     is something you'd handle in your controller. We should not be tightly
>     binding forms and controllers; they should remain loosely coupled (if at
>     all coupled).
> 
> 
> The issue is that Zend_Form and PRG being so loosely coupled makes it a real
> pain to do PRG, and sadly results in most people who use Zend_Form not doing
> PRG (not good for anyone). The biggest issue comes from when validators add
> error messages, and fields need to remember their values. Currently this has to
> be manually saved to each field, and the controllers quickly become unwieldy.
> There's a prop for prg (and multi-page forms)... but I'm not sure how that
> integrates into 2.0 here....
> 
> PRG can be handled in the controller, but when you start doing that you really
> lose any value that ZFORM adds -- I pretty much just use Zend_Validate/
> Zend_Filter_Input on its own these days because ZFORM adds so little value in
> the the PRG context.
>
> I really think that a PRG scenario, and a simplification on how this works
> currently should be added to the 2.0 map -- even if you wont accept PRG as a
> default scenario [which I think it should be as get forms are usually treated
> as parameters, and most forms are therefore posted statefully]

Are we talking about the same thing? We're either not, or you're using
Zend_Form and Zend_Controller very differently from anyone I've ever
talked to. 

As an example of what I'm talking about:

    class FooController extends Zend_Controller_Action
    {
        public function barAction()
        {
            $form    = new SomeForm();
            $request = $this->getRequest();
            
            if ($request->isPost()) {
                // POST request; validate form
                if (!$form->isValid($request->getPost())) {
                    // Invalid; redisplay with errors
                    $this->view->form = $form;
                    return;
                }

                // Valid; update model, and REDIRECT
                $model = new SomeModel();
                $id = $model->create($form->getValues());
                return $this->_helper->redirector('item', 'foo', 'default', array(
                    'id' => $id,
                ));
            }

            // Display form
            $this->view->form = $form;
        }
    }

The above does most aspects of PRG, and all those steps would be
necessary regardless of how Zend_Form works; you're marshalling input,
and deciding how to respond. 

If you're wanting redirection on failure, I'm not entirely sure I see
the point; you'd get the same exact result as before. Most literature on
PRG actually indicates that the Redirect/Get are only really necessary
for _successful_ actions, not those resulting in validation errors.

The work done for multi-page form support would make PRG for error cases
trivially possible, however, and maintains the loose coupling between
Zend_Form and the other MVC components by pushing this interaction into
an action helper. This is the preferred approach, as keeping the
components isolated makes them easier to test and repurpose.  (As for
the multi-page form support, unfortunately, the contributor has had no
time to complete that component. If somebody is willing to step up and
work on it, I'm sure the help would be welcome.)

Forms do have use-cases outside of HTTP -- I personally want to work up
a version that utilizes ncurses and/or readline so as to create
CLI-based forms -- where PRG would have absolutely no meaning
whatsoever.

> Using PRG _should_ be as easy as not using it, and the Zend_Session/
> FlashMessenger/SaveState stuff should all be handled in the core classes as its
> really laborious to do it in the controllers, and for the most part, totally
> redundant and unnecessary.

Regarding your comments on sessions... those *are* core classes, can be
used with or without the MVC, and are as simple as instantiating and
using objects. I'm really needing some examples here if I'm going to
understand what you're getting at.

>         This is obviously a quick overview, but the idea is to more tightly
>         tie Zend_Form in with the request cycle, assume PRG is the priority
>         method for forms, and treat decoration in the view, not the model or
>         controller.
> 
> 
>     As noted, I don't think PRG has anything to do with the forms, but
>     everything to do with controllers, and should be treated there. It's
>     already trivially easy to accomplish.
> 
> 
> Trivial is relative I suppose. The tying in of Zend_Form with
> Zend_Session to remember state, validation errors and flash messenger
> with the controller layer to glue it together, its not trivial enough. 
>
> Most of the forms examples don't do PRG, and last I checked its not
> even the quickstart recommended method. (
> http://framework.zend.com/docs/quickstart/create-a-form doesn't
> redirect on failure for example) ... the docs follow in the same vain.

See my above notes. If you apply the RG portion of PRG to simply the
success responses, then it's already easily and readily supported. If
you want to apply it to *all* form responses, then we need some more
infrastructure -- but that is not difficult to achieve. We simply need a
proposal (BTW, there is no PRG proposal, just the multi-page form
proposal).

> What I'm recommending is for 2.0 is that PRG become 'the' way to do post forms
> in ZFW 2.0. Or at least, a heck of a lot less terse in terms of the coding
> required. Lets integrate Session/FlashMessenger/Routing/Controllers into a
> comprehensive 'forms' solution -- it'll result in better outcomes for deployed
> applications. There's already some unimplemented support in the 1.0 model in
> terms of state saving... so its been on the radar...

Let's discuss this from a use cases perspective -- if you can provide
some examples of how you envision it working, we can start creating a
proposal, or work from the existing multi-page form proposal.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Fri, 26 Feb 2010 22:44:44 +0100
To: [email-masked]
Subject: [zf-contributors] The Zend_Rbac proposal is ready for review

Hi,

I'm happy to announce my proposal for a Zend_Rbac component. Please
check it out, and make sure to comment :D
http://framework.zend.com/wiki/display/ZFPROP/Zend_Rbac+or+Zend~Access~Rbac+-+Dolf+Schimmel

Regards,

Dolf Schimmel
-- Freeaqingme

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Tue, 24 Mar 2009 13:37:14 -0700
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>,
	<[email-masked]>
Subject: RE: [zf-contributors] Proper place to report incubator
	issues/requests?

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9ACC0.519E6B62
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hey AJ, I've been meaning to answer this one for days, so I'm the cause
of the unresponsiveness here. ;) With a recent release of JIRA, it
became easy to migrate issues between projects. I propose we create a
separate project for incubator that uses the same issue scheme as the ZF
project with components that are currently in incubator. We would then
make migrating these issues part of promoting the component to trunk.

If there are no issues or better suggestions, I'll implement this
proposal tomorrow.

=20

,Wil

=20

=20

From: [email-masked] [mailto:[email-masked]] On Behalf Of A.J.
Brown
Sent: Wednesday, March 18, 2009 11:05 PM
To: [email-masked]
Subject: [zf-contributors] Proper place to report incubator
issues/requests?

=20

Hey guys,

I have some requests I want to file for a component currently in the
standard incubator (specifically Zend_Queue).  Where's the place to do
so?

--=20
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

------_=_NextPart_001_01C9ACC0.519E6B62
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hey AJ, I&#8217;ve been meaning to answer this one for =
days, so I&#8217;m
the cause of the unresponsiveness here. ;) With a recent release of =
JIRA, it
became easy to migrate issues between projects. I propose we create a =
separate project
for incubator that uses the same issue scheme as the ZF project with =
components
that are currently in incubator. We would then make migrating these =
issues part
of promoting the component to trunk.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If there are no issues or better suggestions, I&#8217;ll =
implement
this proposal tomorrow.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>,Wil<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>A.J. Brown<br>
<b>Sent:</b> Wednesday, March 18, 2009 11:05 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [zf-contributors] Proper place to report incubator
issues/requests?<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Hey guys,<br>
<br>
I have some requests I want to file for a component currently in the =
standard
incubator (specifically Zend_Queue).&nbsp; Where's the place to do =
so?<br
clear=3Dall>
<br>
-- <br>
A.J. Brown<br>
web | <a href=3D"http://ajbrown.org">http://ajbrown.org</a><br>
phone | (937) 660-3969<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9ACC0.519E6B62--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 10:09:07 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

-- drm <[email-masked]> wrote
(on Tuesday, 17 November 2009, 03:26 PM +0100):
> > Your solution for Zend Framework being too complicated for new users
> > is to split it up into 7 different, overlapping downloads?  And you
> > don't think that would make it much more confusing?
> If it's documented right, it will give a better insight of how ZF is
> organised and thus how it relates to the user's application of the
> framework. I am speaking from my own experience, which is, of course
> subjective. Wouldn't you agree that it would be more insightful to have
> only maybe a dozen of packages in a starter sandbox than nearly 60?

Um... not to be an ass here, but you state "I am speaking from my own
experience, which is, of course, subjective," and then make an
assumption that we agree. ;)

I've heard both sides of this argument: those who would prefer to be
able to retrieve only those components they use, and those who feel the
framework only makes sense when distributed in its entierty. I think
both arguments have merit, and ideally I'd like to offer both
strategies -- which can be accomplished via a PEAR channel.

The problem is building infrastructure for packaging individual
components -- something that gets more difficult with each new component
added to the framework.

> > I think more documentation is the answer; more diagrams, for starters.
> 
> Please note that I did suggest to start with documentation of packages,
> not with the separation of packages as downloads. That could be a
> "nice-to-have" next step though.

It's an interesting idea. The problem with having groupings in the
documentation is that some packages may overlap, and also that there may
be some confusion as to what section to look in: "is Zend_Form in the
Core, Security, or MVC section?" An alphabetical list is simple to
traverse and comprehend.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 10:32:02 -0800
From: Kevin McArthur <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

This is a multi-part message in MIME format.
--------------050300010204090202000008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I guess I'll chime in, and stir the pot a bit. All IMHO of course....

The good:

Namespaces, Creation of components for general-purpose cross-functional 
actions, Usage of new language features within plugin architectures, 
Autoload-only.

The Bad:

1 ) Unified constructor. *All* constructors will (optionally) accept an 
array of options or Zend_Config object as the first argument.

I take exception to this because, well, it's just going to kill 
performance -- and it doesn't follow industry standard techniques for 
this type of thing. This shouldn't be a rule as a ton of classes have no 
reason to be configurable, or make a lot more sense to take real 
parameters, rather than instantiating a new object. Instead, I recommend 
a *Configurable interface* which _may_ mark classes as configurable as 
needed.

2 ) Exception interfacing

Why mess with it? All the SPL exceptions descend from Exception and can 
be caught/thrown as any normal exception can be. Exceptions should 
continue to contain the Exception class inheritance hierarchy.

 From the markup:

try { 
    throw new InvalidArgumentException(); 
} catch (\Foo\Bar\Exception $e) { 
} 

Can just be:

try { 
    throw new InvalidArgumentException(); 
} catch (Exception $e) { 
} 

Without the marker interface. I must be missing something?

3) Design By Contract

I'm actually a big fan of contract programming, but, a framework must be 
fast -- and optimized. Contract programming is great as part of business 
process management, but it has serious runtime performance implications 
-- and worse, increases contribution overhead. Makes testing, acceptance 
testing easier, sure. But this could be realllllly limiting.

4) Getting rid of singletons.

Why does it make more sense to access the front controller via a 
registry? Surely this can't meet the 80/20 rule? Keep the singletons, 
they make it easier to pick up the framework.

The Ugly:

The proposed changes to the core api (and to a large extent the 
framework additions since 1.0) really add complexity to the framework to 
the benefit of testing and other 'advanced' use. These changes do 
little, if anything to advance three goals I see as core requirements 
for 2.0:

a) Can a skilled PHP developer read and understand Zend Framework 
application code without more than an hour's primer on ZFW? Could they 
trace execution of the framework logically without a debugger? Jumps 
like GOTO's, fancy routers, registries, helpers, plugins, and DI models 
all work against this goal. Keep it simple.

b) Can a skilled PHP developer contribute a change to the framework 
easily without being involved in the ZFW core politics, contribution 
processes, proposal processes, test writing, doc writing, etc. 
Currently, ZFW sucks for this, but didn't until after the 1.0 line was 
out. What will ZFW 2.0 do to reduce the contribution overhead and 
encourage community participation?

c) Can a ZFW developer create products and services that leverage ZFW in 
an ecosystem of components? Is there a financial incentive for this? 
Currently, there's very little going on in terms of commercialized 
redistributable components -- How will ZFW 2.0 create, and integrate 
itself into a marketplace for ZFW apps, components, and tools? Official 
ZFW app/component store? ZFW cloud services?

The Atrocious:

Still nothing about an upgrading / security patches system. Still no 
components for detecting if an application is vulnerable, notifying 
system admins, or shutting down an installed base of vulnerable apps 
dependent on the framework. If the problems of the other major framework 
and cms vendors continue to be ignored, there will almost certainly be 
some sort of incident that will tarnish the frameworks reputation for 
security. At some point the framework is going to have to take version 
management more seriously than publishing patches to the website (a good 
first step, but miles away from where it needs to be).

--

I'd also add that there's probably an opportunity to look at 
phar-ization within the 2.0 line. Will the new loader support phar'd 
components, and how will that look? Zend_Tool? Configurable site images?

I'm sure theres more, but thats my $0.02 for now

Kevin McArthur

Matthew Weier O'Phinney wrote:
> Hey, all --
>
> There have been a ton of questions about the ZF 2.0 roadmap, and my
> answer has been consistently, "I'm working on it; I'll have something to
> publish soon."
>
> "Soon" is now:
>
>     http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>
> I'd like you, as contributors, to look over it, and start discussing the
> various ramifications; we can do that either in comments to the pages or
> on this list.
>
> The roadmap is primarily a conceptual one right now, though a
> proof-of-concept has been created for the proposed MVC. I'd like to stay
> fairly high-level for now, and then start getting a flow of proposals
> into the system for specific migration-related tasks.
>
> Thanks everyone who has provided me input over the past many months, and
> let's get started on the next generation of ZF!
>
>   

--------------050300010204090202000008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I guess I'll chime in, and stir the pot a bit. All IMHO of course....<br>
<br>
The good:<br>
<br>
Namespaces, Creation of components for general-purpose cross-functional
actions, Usage of new language features within plugin architectures,
Autoload-only.<br>
<br>
The Bad:<br>
<br>
1 ) Unified constructor. <b>All</b> constructors will (optionally)
accept an array of options or Zend_Config object as the first argument.<br>
<br>
I take exception to this because, well, it's just going to kill
performance -- and it doesn't follow industry standard techniques for
this type of thing. This shouldn't be a rule as a ton of classes have
no reason to be configurable, or make a lot more sense to take real
parameters, rather than instantiating a new object. Instead, I
recommend a <b>Configurable interface</b> which _may_ mark classes as
configurable as needed. <br>
<br>
2 ) Exception interfacing<br>
<br>
Why mess with it? All the SPL exceptions descend from Exception and can
be caught/thrown as any normal exception can be. Exceptions should
continue to contain the Exception class inheritance hierarchy. <br>
<br>
>From the markup: <br>
<br>
<table class="dp-c" border="0" cellpadding="0" cellspacing="0"
 height="89" width="352">
  <tbody>
    <tr>
      <td class="line2">try&nbsp;{&nbsp;</td>
    </tr>
    <tr>
      <td class="line1">&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;<span class="keyword">new</span><span>&nbsp;InvalidArgumentException();&nbsp;</span></td>
    </tr>
    <tr>
      <td class="line2">}&nbsp;catch&nbsp;(\Foo\Bar\Exception&nbsp;<span class="vars">$e</span><span>)&nbsp;{&nbsp;</span></td>
    </tr>
    <tr>
      <td class="line1">}&nbsp;</td>
    </tr>
  </tbody>
</table>
<br>
Can just be:<br>
<br>
<table class="dp-c" border="0" cellpadding="0" cellspacing="0">
  <tbody>
    <tr>
      <td class="line2">try&nbsp;{&nbsp;</td>
    </tr>
    <tr>
      <td class="line1">&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;<span class="keyword">new</span><span>&nbsp;InvalidArgumentException();&nbsp;</span></td>
    </tr>
    <tr>
      <td class="line2">}&nbsp;catch&nbsp;(Exception&nbsp;<span class="vars">$e</span><span>)&nbsp;{&nbsp;</span></td>
    </tr>
    <tr>
      <td class="line1">}&nbsp;</td>
    </tr>
  </tbody>
</table>
<br>
Without the marker interface. I must be missing something?<br>
<br>
3) Design By Contract<br>
<br>
I'm actually a big fan of contract programming, but, a framework must
be fast -- and optimized. Contract programming is great as part of
business process management, but it has serious runtime performance
implications -- and worse, increases contribution overhead. Makes
testing, acceptance testing easier, sure. But this could be realllllly
limiting.<br>
<br>
4) Getting rid of singletons.<br>
<br>
Why does it make more sense to access the front controller via a
registry? Surely this can't meet the 80/20 rule? Keep the singletons,
they make it easier to pick up the framework.<br>
<br>
The Ugly:<br>
<br>
The proposed changes to the core api (and to a large extent the
framework additions since 1.0) really add complexity to the framework
to the benefit of testing and other 'advanced' use. These changes do
little, if anything to advance three goals I see as core requirements
for 2.0:<br>
<br>
a) Can a skilled PHP developer read and understand Zend Framework
application code without more than an hour's primer on ZFW? Could they
trace execution of the framework logically without a debugger? Jumps
like GOTO's, fancy routers, registries, helpers, plugins, and DI models
all work against this goal. Keep it simple.<br>
<br>
b) Can a skilled PHP developer contribute a change to the framework
easily without being involved in the ZFW core politics, contribution
processes, proposal processes, test writing, doc writing, etc.
Currently, ZFW sucks for this, but didn't until after the 1.0 line was
out. What will ZFW 2.0 do to reduce the contribution overhead and
encourage community participation?<br>
<br>
c) Can a ZFW developer create products and services that leverage ZFW
in an ecosystem of components? Is there a financial incentive for this?
Currently, there's very little going on in terms of commercialized
redistributable components -- How will ZFW 2.0 create, and integrate
itself into a marketplace for ZFW apps, components, and tools? Official
ZFW app/component store? ZFW cloud services?<br>
<br>
The Atrocious:<br>
<br>
Still nothing about an upgrading / security patches system. Still no
components for detecting if an application is vulnerable, notifying
system admins, or shutting down an installed base of vulnerable apps
dependent on the framework. If the problems of the other major
framework and cms vendors continue to be ignored, there will almost
certainly be some sort of incident that will tarnish the frameworks
reputation for security. At some point the framework is going to have
to take version management more seriously than publishing patches to
the website (a good first step, but miles away from where it needs to
be).<br>
<br>
--<br>
<br>
I'd also add that there's probably an opportunity to look at
phar-ization within the 2.0 line. Will the new loader support phar'd
components, and how will that look? Zend_Tool? Configurable site images?<br>
<br>
I'm sure theres more, but thats my $0.02 for now<br>
<br>
Kevin McArthur<br>
<br>
<br>
Matthew Weier O'Phinney wrote:
<blockquote cite="mid:20091111183857.GB511@localhost" type="cite">
  <pre wrap="">Hey, all --

There have been a ton of questions about the ZF 2.0 roadmap, and my
answer has been consistently, "I'm working on it; I'll have something to
publish soon."

"Soon" is now:

    <a class="moz-txt-link-freetext" href="http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap">http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap</a>

I'd like you, as contributors, to look over it, and start discussing the
various ramifications; we can do that either in comments to the pages or
on this list.

The roadmap is primarily a conceptual one right now, though a
proof-of-concept has been created for the proposed MVC. I'd like to stay
fairly high-level for now, and then start getting a flow of proposals
into the system for specific migration-related tasks.

Thanks everyone who has provided me input over the past many months, and
let's get started on the next generation of ZF!

  </pre>
</blockquote>
<br>
</body>
</html>

--------------050300010204090202000008--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
Date: Fri, 15 Jan 2010 11:15:35 +0100
From: Julien Pauli <[email-masked]>
To: Dolf Schimmel <[email-masked]>
Cc: Marc Bennewitz <[email-masked]>, 
	zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] 1.10 has been branched!

--0016e65c8bf2d97634047d3148ee
Content-Type: text/plain; charset=ISO-8859-1

On it xD

J.Pauli

On Fri, Jan 15, 2010 at 1:20 AM, Dolf Schimmel <[email-masked]>wrote:

> Gratz all!
>
> Jira tells us there's (only?) a 149 issues to fix (
>
> http://framework.zend.com/issues/browse/ZF#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
> (494 + 40 - 385 = 149)), how about closing all of them? :D
>
> -- Freeaqingme
>
> On Fri, Jan 15, 2010 at 12:32 AM, Marc Bennewitz
> <[email-masked]> wrote:
> > oh sorry - forget this - i see it is already done
> > my mistake
> >
> > Am 15.01.2010 00:27, schrieb Marc Bennewitz:
> >> Great :)
> >>
> >> Can you add the new components of 1.10 on issue tracker and move the
> >> incubator components to Zend Framework project please.
> >>
> >> Greetings
> >> Marc B.
> >>
> >> Am 14.01.2010 22:55, schrieb Matthew Weier O'Phinney:
> >>
> >>> Greetings, all!
> >>>
> >>> I've just created the official 1.10 branch, and will be tagging the
> beta
> >>> off of this branch momentarily.
> >>>
> >>> >From this point forward, no API changes are allowed in the
> release-1.10
> >>> branch -- but DO please assist in fixing bugs, translating, etc.!
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>
> >
>

--0016e65c8bf2d97634047d3148ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On it xD<br><br>J.Pauli<br><br><div class=3D"gmail_quote">On Fri, Jan 15, 2=
010 at 1:20 AM, Dolf Schimmel <span dir=3D"ltr">&lt;<a href=3D"mailto:dolfs=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204=
); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Gratz all!<br>
<br>
Jira tells us there&#39;s (only?) a 149 issues to fix (<br>
<a href=3D"http://framework.zend.com/issues/browse/ZF#selectedTab=3Dcom.atl=
assian.jira.plugin.system.project%3Aroadmap-panel" target=3D"_blank">http:/=
/framework.zend.com/issues/browse/ZF#selectedTab=3Dcom.atlassian.jira.plugi=
n.system.project%3Aroadmap-panel</a><br>

(494 + 40 - 385 =3D 149)), how about closing all of them? :D<br>
<br>
-- Freeaqingme<br>
<div><div></div><div class=3D"h5"><br>
On Fri, Jan 15, 2010 at 12:32 AM, Marc Bennewitz<br>
&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&=
gt; wrote:<br>
&gt; oh sorry - forget this - i see it is already done<br>
&gt; my mistake<br>
&gt;<br>
&gt; Am 15.01.2010 00:27, schrieb Marc Bennewitz:<br>
&gt;&gt; Great :)<br>
&gt;&gt;<br>
&gt;&gt; Can you add the new components of 1.10 on issue tracker and move t=
he<br>
&gt;&gt; incubator components to Zend Framework project please.<br>
&gt;&gt;<br>
&gt;&gt; Greetings<br>
&gt;&gt; Marc B.<br>
&gt;&gt;<br>
&gt;&gt; Am 14.01.2010 22:55, schrieb Matthew Weier O&#39;Phinney:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Greetings, all!<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I&#39;ve just created the official 1.10 branch, and will be ta=
gging the beta<br>
&gt;&gt;&gt; off of this branch momentarily.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt;From this point forward, no API changes are allowed in the=
 release-1.10<br>
&gt;&gt;&gt; branch -- but DO please assist in fixing bugs, translating, et=
c.!<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thanks!<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br>

--0016e65c8bf2d97634047d3148ee--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: "Wil Sinclair" <[email-masked]>,
	"till" <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 20 Mar 2009 22:37:33 +0100
Subject: Re: [zf-contributors] Release Policies and Conventions

Wil, when that's the case then you should rewrite it because "ONLY BUG 
FIXES" means for me that also new features are not allowed within mini 
releases ;-)

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Wil Sinclair" <[email-masked]>
To: "till" <[email-masked]>
Cc: "Thomas Weidner" <[email-masked]>; 
<[email-masked]>
Sent: Friday, March 20, 2009 10:10 PM
Subject: RE: [zf-contributors] Release Policies and Conventions

You can add new API's and new features that don't affect API's much in
mini releases. They have to be BC, however. I'm pretty sure that's
called out in the document, but let me know if it's not.

Thanks.
,Wil

-----Original Message-----
From: till [mailto:[email-masked]]
Sent: Friday, March 20, 2009 2:07 PM
To: Wil Sinclair
Cc: Thomas Weidner; [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

What if I added a "feature" to an existing component.

I mean, from what I understand -- the mini releases shouldn't break BC
-- that's all. But if I add to the api that's allowed? (asking)

On Fri, Mar 20, 2009 at 10:02 PM, Wil Sinclair <[email-masked]> wrote:
> OK, I changed it. There will inevitably be some hand-waving around
what
> is a new feature and what is a functionality enhancement. I'd rather
> confine this thread to the issue of release policies and conventions.
:)
>
> New components pretty clearly fall under the category of 'new
features'
> in my mind. If others are confused, we should further clarify it.
>
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 1:42 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> "A mini release may contain only bug fixes. Note that no new features
or
> API
> changes are allowed whatsoever."
>
> This sentence could imply that new features are not allowed, but
> improvments
> of existing features are allowed as long as they don't change existing
> API.
> The word "only" could be overseen.
>
> The question is also what's for us the difference between a feature
> enhancement and a new feature.
> Feature Enhancement could be for example to add a new option. It would
> not
> change API. So a textual clearification would be great :-)
>
> Also to note: Are new components allowed within minor releases or only
> within major releases? Should also be defined.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>;
> <[email-masked]>
> Sent: Friday, March 20, 2009 9:31 PM
> Subject: RE: [zf-contributors] Release Policies and Conventions
>
>
> Hey Thomas, I'm not quite sure what you are referring to. Your
> understanding is correct, and the wiki page seems to reflect it
> perfectly. Can you tell me exactly what needs to be updated? Maybe
with
> the string that you're referring to?
>
> Thanks.
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 12:57 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> In my understanding also "feature enhancements" are actually not
allowed
> to
> be integrated within mini-releases.
> Only "Bug fixes" which do not add additional API are allowed.
>
> Maybe you should also add a definition for what's a bug fix, a
> improvement
> and a new feature to get that also defined, and we can all speak of
the
> same
> in future.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, March 20, 2009 8:47 PM
> Subject: [zf-contributors] Release Policies and Conventions
>
>
> Over the 2 years that I've been involved with the project, there have
> been many questions about what can go in to a given release and if
there
> are any guidelines for the release schedules. While many of you have
> pieced the picture together from different mails, IRC chats, etc. I've
> owed you a document for a long time now. Here it is:
>
>
>
>
http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
> tions
>
>
>
> I ask all contributors to review this and reply with any question or
> edits- especially if I missed something- in this forum.
>
>
>
> As always, thanks for all the time and effort. Also, go 1.8!
>
>
>
> ,Wil
>
> 

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Sat, 14 Nov 2009 20:09:03 +0100
Subject: Re: [zf-contributors] I18N Webinar

There is a reason why we always say that you should use UTF-8 when workin=
g=20
with I18n.
Especially the locale informations can not be non-UTF-8-ized. But that's=20
another thing.

The other point is: When we want to cover HOW a multilingual site is crea=
ted=20
then there is no time to talk about translations.

That said, from the view of arguments, ALL points are somehow related to=20
I18n.
Translation, Dates, Currency, Localization, MLS.

But I can't talk about all of them at once. ;-)
My first talk will be about the basics of what a locale is, and 95% about=
=20
translation.

I think we should go from simple to complicated. :-)

Btw: I don't see that IP region location should have anything to do with=20
I18n. A region is a region regardless of the source where you get the=20
information about it. You could also detect the locale based on a timezon=
e,=20
but that's also not I18n.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Matthew Weier O'Phinney" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 14, 2009 7:32 PM
Subject: Re: [zf-contributors] I18N Webinar

-- Thomas Weidner <[email-masked]> wrote
(on Saturday, 14 November 2009, 05:59 PM +0100):
> Non of your points target translation.

Actually, I'd argue that points 1 and 3 *do* target translation. UTF-8
conversion is something that hampers some translation tasks, and setting
up a multi-lingual site in terms of language detection, routing, and IP
all affect the translations.

That said, it *is* your webinar, and I'll trust your judgment on how
much material you can cover! :)

Looking forward to catching this one!

> They will be talked about when we given an Localization talk=20
> (Zend_Locale).
>
> For this webinar it would take too much time to focus also on this poin=
ts.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "P=E1draic Brady"
> <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>
> Cc: "Zend Framework Contributors" <[email-masked]>
> Sent: Saturday, November 14, 2009 5:24 PM
> Subject: Re: [zf-contributors] I18N Webinar
>
>
> Just a few suggestions based on common problems:
>
> 1. UTF8 conversion (still lots of people without a clue - judging by
> how my name is still not presented accurately on many sites).
> 2. Integer and Float normalisation across locales - particularly
> when commas/periods are both accepted through forms.
> 3. Basics of designing a multi-lingual site (language detection,
> routing solutions, IP region location).
>
> Paddy
>
>
> P=E1draic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>
>
>
>
>
> ________________________________
> From: Thomas Weidner <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Sent: Sat, November 14, 2009 12:53:46 PM
> Subject: [zf-contributors] I18N Webinar
>
> Hy ZF interested community,
>
> I am preparing an webinar about I18N.
> This one will be a speak about Translation and all what's related to
> this task.
>
> So here comes your part:
> Which things do you want to know ?
> Which informations do you miss from manual or other sources ?
> What do you want to hear in this webinar ?
>
> Don't be shy and just reply :-)
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/=20

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Oct 2009 14:40:43 -0700
From: Trevor Johns <[email-masked]>
To: Graham Anderson <[email-masked]>
Cc: [email-masked]
Subject: [zf-contributors] Re: ZF Git repo,
	(was Re: [zf-contributors] Code Review)

On Mon, Oct 12, 2009 at 2:29 PM, Graham Anderson
<[email-masked]> wrote:
> Trevor, on the subject of Git, first off thanks for making the effort to =
track
> the SVN repo on github. Second, would you please add the standard incubat=
or as
> a remote tracking =C2=A0branch?

Ah, yes, I completely forgot about that.

I'll try to get that done sometime after work this week. If you don't
hear back from me by Friday, feel free to ping me and remind me.

--=20
Trevor Johns

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
From: "Sean P. O. MacCath-Moran" <[email-masked]>
Date: Sun, 22 Nov 2009 15:17:46 -0500
To: [email-masked]
Subject: [zf-contributors] Future of Zend_Db_Schema_Manager

--000e0cd59c962472be0478fb68db
Content-Type: text/plain; charset=ISO-8859-1

Greetings ZF Community,

Some time ago I'd began constructing a Zend DB Schema Manager with the
intention of building up something similar to the database management suite
available in RoR. I have a basic version of this running successfully in a
production environment, but it was made quickly and is a bit hackish.
However, I built on that idea in creating a proposal for an expanded set of
components, viewable at:

http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager+-+Sean+P.+O.+MacCath-Moran?focusedCommentId=18219191#comment-18219191

As I speced this out, I realized I'd made the component a bit to big for a
first attempt, and began refactoring it, but then got distracted by other
more urgent projects (gots to pay the bills, after all). I'm now tending
back towards working on this again, but I'm uncertain if it is worth
proceeding with at this time. With that in mind, I welcome feedback on the
following:

1. IYHO, is this a component that the ZF community wants or needs?

2. My needs are to have a system whereby multiple developers may
successfully submit code that modifies databases in a controlled and
non-conflicting fashion (e.g. much like suite of DB management tools
provided by an RoR environment). I've looked for components in the works at
ZF which address this need, but do not see any such (e.g. Doctrine
integration seems promising on the surface, but doesn't seem to support
multiple developers making incremental database changes that may be applied
and backed out of). However, I've been hearing rumblings hither and thither
of DB management projects for ZF. Further, it sounds like we're all moving
on to the development of ZF 2.0. On that vain, can anyone weigh in on
whether it is useful for me to continue development of this component at
this time?

Thanks in advance!

Sean P. O. MacCath-Moran
www.emanaton.com

--000e0cd59c962472be0478fb68db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings ZF Community,<br><br>Some time ago I&#39;d began constructing a Z=
end DB Schema Manager with the intention of building up something similar t=
o the database management suite available in RoR. I have a basic version of=
 this running successfully in a production environment, but it was made qui=
ckly and is a bit hackish. However, I built on that idea in creating a prop=
osal for an expanded set of components, viewable at:<br>

<br><a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema=
_Manager+-+Sean+P.+O.+MacCath-Moran?focusedCommentId=3D18219191#comment-182=
19191">http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema_Manager=
+-+Sean+P.+O.+MacCath-Moran?focusedCommentId=3D18219191#comment-18219191</a=
><br>

<br>As I speced this out, I realized I&#39;d made the component a bit to bi=
g for a first attempt, and began refactoring it, but then got distracted by=
 other more urgent projects (gots to pay the bills, after all). I&#39;m now=
 tending back towards working on this again, but I&#39;m uncertain if it is=
 worth proceeding with at this time. With that in mind, I welcome feedback =
on the following:<br>

<br>1. IYHO, is this a component that the ZF community wants or needs?<br><=
br>2. My needs are to have a system whereby multiple developers may success=
fully submit code that modifies databases in a controlled and non-conflicti=
ng fashion (e.g. much like suite of DB management tools provided by an RoR =
environment). I&#39;ve looked for components in the works at ZF which addre=
ss this need, but do not see any such (e.g. Doctrine integration seems prom=
ising on the surface, but doesn&#39;t seem to support multiple developers m=
aking incremental database changes that may be applied and backed out of). =
However, I&#39;ve been hearing rumblings hither and thither of DB managemen=
t projects for ZF. Further, it sounds like we&#39;re all moving on to the d=
evelopment of ZF 2.0. On that vain, can anyone weigh in on whether it is us=
eful for me to continue development of this component at this time?<br>

<br>Thanks in advance!<br><br>Sean P. O. MacCath-Moran<br><a href=3D"http:/=
/www.emanaton.com">www.emanaton.com</a><br>

--000e0cd59c962472be0478fb68db--

nFrom nobody Wed Apr  7 08:46:15 2010
Date: Sat, 27 Feb 2010 14:10:48 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked], Matthew Weier O'Phinney <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc

Ben Scholzen 'DASPRiD' wrote on 27.02.2010 13:45:
> Matthew Weier O'Phinney wrote on 25.02.2010 00:05:
>>  * Updating the test suite:
>>    * Removing the AllTests suites (these are not necessary with newer
>>      versions of PHPUnit, and we have already established @group
>>      annotations throughout the framework)
>>    * Usage of TestHelper.php as a PHPUnit bootstrap; this will allow
>>      stripping out the require_once calls in each test class file.
> 
> We should also replace those blown try/catch blocks which currently test
> for expected exceptions with the new functionallity in PHPUnit. There is
> either the function $this->setExpectedException('ExceptionName'); and
> the docblock annotation @expectedException ExceptionName, of which I
> personally prefer the method-call one. The only thing which is currently
> not possible through this is to specify a string which is contained
> within the exception message, but I already raised an issue ticket for that:
> 
> http://www.phpunit.de/ticket/1012

Seems that I was wrong, it was just not written in the documentation, we
can do:

$this->setExpectedException($exceptionName, $exceptionMessage = '',
$exceptionCode = 0);

or via annotation:

@expectedException exceptionName exceptionMessage exceptionCode

nFrom nobody Wed Apr  7 08:46:15 2010
Date: Sat, 27 Feb 2010 13:45:09 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked], Matthew Weier O'Phinney <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc

Matthew Weier O'Phinney wrote on 25.02.2010 00:05:
>  * Updating the test suite:
>    * Removing the AllTests suites (these are not necessary with newer
>      versions of PHPUnit, and we have already established @group
>      annotations throughout the framework)
>    * Usage of TestHelper.php as a PHPUnit bootstrap; this will allow
>      stripping out the require_once calls in each test class file.

We should also replace those blown try/catch blocks which currently test
for expected exceptions with the new functionallity in PHPUnit. There is
either the function $this->setExpectedException('ExceptionName'); and
the docblock annotation @expectedException ExceptionName, of which I
personally prefer the method-call one. The only thing which is currently
not possible through this is to specify a string which is contained
within the exception message, but I already raised an issue ticket for that:

http://www.phpunit.de/ticket/1012

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 7 Feb 2010 09:28:54 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Code freeze for 1.10.1 Sunday evening

Reminder: code freeze is tonight (or, if you're in Europe, potentially
as late as noon tomorrow). Get your patches for 1.10.1 in as soon as you
can!

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Friday, 05 February 2010, 12:23 PM -0500):
> We're planning on rolling out 1.10.1 this coming Tuesday, 9 February
> 2010. Please have any bugfixes, translations, etc. in by Sunday evening
> so that we can test and package on Monday.
> 
> Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 11:32:07 -0800
From: Kevin McArthur <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

>
>> (In past I saw user tables have ALL configuration in it, incl. css 
>> styles.)

Thats an app problem, not something the framework should strive to work 
with.

K

Marc Bennewitz wrote:
> How would you create a reproducible benchmark ?
>   - Is the DB local or reading from net ?
>   - how many fields are in this table and which type ?
> (In past I saw user tables have ALL configuration in it, incl. css styles.)
>
> In my opinion this would be a good solution if the default is set to *.
>
> @Diego
> $fields[] = $credentialExpression is more high-performance than
> array_push( $fields, $credentialExpression );
>
> --
> Marc
>
> Am 25.01.2010 18:45, schrieb Dolf Schimmel:
>   
>> I would indeed like to see some (reproducable) benchmarks that show a
>> significant improvement
>>
>> -- Freeaqingme
>>
>> On Mon, Jan 25, 2010 at 5:39 PM, Kevin McArthur <[email-masked]> wrote:
>>   
>>     
>>> The performance difference between a * and selected columns will be almost
>>> nil.... short of something like an unmaterialized and complex view [in the
>>> db sense] that is.
>>>
>>> I'd think this would add a fair amount of complication to the api and
>>> codebase for what will be, for most people, practically zero benefit.
>>> In-fact, for most, the additional requirement of a couple method invocations
>>> and string operations will likely negate the effect of not returning the
>>> extraneous columns in the first place.
>>>
>>> I'd vote no on this change.
>>>
>>> Kevin
>>>
>>>
>>> Diego Henrique Oliveira wrote:
>>>     
>>>       
>>>> In the adapter DbTable, the generated query to the database is a 'select
>>>> *', and as it was being a bottleneck in my application (users table with
>>>> many fields), i made these changes in the component
>>>> Zend_Auth_Adapter_DbTable.
>>>>
>>>>
>>>> class Zend_Auth_Adapter_DbTable
>>>> {
>>>>      protected $_returnedFields;
>>>>      public function setReturnedFields( array $fields )
>>>>    {
>>>>        $this->_returnedFields = $fields;
>>>>    }
>>>>      public function getReturnedFields()
>>>>    {
>>>>        if (is_null($this->_returnedFields))
>>>>        {
>>>>            return array('*');
>>>>        }
>>>>        return $this->_returnedFields;
>>>>    }
>>>>      /**
>>>>     * _authenticateCreateSelect() - This method creates a Zend_Db_Select
>>>> object that
>>>>     * is completely configured to be queried against the database.
>>>>     *
>>>>     * @return Zend_Db_Select
>>>>     */
>>>>    protected function _authenticateCreateSelect()
>>>>    {
>>>>        // build credential expression
>>>>        if (empty($this->_credentialTreatment) ||
>>>> (strpos($this->_credentialTreatment, '?') === false)) {
>>>>            $this->_credentialTreatment = '?';
>>>>        }
>>>>
>>>>        $credentialExpression = new Zend_Db_Expr(
>>>>            '(CASE WHEN ' .
>>>>            $this->_zendDb->quoteInto(
>>>>                $this->_zendDb->quoteIdentifier($this->_credentialColumn,
>>>> true)
>>>>                . ' = ' . $this->_credentialTreatment, $this->_credential
>>>>                )
>>>>            . ' THEN 1 ELSE 0 END) AS '
>>>>            . $this->_zendDb->quoteIdentifier(
>>>>                $this->_zendDb->foldCase('zend_auth_credential_match')
>>>>                )
>>>>            );
>>>>
>>>>        // get select
>>>>        $fields   = $this->getReturnedFields();
>>>>        array_push( $fields, $credentialExpression );
>>>>        $dbSelect = clone $this->getDbSelect();
>>>>        $dbSelect->from($this->_tableName, $fields)
>>>>
>>>> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . ' =
>>>> ?', $this->_identity);
>>>>
>>>>        return $dbSelect;
>>>>    }
>>>>   }
>>>>
>>>>
>>>>
>>>> What you guys think about these changes? And should I submit them to the
>>>> project?
>>>>
>>>>
>>>> Cheers
>>>>
>>>> Diego
>>>> http://diegoholiveira.com
>>>>
>>>>       
>>>>         
>>>     
>>>       
>>   
>>     

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Mon, 25 May 2009 01:05:53 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.8.2 code freeze

Hi all,

We have ZF 1.8.2 release planned to May 27. So code freeze period for
the release-1.8 branch is started now.=20
Please contact me if you have any additional 1.8.2 updates before
merging them into release branch.

With best regards,
   Alexander Veremyev.

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 22 Jul 2009 16:20:06 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] 1.9 Release Branch created

Greetings!

I have just created the 1.9 release branch, in preparation for the
release of 1.9.0 next week. At this point, we are now in feature freeze
for 1.9. If you have bugfixes or documentation updates between now and
the release, make them on trunk and merge them to the 1.9 release
branch.

We will be cutting a beta release of 1.9 for tomorrow, and would
appreciate any and all testing you can do on it. We're aiming for a very
stable release candidate at the beginning of next week, with a release
to follow later in the week; the more issues we catch before Monday, the
better!

Thanks for all the hard work all of you have done the past few months,
and kudos in advance on the upcoming release!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 16:03:45 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

-- Ralph Schindler <[email-masked]> wrote
(on Tuesday, 16 March 2010, 02:32 PM -0500):
> > Honestly, choosing "f" as an alias just seems like a bad idea from the
> > outset -- does it refer to "filter", or "form", or "file"? If you go
> 
> Totally agree.
> 
> > with a more explicit alias:
> > 
> >     use Zend\Filter;
> > 
> >     $filter = new Filter\Int;
> > 
> > the intent is already there.
> > 
> > I can see your point being more present if you import a single class
> > from a namespace:
> > 
> >     use Zend\Filter\Int;
> >     $filter = new Int();
> > 
> > *This* example more properly shows the issues, to my thinking. But even
> > then, better aliasing solves the problem:
> > 
> >     use Zend\Filter\Int as IntFilter;
> >     $filter = new IntFilter;
> > 
> 
> It could be argued the other way as well:
> 
> use Zend\Filter\IntFilter as Int;
> 
> $filter = new Int();

I'd argue that's a bad alias.

Why? Because what is "Int"? is it a class representing an integer? a
validator? a filter? The alias actually makes the name _less_
meaningful.

Aliases should be used to make shorter names that still adequately
convey the purpose or intent. The above example does not.

> The question is, do we rely completely on a classes placement in a
> namespace as its full intent and meaning? Or do we at least give it
> an identity of its own?

Namespaces are for providing context for a class. Plain and simple. 

So yes -- the namespace should convey some of the meaning and intent for
the class -- and so should aliases.

> IntFilter is still pretty short & concise as a class name, and it's
> purpose is further defined by the Zend\Filter namespace in which it
> resides.

I'd argue that Zend\Filter as a namespace connotes the purpose of the
class (a filter), while "Int" connotes the strategy. "Filter" as a class
suffix feels redundant.

> Did we move away from class Abstract {} and interface Interface {}
> inside of a namespace simply because they were technically
> impossible, or was it because on their own, a class named Abstract
> inside a namespace and an interface named Interface made little
> sense?

Both -- but the latter is what fueled the discussion on the post I
started yesterday. ;-)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 08:20:35 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

-- David Caunt <[email-masked]> wrote
(on Thursday, 25 February 2010, 11:13 AM +0000):
> Integration of Doctrine 1 with ZF 1.11 might be a good way to test the
> water and then community feedback may inform ZF2's integration with
> Doctrine 2.
> 
> As keen as I am for ZF2, I think the amount of work to be done on the
> core is substantial and probably leaves enough time for a 1.11
> release.

Well, that's what we're trying to gauge at this point. It seems like a
substantial amount of work, but if the initial development I outlined
goes quickly, we may find ourselves working on the various
rewrites/refactors much sooner, which could lead to an earlier release.
Then again, it may take much longer, meaning a delay. I don't want to
make a call either way yet, and thus the uncertainty about a 1.11
release.

If we end up deciding to do a 1.11 branch, we'll very likely look at
doing integration with Doctrine 1.2 for the very reasons you describe,
but also to serve as an upgrade path for ZF users.

> Are there any plans to maintain the 1.x series once 2.0 is released?

This is another area we're trying to gauge -- whether to continue
maintenance on the 1.X branch following a 2.0 release.

My personal feeling is that if we do, any future releases would address
only critical bugs or security issues, and no new features. As long as
we develop new features on the 1.X series, we'll hamper adoption of 2.0.
In this vein, we'd likely do like the PHP project did, and do a new
minor release on the version 1 branch simultaneous to 2.0 that would be
for tracking those issues.

If we do, I'll likely look for a small team from the community to assist
as release masters for that branch.

> On 25 February 2010 10:46, Giorgio Sironi <[email-masked]>
> wrote:
> 
>     On Thu, Feb 25, 2010 at 9:08 AM, Ashley Broadley <[email-masked]>
>     wrote:
> 
>         In my opinion if Doctrine integration is to be left until ZF 2.0, then
>         the integrated version of Doctrine should be the 2.0 version. Since
>         both 2.0 versions will require PHP 5.3.
> 
> 
>     I agree. Doctrine 2 will fill the lack of model infrastructure in Zend
>     Framework.
>     Anyway, the set of changes listed by Matthew is already a big step towards
>     simpler development (exploiting phpunit new features for example.)
> 
>     Regards,
>     --
>     Giorgio Sironi
>     Piccolo Principe & Web Engineer
>     http://giorgiosironi.blogspot.com
>     http://twitter.com/giorgiosironi
> 
> 
> 
> 
> --
> Save Water...Drink Ouzo !

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 8 Oct 2009 15:11:33 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [zf-contributors] Code Review

--_004_6B4A8009371807499638509271DEA796012B423ABDB1IMSCMAIL1im_
Content-Type: multipart/alternative;
	boundary="_000_6B4A8009371807499638509271DEA796012B423ABDB1IMSCMAIL1im_"

--_000_6B4A8009371807499638509271DEA796012B423ABDB1IMSCMAIL1im_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

I have been thinking about the problem that ZF ran into right after 1.9.3 w=
as release a few weeks ago and then we had to rush a 1.9.3pl1 into release.=
  Would using a tool such as Crucible from Atlassian help with this problem=
?

What does everyone else think?

<http://zend.com/zce.php?c=3DZEND002524=
&r=3D219549271>

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]<mailto:[email-masked]>
P: (317) 492-8623 - F: (317) 492-6419

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

--_000_6B4A8009371807499638509271DEA796012B423ABDB1IMSCMAIL1im_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Lucida Sans";
	panose-1:2 11 6 2 4 5 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I have been thinking about the problem that ZF ran i=
nto right after 1.9.3 was release a few weeks ago and then we had to rush a=
 1.9.3pl1 into release.&nbsp; Would using a tool such as Crucible from Atla=
ssian help with this problem?
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">What does everyone else think?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<td width=3D"80" valign=3D"top" style=3D"width:60.0pt;padding:0in 0in 0in 0=
in">
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><a href=
=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><span style=
=3D"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-serif&q=
uot;;color:blue;
  text-decoration:none"><img border=3D"0" width=3D"73" height=3D"68" id=3D"=
_x0000_i1025" src=3D"cid:[email-masked]" alt=3D"http://www.=
whitcraftconsulting.com/images/php5_zce_logo_new.gif"></span></a><span styl=
e=3D"font-size:12.0pt"><o:p></o:p></span></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Lu=
cida Sans&quot;,&quot;sans-serif&quot;">Jon Whitcraft<br>
Indianapolis Motor Speedway<br>
</span><span style=3D"font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><a href=3D"mailto:[email-masked]"><span style=3D=
"font-size:10.0pt;
  font-family:&quot;Lucida Sans&quot;,&quot;sans-serif&quot;;color:blue">jw=
[email-masked]</span></a><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span s=
tyle=3D"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-ser=
if&quot;">P: (317) 492-8623 - F: (317) 492-6419</span><span style=3D"font-s=
ize:9.0pt;font-family:
  &quot;Arial&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><br clear=3D"all">
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<br>
<font face=3D"Arial" color=3D"Gray" size=3D"1">********************<br>
********************<br>
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify
 the sender by reply E-mail and erase this E-mail from your system. Your as=
sistance is appreciated. E-mail transmission may not be secure or error-fre=
e. The company is not responsible for any loss/damage arising from any viru=
s transmitted.<br>
********************<br>
********************<br>
</font>
</body>
</html>

--_000_6B4A8009371807499638509271DEA796012B423ABDB1IMSCMAIL1im_--

--_004_6B4A8009371807499638509271DEA796012B423ABDB1IMSCMAIL1im_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=2553;
	creation-date="Thu, 08 Oct 2009 15:11:34 GMT";
	modification-date="Thu, 08 Oct 2009 15:11:34 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_004_6B4A8009371807499638509271DEA796012B423ABDB1IMSCMAIL1im_--

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 17 Jan 2010 02:08:51 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Serializer work

Hi Julien,

I changed ZF-8842 to use class_implements because on creating an
instance you executes code on an unchecked class.

I don't know how to change the "Fix/Version" on a closed issue.
ZF-8842 is changed now because reopened.

Marc

Am 16.01.2010 23:52, schrieb Julien Pauli:
> Hi,
>
> I recently commited 20343-20345-20346 for Zend_Serializer.
> See http://framework.zend.com/issues/browse/ZF-8844 -
> http://framework.zend.com/issues/browse/ZF-8842
>
> I forgot to set the "Fix/Version" to next minor (1.10) , how can I
> edit that later ? Reopening the issue seems the only way right ?
>
> Anyway, tell me if something goes wrong with the patches (shouldn't) ;-)
>
> J.Pauli

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Mon, 8 Jun 2009 04:02:30 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] ZF 1.8.3 and code freeze period

Hi all!

ZF 1.8.3 is planned for tomorrow, so code freeze period has already
started. Please contact me if you need to make any merges into
release-1.8 branch before ZF 1.8.3 launching.

With best regards,
   Alexander Veremyev.

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Tue, 28 Jul 2009 09:12:05 +0200
Subject: Re: [zf-contributors] Contributor list

Like for all other pages within our wiki you need to login.
It's the same process as if you edit one of your proposals.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Daniel Lo" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>
Sent: Tuesday, July 28, 2009 8:00 AM
Subject: Re: [zf-contributors] Contributor list

Hello Thomas,

How do we edit this page? or do we turn in this information to you 
personally?

-daniel

Jira: danlo

Monday, July 27, 2009, 8:25:10 AM, you wrote:

> Hy all,

> we have since several months a contributor list.
> http://framework.zend.com/wiki/pages/viewpage.action?pageId=11036

> Now for 1.9 it's time again to update this list.
> Every contributor/maintainer/component lead is announced to update this 
> list
> with his own informations within the proper component.

> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com

-- 
Best regards,
 Daniel                            mailto:[email-masked] 

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 17:33:36 +0100
From: till <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 option classes for methods

On Mon, Mar 15, 2010 at 4:51 PM,  <[email-masked]> wrote:
> For easy usage of methods is it possible, to add option classes for metho=
ds that accept options as array or Zend_Config?
>
> Code Assist in IDE's would propose the appropriate options including desc=
ription.
>
> /**
> =A0* @property-read string $host =A0 =A0 What host to connect to...
> =A0* @property-read string $username Connect to the database...
> =A0* @property-read string $password Password associated with the...
> =A0* @property-read string $dbname =A0 The name of the database to user
> =A0*/

I think these are used to do cover __get() (and well, __set() with
@property-write).

Till

nFrom nobody Wed Apr  7 08:46:15 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 21 Jan 2010 15:11:31 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] RC1 tagged

Hey, all --

1.10.0rc1 has been tagged, and we'll be releasing it in the next few
hours.

In the meantime, please keep the following in mind:

 * Please merge any bugfixes you make on trunk to the release-1.10
   branch

 * Please note in the commit message the severity of the issue. For
   example, if the class is completely broken without the change, note
   that; if it's a fix to a typo in the docblock, note that.

We will incorporate all bugfixes into the 1.10.0 release. However, if
there are any major issues corrected between now and Sunday, we will
release a new RC on Sunday evening to ensure we get more eyes on the
release.

If you are working on new features or improvements, please leave these
on trunk for the next minor or major release.

Our plan is to release 1.10.0 [stable] this upcoming Tuesday, the 26th.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 8 Apr 2009 14:20:50 +0200
From: Tobias Gies <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 1.8 Preview Release is released

When will it be announced on fw-general?

Best regards,
Tobias

2009/4/8 Matthew Weier O'Phinney <[email-masked]>:
> Greetings, all!
>
> I've just finished releasing the 1.8 preview release, and you can
> download it from http://framework.zend.com/download/latest. The manual
> has also been updated to reflect the new functionality.
>
> On that note, there was a snafu when merging in the ZendX documentation.
> Alex will hit that first thing in the morning so that it's present. If
> you see any other anomolies, please send an email in reply to this one.
>
> Thanks everyone for all the hard work in getting contributions ready for
> this milestone. Let's work on polishing it and getting additional
> bugfixes in before the final release later this month!
>
> --
> Matthew Weier O'Phinney
> Software Architect =A0 =A0 =A0| [email-masked]
> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 11:44:08 -0800
From: Kevin McArthur <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] New Sections for Zend Framework 2.0 Roadmap

This is a multi-part message in MIME format.
--------------020306040109060401090606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Inline.
> PRG is something that can be built around forms, but has nothing to do
> with the main purpose of the form component, which is to encapsulate
> form element metadata and validation, and to facilitate rendering. PRG
> is something you'd handle in your controller. We should not be tightly
> binding forms and controllers; they should remain loosely coupled (if at
> all coupled).
>   
The issue is that Zend_Form and PRG being so loosely coupled makes it a 
real pain to do PRG, and sadly results in most people who use Zend_Form 
not doing PRG (not good for anyone). The biggest issue comes from when 
validators add error messages, and fields need to remember their values. 
Currently this has to be manually saved to each field, and the 
controllers quickly become unwieldy. There's a prop for prg (and 
multi-page forms)... but I'm not sure how that integrates into 2.0 here....

PRG can be handled in the controller, but when you start doing that you 
really lose any value that ZFORM adds -- I pretty much just use 
Zend_Validate/Zend_Filter_Input on its own these days because ZFORM adds 
so little value in the the PRG context.

I really think that a PRG scenario, and a simplification on how this 
works currently should be added to the 2.0 map -- even if you wont 
accept PRG as a default scenario [which I think it should be as get 
forms are usually treated as parameters, and most forms are therefore 
posted statefully]

Using PRG _should_ be as easy as not using it, and the 
Zend_Session/FlashMessenger/SaveState stuff should all be handled in the 
core classes as its really laborious to do it in the controllers, and 
for the most part, totally redundant and unnecessary.

>> This is obviously a quick overview, but the idea is to more tightly
>> tie Zend_Form in with the request cycle, assume PRG is the priority
>> method for forms, and treat decoration in the view, not the model or
>> controller.
>>     
>
> As noted, I don't think PRG has anything to do with the forms, but
> everything to do with controllers, and should be treated there. It's
> already trivially easy to accomplish.
>   
Trivial is relative I suppose. The tying in of Zend_Form with 
Zend_Session to remember state, validation errors and flash messenger 
with the controller layer to glue it together, its not trivial enough. 
Most of the forms examples don't do PRG, and last I checked its not even 
the quickstart recommended method. 
(http://framework.zend.com/docs/quickstart/create-a-form doesn't 
redirect on failure for example) ... the docs follow in the same vain.

What I'm recommending is for 2.0 is that PRG become 'the' way to do post 
forms in ZFW 2.0. Or at least, a heck of a lot less terse in terms of 
the coding required. Lets integrate 
Session/FlashMessenger/Routing/Controllers into a comprehensive 'forms' 
solution -- it'll result in better outcomes for deployed applications. 
There's already some unimplemented support in the 1.0 model in terms of 
state saving... so its been on the radar...

Kevin

--------------020306040109060401090606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Inline.<br>
<blockquote cite="mid:20091117191644.GR25898@localhost" type="cite">
  <pre wrap="">
PRG is something that can be built around forms, but has nothing to do
with the main purpose of the form component, which is to encapsulate
form element metadata and validation, and to facilitate rendering. PRG
is something you'd handle in your controller. We should not be tightly
binding forms and controllers; they should remain loosely coupled (if at
all coupled).
  </pre>
</blockquote>
The issue is that Zend_Form and PRG being so loosely coupled makes it a
real pain to do PRG, and sadly results in most people who use Zend_Form
not doing PRG (not good for anyone). The biggest issue comes from when
validators add error messages, and fields need to remember their
values. Currently this has to be manually saved to each field, and the
controllers quickly become unwieldy. There's a prop for prg (and
multi-page forms)... but I'm not sure how that integrates into 2.0
here.... <br>
<br>
PRG can be handled in the controller, but when you start doing that you
really lose any value that ZFORM adds -- I pretty much just use
Zend_Validate/Zend_Filter_Input on its own these days because ZFORM
adds so little value in the the PRG context. <br>
<br>
I really think that a PRG scenario, and a simplification on how this
works currently should be added to the 2.0 map -- even if you wont
accept PRG as a default scenario [which I think it should be as get
forms are usually treated as parameters, and most forms are therefore
posted statefully]<br>
<br>
Using PRG _should_ be as easy as not using it, and the
Zend_Session/FlashMessenger/SaveState stuff should all be handled in
the core classes as its really laborious to do it in the controllers,
and for the most part, totally redundant and unnecessary. <br>
<br>
<blockquote cite="mid:20091117191644.GR25898@localhost" type="cite">
  <blockquote type="cite">
    <pre wrap="">This is obviously a quick overview, but the idea is to more tightly
tie Zend_Form in with the request cycle, assume PRG is the priority
method for forms, and treat decoration in the view, not the model or
controller.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
As noted, I don't think PRG has anything to do with the forms, but
everything to do with controllers, and should be treated there. It's
already trivially easy to accomplish.
  </pre>
</blockquote>
Trivial is relative I suppose. The tying in of Zend_Form with
Zend_Session to remember state, validation errors and flash messenger
with the controller layer to glue it together, its not trivial enough.
Most of the forms examples don't do PRG, and last I checked its not
even the quickstart recommended method.
(<a class="moz-txt-link-freetext" href="http://framework.zend.com/docs/quickstart/create-a-form">http://framework.zend.com/docs/quickstart/create-a-form</a> doesn't
redirect on failure for example) ... the docs follow in the same vain.<br>
<br>
What I'm recommending is for 2.0 is that PRG become 'the' way to do
post forms in ZFW 2.0. Or at least, a heck of a lot less terse in terms
of the coding required. Lets integrate
Session/FlashMessenger/Routing/Controllers into a comprehensive 'forms'
solution -- it'll result in better outcomes for deployed applications.
There's already some unimplemented support in the 1.0 model in terms of
state saving... so its been on the radar...<br>
<br>
Kevin
</body>
</html>

--------------020306040109060401090606--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 14:15:39 -0700
From: Tommy Smith <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

--00c09f905a22e4c9980480734840
Content-Type: text/plain; charset=ISO-8859-1

I have nothing of value to add - but, I want to say that being on this
mailing list is super educational!

Here at the office, developers make the svn/git arguments daily. My argument
arsenal in this battle (and many others) gets filled by all of the emails
that flow through this mailing list.

Thanks for making me smarter everybody!

Tommy Smith
bodybuilding.com

On Thu, Feb 25, 2010 at 1:48 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> -- Graham Anderson <[email-masked]> wrote
> (on Thursday, 25 February 2010, 08:54 PM +0100):
> > On Thursday 25 February 2010 17:44:54 Luke Crouch wrote:
> > > Maybe I'm turning into a crotchety old programmer, but I'm not really
> > > impressed with git. We switched from svn to git at my day job and I
> > > haven't really seen any big benefits aside from a few sweet syntactic
> > > shortcuts like git stash. For larger projects with well-organized
> > > branching I just haven't seen much additional value from git.
> >
> > I think if I was working in house with a centralised core of programmers,
> > there is a compelling argument to perhaps stay with SVN. You can enforce
> > practices in the organisation and you can deploy a common set of tools.
> SVN
> > access is much easier to manage.
> >
> > ZF on the other hand is already a distributed project and Git's work-flow
> and
> > utilities are very well matched. The cheap branching and merging is in
> it's
> > own right reason enough to switch, in my opinion; but there are many
> other
> > aspects to Git that make it better for ZF's needs.
>
> I've been using git+svn for around 18 months now, and the cheap
> branching and ease of merging are what keep me using the combo.
>
> As an example, earlier this week I was working on several different bug
> fixes at once, and waiting for some from other contributors that
> affected what I was working on.
>
> I branched locally for the code that needed collaboration, did my bits,
> and then returned to my master branch. I then branched again to work on
> another fix, got interrupted, checked out the collaboration branch,
> merged in some changes, finished up, pushed, went back to my other
> bugfix branch, finished up...
>
> This would have been next to impossible to do cleanly with svn.
>
> Other times, I've been working on something, and needed to put it aside for
> awhile. "git stash" to the rescue -- stashed my changes, worked on trunk
> for a bit, and then "git stash pop" to restore my work. Again, basically
> impossible with svn.
>
> > Remote tracking of multiple branches on multiple repo's combined with
> cheap
> > and easy merging is a killer feature. Not only does it make a maintainers
> life
> > a ton easier, it makes collaboration very much easier than SVN too, one
> of the
> > reasons GitHub/Gitorius are so successful...
>
> One thing I'd never quite understood with git was the multiple remotes
> bit, until I saw a talk by Scott Chacon at symfony live last week. And
> suddenly it clicked. You give a handful of people write access to the
> main repository, and this is what everyone tracks. People clone it, and
> then issue a pull request to a release master. The release master can
> track multiple repos from multiple collaborators, and then selectively
> merge into their own "master" -- and push those patches into the
> mainline.
>
> Best of all, git keeps track of the original source, unlike when I merge
> people's code from incubator to trunk today. :)
>
> > Sure, I'm passionate about Git but it's because it has helped me
> > become more productive, and to me that is utter invaluable. I want ZF
> > to switch to Git not because I think it's the better tool or because
> > it's not SVN, I want ZF to switch to Git because I believe ZF as a
> > project and anyone who uses ZF will benefit more so than staying with
> > SVN.
>
> Well-stated, sir.
>
> My personal preference is to use Git -- mainly because I think it will
> give us more flexibility in organizing the project's processes, and
> because I think it will lead to more democratic development.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--00c09f905a22e4c9980480734840
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have nothing of value to add - but, I want to say that being on this mail=
ing list is super educational!=A0<div><br></div><div>Here at the office, de=
velopers make the svn/git arguments daily. My argument arsenal in this batt=
le (and many others) gets filled by all of the emails that flow through thi=
s mailing list.<div>
<br></div><div>Thanks for making me smarter everybody!</div><div><br></div>=
<div>Tommy Smith</div><div><a href=3D"http://bodybuilding.com">bodybuilding=
.com</a><br><br><div class=3D"gmail_quote">On Thu, Feb 25, 2010 at 1:48 PM,=
 Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:matthe=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">-- Graham Anderson &lt;<a href=3D"mailto:gr=
[email-masked]">[email-masked]</a>&gt; wrote<br>
(on Thursday, 25 February 2010, 08:54 PM +0100):<br>
&gt; On Thursday 25 February 2010 17:44:54 Luke Crouch wrote:<br>
&gt; &gt; Maybe I&#39;m turning into a crotchety old programmer, but I&#39;=
m not really<br>
&gt; &gt; impressed with git. We switched from svn to git at my day job and=
 I<br>
&gt; &gt; haven&#39;t really seen any big benefits aside from a few sweet s=
yntactic<br>
&gt; &gt; shortcuts like git stash. For larger projects with well-organized=
<br>
&gt; &gt; branching I just haven&#39;t seen much additional value from git.=
<br>
&gt;<br>
&gt; I think if I was working in house with a centralised core of programme=
rs,<br>
&gt; there is a compelling argument to perhaps stay with SVN. You can enfor=
ce<br>
&gt; practices in the organisation and you can deploy a common set of tools=
. SVN<br>
&gt; access is much easier to manage.<br>
&gt;<br>
&gt; ZF on the other hand is already a distributed project and Git&#39;s wo=
rk-flow and<br>
&gt; utilities are very well matched. The cheap branching and merging is in=
 it&#39;s<br>
&gt; own right reason enough to switch, in my opinion; but there are many o=
ther<br>
&gt; aspects to Git that make it better for ZF&#39;s needs.<br>
<br>
I&#39;ve been using git+svn for around 18 months now, and the cheap<br>
branching and ease of merging are what keep me using the combo.<br>
<br>
As an example, earlier this week I was working on several different bug<br>
fixes at once, and waiting for some from other contributors that<br>
affected what I was working on.<br>
<br>
I branched locally for the code that needed collaboration, did my bits,<br>
and then returned to my master branch. I then branched again to work on<br>
another fix, got interrupted, checked out the collaboration branch,<br>
merged in some changes, finished up, pushed, went back to my other<br>
bugfix branch, finished up...<br>
<br>
This would have been next to impossible to do cleanly with svn.<br>
<br>
Other times, I&#39;ve been working on something, and needed to put it aside=
 for<br>
awhile. &quot;git stash&quot; to the rescue -- stashed my changes, worked o=
n trunk<br>
for a bit, and then &quot;git stash pop&quot; to restore my work. Again, ba=
sically<br>
impossible with svn.<br>
<br>
&gt; Remote tracking of multiple branches on multiple repo&#39;s combined w=
ith cheap<br>
&gt; and easy merging is a killer feature. Not only does it make a maintain=
ers life<br>
&gt; a ton easier, it makes collaboration very much easier than SVN too, on=
e of the<br>
&gt; reasons GitHub/Gitorius are so successful...<br>
<br>
One thing I&#39;d never quite understood with git was the multiple remotes<=
br>
bit, until I saw a talk by Scott Chacon at symfony live last week. And<br>
suddenly it clicked. You give a handful of people write access to the<br>
main repository, and this is what everyone tracks. People clone it, and<br>
then issue a pull request to a release master. The release master can<br>
track multiple repos from multiple collaborators, and then selectively<br>
merge into their own &quot;master&quot; -- and push those patches into the<=
br>
mainline.<br>
<br>
Best of all, git keeps track of the original source, unlike when I merge<br=
people&#39;s code from incubator to trunk today. :)<br>
<br>
&gt; Sure, I&#39;m passionate about Git but it&#39;s because it has helped =
me<br>
&gt; become more productive, and to me that is utter invaluable. I want ZF<=
br>
&gt; to switch to Git not because I think it&#39;s the better tool or becau=
se<br>
&gt; it&#39;s not SVN, I want ZF to switch to Git because I believe ZF as a=
<br>
&gt; project and anyone who uses ZF will benefit more so than staying with<=
br>
&gt; SVN.<br>
<br>
Well-stated, sir.<br>
<br>
My personal preference is to use Git -- mainly because I think it will<br>
give us more flexibility in organizing the project&#39;s processes, and<br>
because I think it will lead to more democratic development.<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</font></blockquote></div><br></div></div>

--00c09f905a22e4c9980480734840--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 14 Jul 2009 10:39:06 -0500
From: Ralph Schindler <[email-masked]>
To: Rob Allen <[email-masked]>
CC: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend_Db_Adapter_Sqlsrv ready for review

This is an awesome addition for the windows devlopment environment.

Nice work!
-ralph

Rob Allen wrote:
> Hi all,
> 
> Juozas and myself worked on an adapter for the MS SQL Server Driver for 
> PHP during the euro-win-php competition. As this is a useful component 
> for anyone working on Windows with SQL Server, we've created a proposal 
> which is now ready for review:
> 
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Adapter_Sqlsrv+-+Juozas+Kaziukenas+and+Rob+Allen 
> 
> 
> There's also working source code at https://zfmssql.svn.codeplex.com/svn/
> 
> We'd appreciate any and all comments on it :)
> 
> Regards,
> 
> Rob...
> 
> 

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Sat, 23 Jan 2010 00:28:39 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors]
	=?UTF-8?Q?Zend=5FDate=20=26=20build-in=20class=20Da?=
	=?UTF-8?Q?teTime?=

The timestamp is available from DateTime per calling
$dateTime->format('U');
ever since its first release.

On Sat, 23 Jan 2010 00:24:54 +0100, "Thomas Weidner"
<[email-masked]> wrote:
> This has been discussed several times in past and the answer is still
the=20
> same.
>=20
> "As long as ZF uses minimum required PHP Versions where DateTime is not=
=20
> available per default (without changing configuration after
installation)
> we=20
> will not change the I18n core."
>=20
> Additionally the method "getTimestamp" you referred to is available per
> PHP=20
> 5.3.0. It was not available in DateTime below this PHP release.
>=20
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>=20
> ----- Original Message -----=20
> From: "Marc Bennewitz" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, January 22, 2010 11:16 PM
> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>=20
>=20
>> Hi all,
>>
>> Does is matter that Zend_Date doesn't extends the build-in DateTime
>> class
>> ?
>> -> The DateTime class is available since PHP 5.2.0 and ZF require PHP=20
>> 5.2.4.
>>
>> It would be very nice because than Zend_Date would be compatible to
>> other php libraries using DateTime and within ZF tests like the
>> following can simplify:
>>
>> if ($date instanceof Zend_Date_DateObject) {
>>    $timestamp =3D $date->getUnixTimestamp();
>> } elseif ($date instanceof DateTime) {
>>    $timestamp =3D $date->getTimestamp();
>> } else {
>>    $timestamp =3D (float)$date;
>> }
>>
>> Greetings,
>> Marc
>>

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 18 Mar 2009 13:19:16 +0200
From: vadim gavrilov <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Problem in the framework translation status list

--001636c5b154ae8b81046562da7c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

The problem still persists, it's been weeks since i reported this and
nothing really changed, i assume something in the system that updates the
status causing it to break and display 0% for all translations.

I am talking about this page:

http://framework.zend.com/manual/status

-- 
Vincent Gabriel.
Lead Developer, Senior Support.
Zend Certified Engineer.

--001636c5b154ae8b81046562da7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<div dir="ltr">The problem still persists, it&#39;s been weeks since i reported this and nothing really changed, i assume something in the system that updates the status causing it to break and display 0% for all translations.<br>
<br>I am talking about this page:<br><br><a href="http://framework.zend.com/manual/status">http://framework.zend.com/manual/status</a><br clear="all"><br>-- <br>Vincent Gabriel.<br>Lead Developer, Senior Support.<br>Zend Certified Engineer.<br>
<br><br><br><br>
</div>

--001636c5b154ae8b81046562da7c--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Mar 2010 09:15:10 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Ralph Schindler <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Introducing a Tool for Namespacing PHP5
	Prefixed codebases

--0-2025796622-1269533710=:44831
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Good job! I'll take it for a spin on something like Zend_Feed later ;)=0A=
=0APaddy=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://w=
ww.survivethedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=
=0A=0A=0A=0A=0A________________________________=0AFrom: Ralph Schindler <ra=
[email-masked]>=0ATo: "Zend Framework Contributors (zf-contributors=
@lists.zend.com)" <[email-masked]>=0ACc: Zend Framework Gen=
eral <[email-masked]>=0ASent: Thu, March 25, 2010 2:01:36 PM=0AS=
ubject: [zf-contributors] Introducing a Tool for Namespacing PHP5 Prefixed =
codebases=0A=0AHey All-=0A=0AOver the past few days, I've been working on a=
 tool that I think might help expedite the task of converting all of our co=
de into a Namespaced codebase.  Currently, it's been tested on simple compo=
nents like Zend_Acl and Zend_Filter and over the course of the next few day=
s, we'll be applying it to some of the more complex components.=0A=0AWhat i=
t does..=0A=0AThis tool is a command line tool.  First, you may get it from=
 my GitHub repository:=0A=0Ahttp://github.com/ralphschindler/PHPTools=0Agit=
 clone http://github.com/ralphschindler/PHPTools.git=0A=0A-OR-=0A=0AJust do=
wnload the tar/gz/zip via the github interface.=0A=0AInside here you'll fin=
d a bin/ library/ and test/ directory, the namespacer tool is located in th=
is library.  To get the basic help screen, simply run 'php bin/php-namespac=
er.php -h'.  This will give you a couple of available options to understand=
 what the various command line switches do.  Personally, I create a link fr=
om somewhere in my path, usually $HOME/bin/php-namespacer to path/to/PHPToo=
ls/bin/php-namespacer.php, this makes it easier to run the command from any=
where in your filesystem.=0A=0ATo be able to get up and running with it qui=
ckly, I suggest running to tool in the following manner to get an idea of w=
hat it will produce:=0A=0Abash> php-namespacer -l=3D../library/ -d=3DZend/A=
cl -p=3DZend -o=3D./tmp/ -m=3D./tmp/=0A=0AHere are is what the above is goi=
ng to do:=0A=0A  * with the -l switch, you are telling it the location of a=
 library=0A    this is typically the same directory you'd add to an include=
_path=0A=0A  * with the -d switch, you are telling the tool that of all the=
=0A    classes it comes across in the library, only work on this=0A    part=
icular directory=0A=0A  * -p is the prefix we want to work on, in our case =
Zend/=0A=0A  * -o is the directory where you want your new files written to=
=0A=0A  * -m is the directory where an XML file will be produced of all the=
=0A    name translations that have taken place.=0A=0AThe full library is su=
pplied so that the tool can iterate all files for class names that might be=
 present inside the working directory's files. This is so that it knows wha=
t those translations will be once those components are eventually converted=
 (assuming they are part of the same effort).=0A=0AThis tool will OPTIONALL=
Y convert names in docblock ONLY if you have the pecl ext/docblock extensio=
n compiled and enabled (http://pecl.php.net/package/docblock).  Otherwise i=
t will not touch the docblocks.=0A=0AI have to admit that even though we ar=
e seeing some great results so far, this tool is still in it's infancy.  We=
 are opening it up to you for feedback and if you find it useful, to run it=
 over your own code to see if it does the job of converting prefixed PHP5 c=
ode into namespaced PHP 5.3 code.=0A=0AI'll let everyone get a chance to ru=
n the tool and produce some output first before we start discussing the act=
ual output and file contents. For discussion purposes, we've been heavily l=
ooking at simpler components like Zend_Acl, Zend_Filter and Zend_Config- bu=
t don't let that stop you from running it over other components or even you=
r own code.=0A=0ALet me know what you think!=0ARalph Schindler=0A
--0-2025796622-1269533710=:44831
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Good job! I'll take it for a spin on something like Zend_Feed =
later ;)<br><br>Paddy<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 1=
91);"><font style=3D"font-family: times new roman,new york,times,serif;" si=
ze=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></span><=
/font><span style=3D"font-style: italic;"><font style=3D"font-family: times=
 new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com<=
/a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethed=
eepend.com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" tar=
get=3D"_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundatio=
n Irish Representative</a><br></font></span></span><div><br></div><div styl=
e=3D"font-family: times new
 roman,new york,times,serif; font-size: 12pt;"><br><div style=3D"font-famil=
y: tahoma,new york,times,serif; font-size: 8pt;"><font size=3D"2" face=3D"T=
ahoma"><hr size=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b=
> Ralph Schindler &lt;[email-masked]&gt;<br><b><span style=3D"fon=
t-weight: bold;">To:</span></b> "Zend Framework Contributors (zf-contributo=
[email-masked])" &lt;[email-masked]&gt;<br><b><span styl=
e=3D"font-weight: bold;">Cc:</span></b> Zend Framework General &lt;fw-gener=
[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">Sent:</span>=
</b> Thu, March 25, 2010 2:01:36 PM<br><b><span style=3D"font-weight: bold;=
">Subject:</span></b> [zf-contributors] Introducing a Tool for Namespacing =
PHP5 Prefixed codebases<br></font><br>=0AHey All-<br><br>Over the past few =
days, I've been working on a tool that I think might help expedite the task=
 of converting all of our code into a Namespaced codebase.&nbsp; Currently,=
 it's been tested on simple components like Zend_Acl and Zend_Filter and ov=
er the course of the next few days, we'll be applying it to some of the mor=
e complex components.<br><br>What it does..<br><br>This tool is a command l=
ine tool.&nbsp; First, you may get it from my GitHub repository:<br><br><sp=
an><a target=3D"_blank" href=3D"http://github.com/ralphschindler/PHPTools">=
http://github.com/ralphschindler/PHPTools</a></span><br><span>git clone <a =
target=3D"_blank" href=3D"http://github.com/ralphschindler/PHPTools.git">ht=
tp://github.com/ralphschindler/PHPTools.git</a></span><br><br>-OR-<br><br>J=
ust download the tar/gz/zip via the github interface.<br><br>Inside here yo=
u'll find a bin/ library/ and test/ directory, the namespacer tool is locat=
ed in this library.&nbsp; To get the basic
 help screen, simply run 'php bin/php-namespacer.php -h'.&nbsp; This will g=
ive you a couple of available options to understand what the various comman=
d line switches do.&nbsp; Personally, I create a link from somewhere in my =
path, usually $HOME/bin/php-namespacer to path/to/PHPTools/bin/php-namespac=
er.php, this makes it easier to run the command from anywhere in your files=
ystem.<br><br>To be able to get up and running with it quickly, I suggest r=
unning to tool in the following manner to get an idea of what it will produ=
ce:<br><br>bash&gt; php-namespacer -l=3D../library/ -d=3DZend/Acl -p=3DZend=
 -o=3D./tmp/ -m=3D./tmp/<br><br>Here are is what the above is going to do:<=
br><br>&nbsp; * with the -l switch, you are telling it the location of a li=
brary<br>&nbsp; &nbsp; this is typically the same directory you'd add to an=
 include_path<br><br>&nbsp; * with the -d switch, you are telling the tool =
that of all the<br>&nbsp; &nbsp; classes it comes across in the library, on=
ly
 work on this<br>&nbsp; &nbsp; particular directory<br><br>&nbsp; * -p is t=
he prefix we want to work on, in our case Zend/<br><br>&nbsp; * -o is the d=
irectory where you want your new files written to<br><br>&nbsp; * -m is the=
 directory where an XML file will be produced of all the<br>&nbsp; &nbsp; n=
ame translations that have taken place.<br><br>The full library is supplied=
 so that the tool can iterate all files for class names that might be prese=
nt inside the working directory's files. This is so that it knows what thos=
e translations will be once those components are eventually converted (assu=
ming they are part of the same effort).<br><br><span>This tool will OPTIONA=
LLY convert names in docblock ONLY if you have the pecl ext/docblock extens=
ion compiled and enabled (<a target=3D"_blank" href=3D"http://pecl.php.net/=
package/docblock">http://pecl.php.net/package/docblock</a>).&nbsp; Otherwis=
e it will not touch the docblocks.</span><br><br>I have to admit that
 even though we are seeing some great results so far, this tool is still in=
 it's infancy.&nbsp; We are opening it up to you for feedback and if you fi=
nd it useful, to run it over your own code to see if it does the job of con=
verting prefixed PHP5 code into namespaced PHP 5.3 code.<br><br>I'll let ev=
eryone get a chance to run the tool and produce some output first before we=
 start discussing the actual output and file contents. For discussion purpo=
ses, we've been heavily looking at simpler components like Zend_Acl, Zend_F=
ilter and Zend_Config- but don't let that stop you from running it over oth=
er components or even your own code.<br><br>Let me know what you think!<br>=
Ralph Schindler<br></div></div>=0A</div></body></html>
--0-2025796622-1269533710=:44831--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 8 Dec 2009 05:09:30 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Thomas Weidner <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

--0-236097565-1260277770=:53321
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>The ONLY secure way to use the striptags filter is to strip ALL =0Atags/at=
tributes/comments.=0A=0AThis is how the class should be presented, and its =
design should be rectified to only fit this specific use case.=0A=0A P=E1dr=
aic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.=
com=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=0A=0A=0A______=
__________________________=0AFrom: Thomas Weidner <[email-masked]>=
=0ATo: [email-masked]=0ASent: Mon, December 7, 2009 4:11:52=
 PM=0ASubject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities=
 In Zend_Filter_StripTags=0A=0AI think it was created as extension to PHP's=
 striptags allowing comments and attributes to be whitelisted.=0A=0AStill, =
as also PHP's own striptags method, it does not prevent on XSS or other att=
acks. PHP mentions this within it's manual.=0A=0AThe ONLY secure way to use=
 the striptags filter is to strip ALL tags/attributes/comments.=0A=0AGreeti=
ngs=0AThomas Weidner, I18N Team Leader, Zend Framework=0Ahttp://www.thomasw=
eidner.com=0A=0A----- Original Message ----- From: "Giorgio Sironi" <piccol=
[email-masked]>=0ATo: "P=E1draic Brady" <[email-masked]=
m>=0ACc: "Zend Framework Contributors" <[email-masked]>=0AS=
ent: Monday, December 07, 2009 4:02 PM=0ASubject: Re: [zf-contributors] XSS=
 And Malformed HTML Vulnerabilities In Zend_Filter_StripTags=0A=0A=0A> But =
why it has been created at all?=0A> =0A> -- Giorgio Sironi=0A> Piccolo Prin=
cipe & Web Engineer=0A> http://giorgiosironi.blogspot.com=0A> http://twitte=
r.com/giorgiosironi=0A> 
--0-236097565-1260277770=:53321
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">&gt;The ONLY secure way to use the striptags filter is to stri=
p ALL =0Atags/attributes/comments.<br><br>This is how the class should be p=
resented, and its design should be rectified to only fit this specific use =
case.<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font styl=
e=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><span s=
tyle=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span styl=
e=3D"font-style: italic;"><font style=3D"font-family: times new roman,new y=
ork,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"=
http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a rel=3D=
"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com">http=
://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_blank" h=
ref=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Represen=
tative</a><br></font></span></span><div><br></div><div style=3D"font-family=
: times new roman,new york,times,serif; font-size: 12pt;"><br><div style=3D=
"font-family: tahoma,new
 york,times,serif; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"><hr si=
ze=3D"1"><b><span style=3D"font-weight: bold;">From:</span></b> Thomas Weid=
ner &lt;[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">=
To:</span></b> [email-masked]<br><b><span style=3D"font-wei=
ght: bold;">Sent:</span></b> Mon, December 7, 2009 4:11:52 PM<br><b><span s=
tyle=3D"font-weight: bold;">Subject:</span></b> Re: [zf-contributors] XSS A=
nd Malformed HTML Vulnerabilities In Zend_Filter_StripTags<br></font><br>=
=0AI think it was created as extension to PHP's striptags allowing comments=
 and attributes to be whitelisted.<br><br>Still, as also PHP's own striptag=
s method, it does not prevent on XSS or other attacks. PHP mentions this wi=
thin it's manual.<br><br>The ONLY secure way to use the striptags filter is=
 to strip ALL tags/attributes/comments.<br><br>Greetings<br>Thomas Weidner,=
 I18N Team Leader, Zend Framework<br><span><a target=3D"_blank" href=3D"htt=
p://www.thomasweidner.com">http://www.thomasweidner.com</a></span><br><br>-=
---- Original Message ----- From: "Giorgio Sironi" &lt;<a ymailto=3D"mailto=
:[email-masked]" href=3D"mailto:piccoloprincipeazzurro@gm=
ail.com">[email-masked]</a>&gt;<br>To: "P=E1draic Brady" =
&lt;<a ymailto=3D"mailto:[email-masked]" href=3D"mailto:padraic.br=
[email-masked]">[email-masked]</a>&gt;<br>Cc: "Zend Framework Contr=
ibutors" &lt;<a ymailto=3D"mailto:[email-masked]"
 href=3D"mailto:[email-masked]">[email-masked].=
com</a>&gt;<br>Sent: Monday, December 07, 2009 4:02 PM<br>Subject: Re: [zf-=
contributors] XSS And Malformed HTML Vulnerabilities In Zend_Filter_StripTa=
gs<br><br><br>&gt; But why it has been created at all?<br>&gt; <br>&gt; -- =
Giorgio Sironi<br>&gt; Piccolo Principe &amp; Web Engineer<br><span>&gt; <a=
 target=3D"_blank" href=3D"http://giorgiosironi.blogspot.com">http://giorgi=
osironi.blogspot.com</a></span><br><span>&gt; <a target=3D"_blank" href=3D"=
http://twitter.com/giorgiosironi">http://twitter.com/giorgiosironi</a></spa=
n><br>&gt; <br><br></div></div>=0A<!-- cg2.c902.mail.ac4.yahoo.com compress=
ed/chunked Mon Dec  7 03:29:14 PST 2009 -->=0A</div></body></html>
--0-236097565-1260277770=:53321--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 10:27:09 -0700
From: Matthew Ratzloff <[email-masked]>
To: Nico Edtinger <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?

--001636283e944bcf160474420681
Content-Type: text/plain; charset=UTF-8

That's a good compromise solution.
-Matt

On Wed, Sep 23, 2009 at 4:11 AM, Nico Edtinger <[email-masked]> wrote:

> Matthew Ratzloff wrote:
>
>> Breaking BC in a mini release is bad news.  I would strongly suggest
>> adding
>> a new option in the config array (second parameter) to control inflection,
>> with the default the old style.  This way, in your config you can say:
>>
>> db.newInflector = true
>>
>
> Do we really need a new option? What I've read the problem is people
> writing 'PDO_MYSQL' or 'pdo_mysql'. It should suffice to convert the name if
> it's completely uppercase or lowercase and else leave as is.
>
> nico
>

--001636283e944bcf160474420681
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That&#39;s a good compromise solution.<div><br></div><div>-Matt<br><br><div=
 class=3D"gmail_quote">On Wed, Sep 23, 2009 at 4:11 AM, Nico Edtinger <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">Matthew Ratzloff wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Breaking BC in a mini release is bad news. =C2=A0I would strongly suggest a=
dding<br>
a new option in the config array (second parameter) to control inflection,<=
br>
with the default the old style. =C2=A0This way, in your config you can say:=
<br>
<br>
db.newInflector =3D true<br>
</blockquote>
<br></div>
Do we really need a new option? What I&#39;ve read the problem is people wr=
iting &#39;PDO_MYSQL&#39; or &#39;pdo_mysql&#39;. It should suffice to conv=
ert the name if it&#39;s completely uppercase or lowercase and else leave a=
s is.<br>
<font color=3D"#888888">
<br>
nico<br>
</font></blockquote></div><br></div>

--001636283e944bcf160474420681--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 11 Oct 2009 22:46:51 +0200
From: Pieter Kokx <[email-masked]>
To: Ralph Schindler <[email-masked]>
CC: "Whitcraft, Jon" <[email-masked]>, 
	"[email-masked]" <[email-masked]>
Subject: Re: [zf-contributors] Code Review

Sorry, i forgot to hit the 'reply all' button:

In most of my projects, I am already having an SVN external on the
latest ZF branch, and I am quite sure that I'm not the only one doing that.

Best Regards,

Pieter Kokx

Ralph Schindler schreef:
> Ok, I'm gonna throw out something I've been thinking for a while.
>
> I think we should have a list of projects, sites, and dedicated
> contributors (it can be a google spreadsheet for that matter) that
> have no problem keeping their project up to date with the latest ZF
> branch version.  What this would allow us to do is say "here is the
> latest zf 1.9.x, please try it in your project".  Then, we have at
> least 5 days where we collect feedback before actually publishing the
> version.  This will provide us with plenty enough time to catch any
> unknown/undocumented usage case breaks.
>
> Having more time between the actual building of a release package, and
> the actual publishing of that release package.  Perhaps we call it a
> ReleaseCandidate, but if we do, we at least have to alert the
> aforementioned list that we'd like them to try it out on their project.
>
> Call this "QA from the field".
>
> -ralph
>
> Whitcraft, Jon wrote:
>> Hello,
>>
>>  
>>
>> I have been thinking about the problem that ZF ran into right after
>> 1.9.3 was release a few weeks ago and then we had to rush a 1.9.3pl1
>> into release.  Would using a tool such as Crucible from Atlassian
>> help with this problem?
>>
>>  
>>
>> What does everyone else think?
>>
>>  
>>
>> http://www.whitcraftconsulting.com/images/php5_zce_logo_new.gif
>> <http://zend.com/zce.php?c=ZEND002524&r=219549271>
>>
>>     
>>
>> Jon Whitcraft
>> Indianapolis Motor Speedway
>> [email-masked] <mailto:[email-masked]>
>>
>> P: (317) 492-8623 - F: (317) 492-6419
>>
>>
>>  
>>
>>
>> ********************
>> ********************
>> This E-mail (and attachments) may contain confidential/privileged
>> information intended only for the named addressee(s). If you are not
>> an intended recipient, do not read, copy, disseminate or take any
>> action based on the content of this E-mail. Please notify the sender
>> by reply E-mail and erase this E-mail from your system. Your
>> assistance is appreciated. E-mail transmission may not be secure or
>> error-free. The company is not responsible for any loss/damage
>> arising from any virus transmitted.
>> ********************
>> ********************
>
>

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Thu, 1 Apr 2010 16:48:51 +0200
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

> Now, since the Symfony Live conference, I've also been thinking about
> something Fabien said about Symfony 2: "less magic." To clarify, the
> idea is to design components so that they are explicit about what they
> can do. As an example, instead of using __get() and __set(), using
> explicit getters and setters; instead of using __call(), explicitly
> defining methods; instead of having __call() proxy to helpers, having a
> broker from which you pull them as needed.

Apparently the rumors on twitter were in place; the conference did
have a bad influence on you :D

More seriously, I think this can in no way be compared with SF's
"magic" (does the fact that our Zend_Magic only is imaginative mean ZF
does at this moment not contain any magic?).

Firstly, if you have a class called foo\Filter which contains an
__invoke() method,
that method should obviously filter. As long as it does that and only
that, there's no magic imho involved. Same goes for foo\Validator (its
__invoke() method is supposed to validate), and foo\Bootstrap (guess
what: __invoke() should bootstrap here). If we can get it done
consistently I'm pretty sure everybody will be used to it within the
first 5 seconds they look at a random piece of code.

Secondly Symfony's magic is on an entirely different scale of
magnitude than the naming of one type of method.  Compare
$random->method() generating an entire application for you with
$object() which exactly does what the name of the object implies.

Situations in which you have two methods doing exactly the same are
often/usually a result of willing to change, but also struggling with
inability to do so due to backwards compatibility constraints.
However, now that we're busy on something where potentially all BC may
be broken, I really don't think having two methods doing exactly the
same would be beneficial to anybody. In fact, it would increase the
amount of options to do something with (give or take) N! which is an
awful lot, without any added value.

My $0.02 (you can keep those, dollar's value sucks anyways)

Dolf
Freeaqingme

On Thu, Apr 1, 2010 at 3:07 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> I've been following this thread as well as discussions on IRC with
> interest, as, honestly, I can completely buy into all arguments, which
> are, to sum things up:
>
> =C2=A0* Use only __invoke()
> =C2=A0* Use a method name specific to the interface
> =C2=A0* Use a standardized method name, such as "run" or "execute"
> =C2=A0* Use a combination of __invoke() and either a meaningful or
> =C2=A0 standardized method name.
>
> I got to thinking about why I suggested "__invoke()" in the first place,
> and went back to the plugin architecture page:
>
> =C2=A0* http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architecture=
s
>
> The original rationale was for using pubsub/filter chain systems. In
> such systems, you attach callbacks:
>
> =C2=A0 =C2=A0$chain->attach($callback);
>
> If your objects implement __invoke(), $callback can simply be your
> object -- you're done. Otherwise, you also have to provide the method:
>
> =C2=A0 =C2=A0$chain->attach($object, $method);
>
> Interestingly, in this document, I also recommended that for existing
> interfaces, __invoke() be added as an _additional_ method, and that it
> should proxy to the appropriate interface method. In this case, we'd
> simply be taking advantage of a language feature in places it makes
> sense.
>
> Now, since the Symfony Live conference, I've also been thinking about
> something Fabien said about Symfony 2: "less magic." To clarify, the
> idea is to design components so that they are explicit about what they
> can do. As an example, instead of using __get() and __set(), using
> explicit getters and setters; instead of using __call(), explicitly
> defining methods; instead of having __call() proxy to helpers, having a
> broker from which you pull them as needed.
>
> This has several implications:
>
> =C2=A0* Less need for explicit documentation. If you have behaviors relyi=
ng
> =C2=A0 on the magic methods, developers *must* read the the documentation=
 in
> =C2=A0 order to know how a class/component works. If everything is explic=
it,
> =C2=A0 the class is self-documenting, and you can get the information you
> =C2=A0 need from API docs, your IDE, etc.
>
> =C2=A0* Performance. Magic methods are reportedly less performant than us=
ing
> =C2=A0 straight method calls (more on this later).
>
> These are important factors, and the test-driven developer in me
> particularly likes less magic; it's much easier to test when you have
> explicit behaviors.
>
> That said, I decided to run some tests. These were the scenarios:
>
> =C2=A0* No Proxying:
> =C2=A0 * Defined "filter" method returns value
> =C2=A0 * Defined "__call" method returns value
> =C2=A0 * Defined "__invoke" method returns value
> =C2=A0* Proxying:
> =C2=A0 * Defined "filter" method returns value
> =C2=A0 * Defined "__call" method proxies to "filter"
> =C2=A0 * Defined "__invoke" method proxies to "filter"
> =C2=A0* Inverse proxying
> =C2=A0 * Defined "filter" method calls invoke (as "$this();")
> =C2=A0 * Defined "__invoke" method returns value
> =C2=A0* call_user_func_array()
> =C2=A0 * Using array($obj, 'filter') callback
> =C2=A0 * Using __invoke() with no proxying
> =C2=A0 * Using __invoke() with proxying
>
> The results were quite interesting. Across the board, using __call() is
> awful -- even if you simply return a value, it's on average 6x slower
> than a straight method call; proxying to another method, however,
> doesn't take significantly longer (so long as you're not using
> call_user_func_array() internally, that is).
>
> __invoke(), however, turns out to be quite different. When not proxying,
> it's actually *faster* than a method call (about 25% on average).
> Proxing __invoke() to a method call or doing the inverse are roughly the
> same speed -- about 2.5x slower than a straight method call (which, as
> you'll note, is still over twice as fast as using __call()).
>
> What was *really* interesting, however, was using
> call_user_func_array(), which is commonly used in filter chains and/or
> brokers. =C2=A0__invoke(), with or without proxying, *always* was around =
30%
> *faster* than using an explicit array($obj, $method) callback.
>
> So, what does this tell me?
>
> =C2=A0* AVOID using __call(), particularly for often-used method calls. F=
or
> =C2=A0 helper systems, it will always be better to use a helper broker an=
d
> =C2=A0 command pattern.
>
> =C2=A0* For classes meant to be used primarily with filter chains or brok=
ers,
> =C2=A0 DO use __invoke(), even if it simply proxies to another interface
> =C2=A0 method.
>
> So, based on the design goals and the performance benchmarking, I'm
> going to recommend that Filter and Validator (we renamed Validate to
> Validator) define an __invoke() method in addition to a more explicit
> interface method, and that helpers also follow this pattern.
>
> -- Matthew Weier O'Phinney <[email-masked]> wrote
> (on Wednesday, 31 March 2010, 10:21 AM -0400):
>> Greetings, all --
>>
>> Per the roadmap, one change we're planning on making is making plugin
>> usage consistent across components: plugins will implement __invoke(),
>> which makes them inherently callable.
>>
>> In our refactoring branch, I've done this now with Zend_Filter. However,
>> it required a ton of refactoring on the unit tests (had to either call
>> __invoke() directly, or $filter($value)), and it got me to thinking:
>>
>> Would it make sense to keep the original interfaces (filter, isValid,
>> render, etc.), but also implement __invoke() -- having it proxy to the
>> appropriate interface method?
>>
>> As an example:
>>
>> =C2=A0 =C2=A0 interface Filter
>> =C2=A0 =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function filter($value);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function __invoke($value);
>> =C2=A0 =C2=A0 }
>>
>> =C2=A0 =C2=A0 class Digits implements Filter
>> =C2=A0 =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function filter($value)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... logic...
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 public function __invoke($value)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return $this->filter($value);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>> =C2=A0 =C2=A0 }
>>
>> The benefits:
>>
>> =C2=A0* Fewer changes necessary to existing unit tests
>> =C2=A0* interface method names may be more descriptive of intent
>>
>> Problems:
>>
>> =C2=A0* Using __invoke() introduces overhead -- 2 method calls instead o=
f one
>> =C2=A0* Redundancy (two methods doing the same thing)
>> =C2=A0* A few extra tests to write (to ensure __invoke works as expecte)
>>
>> After discussion with Ralph and Alex, I'm leaning towards having
>> __invoke() as an _additional_ method, instead of replacing existing
>> methods.
>>
>> Any thoughts or comments?
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
>> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend=
.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 10:57:37 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

-- Simone Carletti <[email-masked]> wrote
(on Monday, 22 March 2010, 01:46 PM +0100):
> I don't know the details about how you are going to manage the git push/pull
> task from a local machine to a git server, however I suggest you to have a look
> at the following document.
> http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
> 
> It describes how gitosis works and, AFAIK, it roughly resemble to the current
> GitHub and Gitorious system.

Indeed, I've been playing with Gitorious and git-daemon (former for
write-access, latter for read-only; they work together quite well).

> Basically, you have one unique unix user which handles all the communication
> from the local machine to the master repository.
> All users pull and push changes using this user. Internally the system checks
> the public ssh key of the committer agains a whitelist which is stored itself
> in a Git repos.
> 
> In your case, the whitelist can be the list of all users which signed the CLA
> and are allowed to send commits to the repository.

THe problem is going to be ensuring that patches that the contributors
have merged and commit fall under the CLA. However, if they are doing
true merges, we can likely at the least look at the email associated
with each merged commit (I've seen some hooks for doing this exact
thing). This could potentially be spoofed, but so can svn credentials,
to be honest.

> I hope this can help you,
> -- Simone
> 
> 
> On Mon, Mar 22, 2010 at 1:36 PM, Matthew Weier O'Phinney <[email-masked]>
> wrote:
> 
>      If you have any ideas on handling ACLs, I'd love to
>     hear them, and sooner rather than later!
> 
>     --
>     Matthew Weier O'Phinney
>     Project Lead            | [email-masked]
>     Zend Framework          | http://framework.zend.com/
>     PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> 
> 
> 
> 
> --
> Simone Carletti
> 
> Site & Blog: http://www.simonecarletti.com
> Email: [email-masked]
> LinkedIn: http://linkedin.com/in/weppos
> Nick: weppos | Skype: weppos

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 17 Jan 2010 14:36:26 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Serializer work

Hi,

I would like to add a coding standard block for String access and
modification by character:

$str = 'my string';

// WRONG:
$str{1} == 'y'

// RIGHT:
$str[1] == 'y'

Note:  Strings may also be accessed using braces, as in $str{42}, for
the same purpose. However, this syntax is deprecated as of PHP 5.3.0.
Use square brackets instead, such as $str[42]. 
@see
http://php.net/manual/en/language.types.string.php#language.types.string.substr

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 18 Nov 2009 11:59:32 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Dev Tools going down for an hour or two

The upgrade to Crowd 2.0.2 was successful, and all developer tools are
now back online. Thanks for your patience, everyone!

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Wednesday, 18 November 2009, 10:04 AM -0500):
> Hey, all --
> 
> We need to upgrade Crowd, which provides the single sign-on capabilities
> for the various developer tools (wiki, issue tracker, etc.). This will
> require taking all of them offline for an hour or two.
> 
> I will post here again once they are all back up.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: =?iso-8859-1?Q?Marcus_St=F6hr?= <[email-masked]>
Date: Thu, 21 Jan 2010 15:17:48 +0100
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Zend_Service_Itunes component proposal

Hi,

I just posted my proposal on Zend_Service_Itunes. You can search the =
iTunes Store using the Apple iTunes Store Webservice API. I'm looking =
forward to any suggestions, advices und opinions. :)

The proposal can be found here: =
http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_Itunes

- Marcus=

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 5 Jun 2009 08:34:54 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] addScriptPath question

-- till <[email-masked]> wrote
(on Thursday, 04 June 2009, 10:50 PM +0200):
> On Thu, Jun 4, 2009 at 10:14 PM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
> > -- till <[email-masked]> wrote
> > (on Thursday, 04 June 2009, 07:11 PM +0200):
> > > Sort of related, it would be nice if there were no private methods =
in
> > > that class. ;-(
> >
> > Dude, this has been covered *so* many times, and it even has a sectio=
n
> > in the manual covering the "why" of the design:
> >
> > =A0 =A0http://framework.zend.com/manual/en/zend.view.abstract.html
> >
> > Short answer: the private methods are not going away, as they are an
> > important implementation detail.
>=20
> Yeah, I actually found an issue in Jira but besides I didn't see the
> above documentation.
>=20
> Having read that and the issue in Jira. I still don't like it. =3D) I
> need to jump through hoops so someone doesn't override something
> because he got no idea. Using the interface is just pure overkill when
> you want to change the behavior of a single method. All of the sudden
> I need to implement my own view, essentially duplicate code, etc..

Um, you know that you can re-declare private methods as protected in an
extending class, right? Yes, you need to do the full implementation, as
you cannot then call parent::, but it's one way forward. (I've done this
myself.)

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 17:36:11 +0100
From: H2Lsoft <[email-masked]>
Organization: H2Lsoft
To: [email-masked]
Subject: [zf-contributors] unsuscribe

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 21 Jul 2009 16:37:09 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Feature Freeze starts tomorrow!

Greetings, all!

Feature freeze will start tomorrow around 14:00 EDT (give or take an
hour). I'll send out an announcement to the list and also in the
#zftalk.dev channel once I create the release-1.9 branch. Once I have,
NO new features will be allowed in that branch going forward. Bugfixes
should be done on trunk and merged to the release-1.9 branch from that
point forward.

We plan to cut and release a Beta of 1.9 on Thursday, and, barring any
major issues, an RC on Monday. Please test frequently, and provide
feedback ASAP. 

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 20:19:22 -0800
From: Kevin McArthur <[email-masked]>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

This is a multi-part message in MIME format.
--------------070008050704020105070401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

> That's a massively misleading statement.

I don't have much more to say on this subject, as I think I've made my=20
vision clear. But don't underestimate the power of engaged component=20
leaders to maintain code quality without formal process. This current=20
process is of but one way to do things, it hasn't always been this way,=20
and it doesn't have to be in the future. It can be re-evaluated,=20
especially in the 2.0 context -- and it's certainly not massively=20
misleading to say 1.0 was achieved [or that it was a success] without=20
the current level of process involved.

Kevin

P=E1draic Brady wrote:
> >I doubt this greatly, ZF to 1.0 was a huge success and had none of=20
> this stuff. A decent vetting by interested coders was all it took to=20
> keep the quality up. Most of that
> >code still comprises the code base today, and it still runs fine. The=20
> docs were enough to get interested developers over the initial hurdles=20
> and the rest came through other
> >sources like blogs, irc, books and sample code. I'm not saying we go=20
> back to totally untested code or anything like that, I guess I just=20
> see tests like icing, not an
> >ingredient. If there's tests, great, if not, put it on the todo and=20
> move on. Instead we've got tests that are at times even=20
> counter-productive as you describe.
>
> That's a massively misleading statement. I was around pre-1.0 too. The=20
> number of components and lines-of-code were a tiny fraction of what=20
> currently exists, and oddly enough, even at that there were tests and=20
> docs. ZF 0.x without those would never have been a success.=20
> Counter-productive tests are a problem - unfortunately overview has=20
> been lacking in the past otherwise they'd have been noticed a lot=20
> sooner. Not to drag this into a present context - as far as I know=20
> Matthew does review new test suites as part of the review process.
>
> >I'd argue that some of those components are bad in part because of=20
> the requirement.
>
> No, they are bad in spite of the requirement. Tests, docs or nothing=20
> at all - bad code is bad code.
>
> >That assumes that a large amount of this work isn't optional -- when=20
> it is. Those useless tests are there because someone said 'must have=20
> tests', many, possibly most, of
> >them are totally unneeded except to up the code coverage report=20
> statistics. A minority of the ZFW tests do any useful testing, and for=20
> those, I'm glad there's tests... and I
> >believe those tests would still be there if they weren't required to b=
e.
>
> I agree the code coverage is sometimes horribly artificial (personally=20
> I believe a coverage of 60% is acceptable in a lot of cases - I do add=20
> stupid little tests to get to 85% like testing getters (ye gods) or=20
> worse). It's always a complaint when I run code coverage on a shiny=20
> new class and it pops a 55% coverage ;). I know the tests are=20
> sufficient but a rule is a rule since, as many tests prove, you really=20
> can't trust all developers. Even I make silly typos at times - even in=20
> dumb getters sometimes.
>
> Nevertheless, whether the rule adds work or not - the point is that=20
> the work must get done one way or another before any contribution can=20
> be committed to trunk for the next release.
>
> >I suspect many wont expect their contributions to be accepted -- and=20
> instead of capitulating to the requirements, will simply abandon the=20
> contribution.
>
> Already happening to be honest. Unfortunately, I'm unwilling to vet=20
> every single contribution and patch, and so are the contributors. It's=20
> going to happen a lot.
>
> >I think you just made my point.
>
> Rest of quote? ;) The front controller is just another object - how do=20
> you get any other object in whatever class you need it? It's not=20
> something magical...
>
> >I'd hate to think what it would take to get a class as complicated as=20
> Zend_Pdf_Resource_Image_Tiff committed today....
>
> Probably the same effort - with testing. I'm a fan of TDD though so=20
> I'm totally biased in favour of a test driven approach - I've yet to=20
> find anything too complex to handle with it.
>
> >We agree here. Today is too complicated... Tomorrow will be too=20
> complicated... I was hoping with 2.0 that we would figure out where=20
> the redundancies are and nix em >--> i'd start at the actionstack, but=20
> thats just me. Now we're talking FSM's, and DI systems... which is=20
> cool in a compsci kinda way, but fantastically complicated out of >the=20
> box.
> >Is it a SDK, a black box, or are we helping people make applications=20
> they understand? Whats the implication of blind use of the framework?
>
> Same could be said of namespaces, closures, all that other compsci=20
> ECMA stuff. DI and FSM are not complicated or weird or conceptually=20
> difficult - they are merely different. What we have at the moment is=20
> more familiar - and a mess. Unfortunately, ZF or not, MVC is always=20
> going to be more complicated as it needs more features. The C part of=20
> MVC remains the most expensive part of ZF performance wise. That won't=20
> change, but maybe the new concepts will help. They surely will NOT=20
> make it more complex. Whether it simplifies anything - open question=20
> to Matthew? ;)
>
> >Theres a reason we write books on this stuff instead of user docs.....
>
> Devs are horrible writers. Unrelated, but true! The manual has become=20
> a monster read.
>
> >"No" is a policy, and its not a very good one.
>
> Don't get me wrong - I agree it's not the best policy ever, but who's=20
> going to contribute the resources to make the policy "yes"? In reality=20
> a "no" is the only possible answer in an open source project with=20
> limited resources.
>
> Paddy
>
>  P=E1draic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative=20
> <http://www.openideurope.eu/>
>
>
> -----------------------------------------------------------------------=
-
> *From:* Kevin McArthur <[email-masked]>
> *To:* P=E1draic Brady <[email-masked]>
> *Cc:* Zend Framework Contributors <[email-masked]>
> *Sent:* Fri, November 13, 2009 12:58:43 AM
> *Subject:* Re: [zf-contributors] Zend Framework 2.0 Roadmap
>
> P=E1draic Brady wrote:
>>
>> The main wall Kevin just hit is simply never going away. If it ever=20
>> did, ZF wouldn't be far behind it as a untested, undocumented morass=20
>> of code that (allegedly) does stuff.
> I doubt this greatly, ZF to 1.0 was a huge success and had none of=20
> this stuff. A decent vetting by interested coders was all it took to=20
> keep the quality up. Most of that code still comprises the code base=20
> today, and it still runs fine. The docs were enough to get interested=20
> developers over the initial hurdles and the rest came through other=20
> sources like blogs, irc, books and sample code. I'm not saying we go=20
> back to totally untested code or anything like that, I guess I just=20
> see tests like icing, not an ingredient. If there's tests, great, if=20
> not, put it on the todo and move on. Instead we've got tests that are=20
> at times even counter-productive as you describe.
>
>> We need all the "contribution overhead". It is absolutely essential.=20
>> There are components in the ZF which, to be generous, are pretty bad=20
>> in terms of testing, documentation and flexibility already - and=20
>> that's with the requirement! I have worse descriptions. Catch me on=20
>> IRC during a bug hunt and I'll share some ;).
>
> I'd argue that some of those components are bad in part because of the=20
> requirement.
>>
>> The fact is, if you cannot handle the additional work that underpins,=20
>> supports and ensures ease of maintenance for a component - then you=20
>> are begging for a developer to start swearing over IRC. I had the joy=20
>> of dealing with such a component a few weeks back. It took me hours=20
>> to figure out a bug. Why? Because the unit tests DID NOT TEST the=20
>> functionality of the component. I could have deleted every single=20
>> test with no ill effect - they were all busy with XML parsing or=20
>> something (performed by a completely different component with its own=20
>> perfectly functional unit tests).
> That sounds about right.
>>
>> But worse than all this, is the assumption that lowering the=20
>> contribution overhead is a positive thing. It's not - it merely=20
>> shifts that work onto someone else.
> That assumes that a large amount of this work isn't optional -- when=20
> it is. Those useless tests are there because someone said 'must have=20
> tests', many, possibly most, of them are totally unneeded except to up=20
> the code coverage report statistics. A minority of the ZFW tests do=20
> any useful testing, and for those, I'm glad there's tests... and I=20
> believe those tests would still be there if they weren't required to be=
.
>> Someone else with precious little time and a chargeout rate to=20
>> justify work with. And surprise - they won't like that in the=20
>> slightest. Sometimes you get lucky - I spent about 10 hours of=20
>> otherwise chargeable time in September's bug hunt (which I enjoyed a=20
>> lot by the way) along with several evenings but generally everyday=20
>> work will always lean towards ignoring contributions where no=20
>> supporting "contribution overhead" has also been committed. Such=20
>> contributions/patches/whatever can be horrible to work on. No tests,=20
>> poor explanations, lack of communication, differing assumptions -=20
>> ugh. If it's not worth contributing in full, don't expect someone=20
>> else to do it - they probably won't.
> I suspect many wont expect their contributions to be accepted -- and=20
> instead of capitulating to the requirements, will simply abandon the=20
> contribution.
>>
>> Sorry for the ranty piece - but code doesn't write itself. It is=20
>> great to have a contribution - so long as you don't pin it all on=20
>> someone else ;).
> Pin what? When I developed the Zend PDF image parsers for example, I=20
> didn't write any tests, I did functional testing to the best I=20
> could.... and we went from there. Those classes exist in the framework=20
> today in basically the same format. That contribution process was very=20
> different from today, but it worked great. I'd hate to think what it=20
> would take to get a class as complicated as=20
> Zend_Pdf_Resource_Image_Tiff committed today....
>>
>> Which one? Nobody said there would be one front controller.
> For 99.999% of uses theres only one url, and only a need for one front=20
> controller.
>> My guess, is that it will be accessible from your bootstrap, which is=20
>> registered to the front controller, which is registered to...I'm lost=20
>> now.
> I think you just made my point.
>>
>> Trace what under the hood?=20
>> Request->Route->Dispatch->Controller->Action <- stick plugins in=20
>> between. It's not rocket science.
> Add into that Zend_Application->Zend_Config->Get Bootstrap Name=20
> Setting->do whatever *secret sauce*->all before you get to the mvc=20
> dispatch process above. Now, from the code source I looked at before,=20
> its going to require creating some sort of methodinvokers, event=20
> delegates and hooking into a series of events. Tracing back from=20
> output to figure out where something is happening truly is a science=20
> these days -- most of the time I end up pecking around in the leaves,=20
> instead of tracing from the trunk. It gets even more complicated when=20
> you start talking partials, helpers( think actionstack ), and the=20
> myriad of other ways to inject into the request cycle.
>> If you doubled the complexity of the implementation today, it would=20
>> still quack like the same duck it was yesterday.
> We agree here. Today is too complicated... Tomorrow will be too=20
> complicated... I was hoping with 2.0 that we would figure out where=20
> the redundancies are and nix em --> i'd start at the actionstack, but=20
> thats just me. Now we're talking FSM's, and DI systems... which is=20
> cool in a compsci kinda way, but fantastically complicated out of the b=
ox.
>
> Is it a SDK, a black box, or are we helping people make applications=20
> they understand? Whats the implication of blind use of the framework?
>> Right now you can still conceptually grasp MVC and use it, without=20
>> ever reading the source code. In fact, right now MVC is a pretty=20
>> complex beast in ZF. It would take a serious effort to complicate it=20
>> further :).
> Theres a reason we write books on this stuff instead of user docs.....
>>
>> >Can a skilled PHP developer contribute a change to the framework easi=
ly
>> >without being involved in the ZFW core politics, contribution process=
es,
>> >proposal processes, test writing, doc writing, etc.
>>
>> ZF may be one of the few non-political projects around. I've had some=20
>> fun of course butting heads in the past, but the last two years have=20
>> been politics free. Everything else is answered "no". Who else is=20
>> going to miraculously write someone else's tests/docs/proposals? Not=20
>> me :P.
> "No" is a policy, and its not a very good one.
>
> $0.02
>
> Kevin

--------------070008050704020105070401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote type="cite">That's a massively misleading statement.</blockquote>
<br>
I don't have much more to say on this subject, as I think I've made my
vision clear. But don't underestimate the power of engaged component
leaders to maintain code quality without formal process. This current
process is of but one way to do things, it hasn't always been this way,
and it doesn't have to be in the future. It can be re-evaluated,
especially in the 2.0 context -- and it's certainly not massively
misleading to say 1.0 was achieved [or that it was a success] without
the current level of process involved. <br>
<br>
Kevin<br>
<br>
P&aacute;draic Brady wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <style type="text/css"><!-- DIV {margin:0px;} --></style>
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">&gt;I
doubt this greatly, ZF to 1.0 was a huge success and had none of this
stuff. A decent vetting by interested coders was all it took to keep
the quality up. Most of that <br>
&gt;code still comprises the code base today,
and it still runs fine. The docs were enough to get interested
developers over the initial hurdles and the rest came through other
  <br>
&gt;sources like blogs, irc, books and sample code. I'm not saying we
go
back to totally untested code or anything like that, I guess I just see
tests like icing, not an <br>
&gt;ingredient. If there's tests, great, if not,
put it on the todo and move on. Instead we've got tests that are at
times even counter-productive as you describe.<br>
  <br>
That's a massively misleading statement. I was around pre-1.0 too. The
number of components and lines-of-code were a tiny fraction of what
currently exists, and oddly enough, even at that there were tests and
docs. ZF 0.x without those would never have been a success.
Counter-productive tests are a problem - unfortunately overview has
been lacking in the past otherwise they'd have been noticed a lot
sooner. Not to drag this into a present context - as far as I know
Matthew does review new test suites as part of the review process.<br>
  <br>
&gt;I'd argue that some of those components are bad in part because of
the
requirement.<br>
  <br>
No, they are bad in spite of the requirement. Tests, docs or nothing at
all - bad code is bad code.<br>
  <br>
&gt;That assumes that a large amount of this work isn't optional --
when it
is. Those useless tests are there because someone said 'must have
tests', many, possibly most, of <br>
&gt;them are totally unneeded except to up
the code coverage report statistics. A minority of the ZFW tests do any
useful testing, and for those, I'm glad there's tests... and I <br>
&gt;believe
those tests would still be there if they weren't required to be.<br>
  <br>
I agree the code coverage is sometimes horribly artificial (personally
I believe a coverage of 60% is acceptable in a lot of cases - I do add
stupid little tests to get to 85% like testing getters (ye gods) or
worse). It's always a complaint when I run code coverage on a shiny new
class and it pops a 55% coverage ;). I know the tests are sufficient
but a rule is a rule since, as many tests prove, you really can't trust
all developers. Even I make silly typos at times - even in dumb getters
sometimes.<br>
  <br>
Nevertheless, whether the rule adds work or not - the point is that the
work must get done one way or another before any contribution can be
committed to trunk for the next release.<br>
  <br>
&gt;I suspect many wont expect their contributions to be accepted --
and
instead of capitulating to the requirements, will simply abandon the
contribution.<br>
  <br>
Already happening to be honest. Unfortunately, I'm unwilling to vet
every single contribution and patch, and so are the contributors. It's
going to happen a lot.<br>
  <br>
&gt;I think you just made my point.<br>
  <br>
Rest of quote? ;) The front controller is just another object - how do
you get any other object in whatever class you need it? It's not
something magical...<br>
  <br>
&gt;I'd hate to think what it
would take to get a class as complicated as
Zend_Pdf_Resource_Image_Tiff committed today....<br>
  <br>
Probably the same effort - with testing. I'm a fan of TDD though so I'm
totally biased in favour of a test driven approach - I've yet to find
anything too complex to handle with it.<br>
  <br>
&gt;We agree here. Today is too complicated... Tomorrow will be too
complicated... I was hoping with 2.0 that we would figure out where the
redundancies are and nix em &gt;--&gt; i'd start at the actionstack,
but
thats just me. Now we're talking FSM's, and DI systems... which is cool
in a compsci kinda way, but fantastically complicated out of &gt;the
box.<br>
&gt;Is it a SDK, a black box, or are we helping people make
applications
they understand? Whats the implication of blind use of the framework?<br>
  <br>
Same could be said of namespaces, closures, all that other compsci ECMA
stuff. DI and FSM are not complicated or weird or conceptually
difficult - they are merely different. What we have at the moment is
more familiar - and a mess. Unfortunately, ZF or not, MVC is always
going to be more complicated as it needs more features. The C part of
MVC remains the most expensive part of ZF performance wise. That won't
change, but maybe the new concepts will help. They surely will NOT make
it more complex. Whether it simplifies anything - open question to
Matthew? ;)<br>
  <br>
&gt;Theres a reason we write books on this stuff instead of user
docs.....<br>
  <br>
Devs are horrible writers. Unrelated, but true! The manual has become a
monster read.<br>
  <br>
&gt;"No" is a policy, and its not a very good one.<br>
  <br>
Don't get me wrong - I agree it's not the best policy ever, but who's
going to contribute the resources to make the policy "yes"? In reality
a "no" is the only possible answer in an open source project with
limited resources.<br>
  <br>
Paddy<br>
  <br>
&nbsp;<span style="color: rgb(0, 0, 191);"><font
 style="font-family: times new roman,new york,times,serif;" size="3"><span
 style="font-weight: bold;">P&aacute;draic Brady<br>
  <br>
  </span></font><span style="font-style: italic;"><font
 style="font-family: times new roman,new york,times,serif;" size="3"><a
 moz-do-not-send="true" rel="nofollow" target="_blank"
 href="http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>
  <a moz-do-not-send="true" rel="nofollow" target="_blank"
 href="http://www.survivethedeepend.com">http://www.survivethedeepend.com</a><br>
  <a moz-do-not-send="true" rel="nofollow" target="_blank"
 href="http://www.openideurope.eu/">OpenID Europe Foundation Irish
Representative</a><br>
  </font></span></span>
  <div><br>
  </div>
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
  <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font
 face="Tahoma" size="2">
  <hr size="1"><b><span style="font-weight: bold;">From:</span></b>
Kevin McArthur <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
  <b><span style="font-weight: bold;">To:</span></b> P&aacute;draic Brady
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
  <b><span style="font-weight: bold;">Cc:</span></b> Zend Framework
Contributors <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
  <b><span style="font-weight: bold;">Sent:</span></b> Fri, November
13, 2009 12:58:43 AM<br>
  <b><span style="font-weight: bold;">Subject:</span></b> Re:
[zf-contributors] Zend Framework 2.0 Roadmap<br>
  </font><br>
  <meta http-equiv="x-dns-prefetch-control" content="off">
P&aacute;draic Brady wrote:
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
The main wall Kevin just hit is simply never going away. If it ever
did, ZF wouldn't be far behind it as a untested, undocumented morass of
code that (allegedly) does stuff. </div>
  </blockquote>
I doubt this greatly, ZF to 1.0 was a huge success and had none of this
stuff. A decent vetting by interested coders was all it took to keep
the quality up. Most of that code still comprises the code base today,
and it still runs fine. The docs were enough to get interested
developers over the initial hurdles and the rest came through other
sources like blogs, irc, books and sample code. I'm not saying we go
back to totally untested code or anything like that, I guess I just see
tests like icing, not an ingredient. If there's tests, great, if not,
put it on the todo and move on. Instead we've got tests that are at
times even counter-productive as you describe.<br>
  <br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">We
need all the "contribution overhead". It is absolutely essential. There
are components in the ZF which, to be generous, are pretty bad in terms
of testing, documentation and flexibility already - and that's with the
requirement! I have worse descriptions. Catch me on IRC during a bug
hunt and I'll share some ;).<br>
    </div>
  </blockquote>
  <br>
I'd argue that some of those components are bad in part because of the
requirement.<br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
The fact is, if you cannot handle the additional work that underpins,
supports and ensures ease of maintenance for a component - then you are
begging for a developer to start swearing over IRC. I had the joy of
dealing with such a component a few weeks back. It took me hours to
figure out a bug. Why? Because the unit tests DID NOT TEST the
functionality of the component. I could have deleted every single test
with no ill effect - they were all busy with XML parsing or something
(performed by a completely different component with its own perfectly
functional unit tests).<br>
    </div>
  </blockquote>
That sounds about right.<br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
But worse than all this, is the assumption that lowering the
contribution overhead is a positive thing. It's not - it merely shifts
that work onto someone else. </div>
  </blockquote>
That assumes that a large amount of this work isn't optional -- when it
is. Those useless tests are there because someone said 'must have
tests', many, possibly most, of them are totally unneeded except to up
the code coverage report statistics. A minority of the ZFW tests do any
useful testing, and for those, I'm glad there's tests... and I believe
those tests would still be there if they weren't required to be.<br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Someone
else with precious little time and a chargeout rate to justify work
with. And surprise - they won't like that in the slightest. Sometimes
you get lucky - I spent about 10 hours of otherwise chargeable time in
September's bug hunt (which I enjoyed a lot by the way) along with
several evenings but generally everyday work will always lean towards
ignoring contributions where no supporting "contribution overhead" has
also been committed. Such contributions/patches/whatever can be
horrible to work on. No tests, poor explanations, lack of
communication, differing assumptions - ugh. If it's not worth
contributing in full, don't expect someone else to do it - they
probably won't.<br>
    </div>
  </blockquote>
I suspect many wont expect their contributions to be accepted -- and
instead of capitulating to the requirements, will simply abandon the
contribution.<br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
Sorry for the ranty piece - but code doesn't write itself. It is great
to have a contribution - so long as you don't pin it all on someone
else ;).<br>
    </div>
  </blockquote>
Pin what? When I developed the Zend PDF image parsers for example, I
didn't write any tests, I did functional testing to the best I
could.... and we went from there. Those classes exist in the framework
today in basically the same format. That contribution process was very
different from today, but it worked great. I'd hate to think what it
would take to get a class as complicated as
Zend_Pdf_Resource_Image_Tiff committed today....<br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
Which one? Nobody said there would be one front controller.</div>
  </blockquote>
For 99.999% of uses theres only one url, and only a need for one front
controller. <br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">My
guess, is that it will be accessible from your bootstrap, which is
registered to the front controller, which is registered to...I'm lost
now. </div>
  </blockquote>
I think you just made my point.<br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
Trace what under the hood?
Request-&gt;Route-&gt;Dispatch-&gt;Controller-&gt;Action &lt;- stick
plugins in between. It's not rocket science. </div>
  </blockquote>
Add into that Zend_Application-&gt;Zend_Config-&gt;Get Bootstrap Name
Setting-&gt;do whatever *secret sauce*-&gt;all before you get to the
mvc dispatch process above. Now, from the code source I looked at
before, its going to require creating some sort of methodinvokers,
event delegates and hooking into a series of events. Tracing back from
output to figure out where something is happening truly is a science
these days -- most of the time I end up pecking around in the leaves,
instead of tracing from the trunk. It gets even more complicated when
you start talking partials, helpers( think actionstack ), and the
myriad of other ways to inject into the request cycle. <br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">If
you doubled the complexity of the implementation today, it would still
quack like the same duck it was yesterday. </div>
  </blockquote>
We agree here. Today is too complicated... Tomorrow will be too
complicated... I was hoping with 2.0 that we would figure out where the
redundancies are and nix em --&gt; i'd start at the actionstack, but
thats just me. Now we're talking FSM's, and DI systems... which is cool
in a compsci kinda way, but fantastically complicated out of the box.<br>
  <br>
Is it a SDK, a black box, or are we helping people make applications
they understand? Whats the implication of blind use of the framework?<br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Right
now you can still conceptually grasp MVC and use it, without ever
reading the source code. In fact, right now MVC is a pretty complex
beast in ZF. It would take a serious effort to complicate it further :).<br>
    </div>
  </blockquote>
Theres a reason we write books on this stuff instead of user docs..... <br>
  <blockquote type="cite">
    <div
 style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
&gt;Can a skilled PHP developer contribute a change to the framework
easily<br>
&gt;without being involved in the ZFW core politics, contribution
processes,<br>
&gt;proposal processes, test writing, doc writing, etc.<br>
    <br>
ZF may be one of the few non-political projects around. I've had some
fun of course butting heads in the past, but the last two years have
been politics free. Everything else is answered "no". Who else is going
to miraculously write someone else's tests/docs/proposals? Not me :P.<br>
    </div>
  </blockquote>
"No" is a policy, and its not a very good one.<br>
  <br>
$0.02<br>
  <br>
Kevin<br>
  <meta http-equiv="x-dns-prefetch-control" content="on">
  </div>
  </div>
<!-- cg4.c902.mail.ac4.yahoo.com compressed/chunked Thu Nov 12 08:24:37 PST 2009 -->
  </div>
</blockquote>
<br>
</body>
</html>

--------------070008050704020105070401--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 18 Nov 2009 09:10:01 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend_json_Client or How to start contributing

-- Lars Kneschke <[email-masked]> wrote
(on Wednesday, 18 November 2009, 08:29 AM +0100):
> For our project Tine 2.0, we implemented Zend_Json_Client. It's modelled after
> Zend_XmlRpc_Client and I would like to contribute it.
> 
> I signed the CLA. That was easy. But now I'm searching for the best, to get in
> contact with right person to merge my work with the existsing Zend_Json_Server
> codbase.
> 
> The code is available at http://svn.tine20.org/svn/trunk/tine20/Zend/Json/ .
> 
> We also have extended Zend_Json_Server to handle batched request.
> 
> What is the right way to move forward on this issue?
> What is the right way to discuss the needed changes with the maintainer of
> Zend_Json?

For Zend_Json_Client, you will need to go through the proposal process;
information is available on the wiki:

    http://framework.zend.com/wiki/display/ZFPROP/Home

(I'm looking forward to this -- it's a component that's been on my
"todo" backlog for many, many months!)

As for the batched request support for Zend_Json_Server, the best way to
handle that is to add a feature request to the issue tracker
(http://framework.zend.com/issues), along with a patch that provides
both the new functionality as well as unit tests for it; bonus points if
you can provide documentation on it as well.

I'm the maintainer of Zend_Json, so ping me if you have questions or
suggestions on it.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 8 May 2009 01:57:12 +0200
From: till <[email-masked]>
To: Ryan Mauger <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Proposal to add validation and filtering to the
	getParam method of Zend_Controller_Request_Abstract

On Wed, Apr 15, 2009 at 10:36 PM, Ryan Mauger <[email-masked]> wrote:
> Good day to you all!
>
> After some discussion on IRC, there is now a proposal to update the
> getParam method in the Request object, to allow validation and filtering.
>
> Please comment the proposal =A0@
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Controller_Request+-+A=
dd+validation+and+filtering+to+getParam()

Hey Ryan,

interesting proposal. I remember 'wanting' something like that (even
opened an issue), but got turned down. So IMHO, please do follow
through and gather more support. ;-) I think this would be a valuable
addition.

Cheers,
Till

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>, <[email-masked]>
Date: Sat, 06 Feb 2010 13:05:15 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors] FW: [fw-general] Topics for Zend Framework
	conference (Russia, St. Petersburg). Lets discuss them!

Hey Georgy,

I see you are doing a talk on the ZendX jQuery integration. You should
make sure to check
out the current trunk, since it contains fixed to integrate the jQuery UI
1.8 Autocomplete
Widget. In this regard the requirements are bumped up to jQuery 1.4 + UI
1.8 in the next release.

greetings,
Benjamin

On Thu, 4 Feb 2010 16:08:09 -0800, "Alexander Veremyev"
<[email-masked]> wrote:
> Hi!
>=20
> First Russian ZF Conference is officially announced! :)
> http://devzone.zend.com/article/11781-1st-Russian-Zend-Framework-Confer=
e
> nce-Announced
>=20
> You are welcome to discuss conference topics and give your
> recommendations to speakers.
>=20
> Topics list and theses are available here as well as in the DevZone
> announce.
>=20
> With best regards,
>    Alexander Veremyev.
>=20
> -----Original Message-----
> From: Georgy Turevich [mailto:[email-masked]]=20
> Sent: Thursday, February 04, 2010 2:52 AM
> To: [email-masked]
> Subject: [fw-general] Topics for Zend Framework conference (Russia, St.
> Petersburg). Lets discuss them!
>=20
> Hello,
>=20
> ZF conference (ZFConf 2010) will take place in Saint Petersburg
> (Russia) at the end of March.
> I am one of this event's organizers so I would like to discuss the
> topics of the expected topics with you.
>=20
> Our speakers are deeply interested in your feedback. On its basis they
> can modify the content of their reviews.
>=20
> For russian developers which are not aware of the event yet:
> - http://www.zfconf.ru
> - additional discussions on topics are available at the forum:
> http://zendframework.ru/forum/index.php?topic=3D2281.0
>=20
>=20
> Here is the list of the expected topics (see the detailed theses for
> each of them below):
> - Proposal Lifecycle
> - Zend_Search_Lucene in the Details
> - Performance of Zend Framework Applications
> - Zend Framework and MVC, <Fat> Model
> - Fotostrana.ru: Prototyping Project with Zend Framework
> - Using Message Queues in Day-to-Day Projects (Zend_Queue)
> - Zend Framework and Doctrine
> - ZF and Multilingual
> - History of e-Shtab.ru
> - What News Zend Framework 2.0 Brings to Us?
> - jQuery and Dojo Toolkit JavaScript-frameworks Integration with Zend
> Framework
>=20
>=20
> =3D=3D=3D Proposal Lifecycle =3D=3D=3D
> Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)
>=20
> This presentation is intended to describe Zend Framework proposal
> lifecycle in details to give clear understanding of the steps required
> to get proposal included into ZF.
>=20
> It'll touch on proposal lifecycle actors, proposal lifecycle
> steps/proposal states, ZF repository areas created to support proposal
> process and other things.
> In addition to this some recommendations helping to promote your
> proposal quickly will be given.
>=20
>=20
> =3D=3D=3D Zend_Search_Lucene in the Details =3D=3D=3D
> Alexander Veremyev (Zend Technologies, Zend Framework Core Developer)
>=20
> Presentation gives a complete description of a Zend_Search_Lucene
> full-text search component usage.
>=20
> It's oriented to new Zend_Search_Lucene users as well as to experienced
> users.
>=20
> The following aspects will be described within presentation:
>=20
>     * history of component creation;
>     * component purpose;
>     * index format details (including factors affecting performance);
>     * indexing and indexing performance;
>     * searching using queries and query construction API;
>     * search results pagination.
>=20
> Presentation also describes techniques of improving searching
> performance for different modes of component usage.
>=20
>=20
> =3D=3D=3D Performance of Zend Framework Applications =3D=3D=3D
> Alexander Mahomet (ZendFramework.ru Community, Founder)
>=20
> The main goal of this report is to show how certain techniques can
> improve performance of applications that use Zend Framework. I will
> create demo application and will apply these techniques to it. Plan of
> report:
>=20
> Problem definition:
>=20
>     * Overview of demo application;
>     * Overview of testing environment;
>     * Overview of instruments for testing;
>     * Overview of parameters we should test, measurements before
> testing.
>=20
> Overview of techniques (after each item - new measurements):
>=20
>     * Methods which are not directly connect to Zend Framework
> (accelerators, setup of web server);
>     * Deleting of require* from Zend Framework;
>     * Joining of Zend Framework classes to one big file;
>     * Autoloading and Zend_Loader;
>     * Caching of objects (Zend_Config, Zend_Locale, Zend_Acl,
> Zend_Navigation), caching of pages and blocks, caching results of
> database queries, etc;
>     * Memcache;
>     * Recommendations from Zend Framework team;
>     * How Zend_Server can help building high-load applications.
>=20
> Comparison Zend Framework performance with other popular PHP frameworks=
.
>=20
>=20
> =3D=3D=3D Zend Framework and MVC, <Fat> Model =3D=3D=3D
> Alexander Steshenko (Norada Corporation, PHP programmer)
>=20
> 1. MVC pattern in details
>     * Controller, View
>     * Model is the application logic. Model isolation from other parts
> of MVC triad
> 2. MVC implementation in Zend Framework
>     * Zend_Controller_Action
>     * Zend_Controller_Front
>     * Zend_Controller_Dispatcher_Standard
>     * Zend_Controller_Action_Helper_ViewRenderer
>     * Zend_View
> 3. Thin / Fat Model
>     * What is thin Model, why it does not fit MVC pattern, code samples
>     * <Fat> model is every fragment of the application and the whole
> application itself
>     * Domain model
>     * Most often used data access patterns and approaches for modeling
> application objects
>     * Code samples
>     * Data access design patterns flexibility problems
>     * Benefits of Data Mapper - data access decomposition, easy
> refactoring of every part of the application
>     * Service layer, code samples
> 4. General tips and advices
>     * Automated testing
>     * ORM tool
>     * Good OOP, software design patterns
>=20
>=20
> =3D=3D=3D Fotostrana.ru: Prototyping Project with Zend Framework =3D=3D=
=3D
> Leonid Zhavoronkov (Fotostrana.ru, Teamlead)
>=20
> The history about Zend Framework usage in highload-project (12M hits,
> 200K hosts):
>     * Project's history and key features
>     * Choice of ZF as a platform for a startup: benefits and drawbacks
>     * Project's platform evolution
>     * The current architecture of the project and plans for the future
>=20
>=20
> =3D=3D=3D Using Message Queues in Day-to-Day Projects (Zend_Queue) =3D=3D=
=3D
> Denis Baklikov (Obnovlenie, Web Developer)
>=20
> 1. What is message queues?
>     * MQ history. JMS
>     * Advantages of using message queues
>     * Example usage of message queues. Bad examples
>     * Messaging patterns
> 2. Zend_Queue overview
>     * Interfaces overview
>     * Adapters overview
>     * Using different adapters. Best practices
>           o array
>           o db
>           o mq server
>     * Zend_Queue development. Next steps
> 3. MQ servers overview
>     * List of MQ serves (main idea: show people large number of
> servers they can use)
>     * Features of messaging servers (ActiveMQ, MemcacheQ, ...)
> 4. Projects using message queues
>     * Classic example - delayed emails sending
>     * Real time statistics processing
>     * Social networks. Image uploading example
>=20
>=20
> =3D=3D=3D Zend Framework and Doctrine =3D=3D=3D
> Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)
>=20
> 1. Connection of Doctrine to ZF project
>     * I will show the examples of code
>     * I will tell which options are responsible for what
> 2. Script for work with Doctrine_Cli
>     * I will show an example of work with Doctrine Cli
>     * I will tell how to create your task for Doctrine Cli
> 3. Generation models and mappers with yaml schemes. Inheritance.
> Migrations
>     * I will show the example of some simple circuits with binding and
> inheritance
>     * I will show our inputs for the models'autogeneration in modular
> application that correspond to standard coding of Zend Framework
> 4. Adapters for Zend_Paginator and Zend_Auth
>     * I will tell how to work and to show code
> 5. Caching of query results
>     * I will tell and show how to connect it and how to work with it
>=20
>=20
> =3D=3D=3D ZF and Multilingual =3D=3D=3D
> Stepan Tanasiychuk (Stfalcon.com Web Studio, Chief)
>=20
> 1. Adding language in the URL using a custome router (author -
> Konstantin Yurevich), a standard router and hostname router. Pluses
> and minuses of each approach
>     * I will show an examples of routers and examples of simple
> applications
>     * I will speak about pluses and minuses this routers in terms of SE=
O
> 2. Plugin or action helper to initialize translator
>     * I will show code examples
> 3. Why gettext? Nuances and hacks in the implementation of
> multilanguage through gettext
>     * I will show how convenient to add gettext through poedit and
> explain why I think other ways of localization inconvenient
>     * I will tell you that we do to translate validators messages
> 4. Caching
>     * I will show code examples
>=20
>=20
> =3D=3D=3D History of e-Shtab.ru =3D=3D=3D
> Anatoliy Larin (e-Legion, Web Developer)
>=20
> Architecture:
>     * Zend_Application, Zend_Config, Zend_Controller, Zend_Router
>     * MySQL, Zend_Db_Select, Zend_Db_Table, Zend_Db_Row
>       Table and Row have partly performed the Model role.
>     * Smarty
>       We gave up using PHTML because of its extreme flexibility,
> posibility to change the data right in the template.
>     * Zend_Feed, Zend_Pagination, Zend_Openid
> Problems:
>     * Smarty autoescaping
>       The programmers' forgetfulness became a problem, we missed out
> too many XSS holes.
>       The problem was solved via patching the Smarty by adding
> variables autoescaping functionality.
>     * Console jobs
>       Zend Framework does not provide instruments for creating console
> tasks (crontab, management tasks).
>     * A lot of problems related to character encodings
>     * Unintuitive URL-Router (upside-down)
>     * Error in long email subject in Russian
>       We had to spend a few days, to solve the issue.
>       http://framework.zend.com/issues/browse/ZF-1688
> (07.07.07-18.01.09)
>     * Notice, warning instead of Exceptions
>       At first we paid no attention to them, which led to bad
> consequences a few times.
>       As a result, we haven't elaborated correct coding style, which
> we got in other programming languages, where the bad-quality code is
> denied by compiler / interpreter.
>     * Reusability
>       Few parts of code we were able to use again without a pain.
>       A lot of things were created by copy'n'paste of existing code.
>=20
>=20
> =3D=3D=3D What News Zend Framework 2.0 Brings to Us? =3D=3D=3D
> Nadezhda Blinova (Wizartech, Web Programmer), Georgy Turevich
> (Wizartech, Lead Web Programmer)
>=20
> The following changes will be examined in the review:
>     * Architectural \ Design Changes
>     * MVC Implementation
>     * Plugin Architectures
>     * Other components (Zend_Acl, Zend_Controller,
> Zend_Controller_Router, Zend_Form, Zend_Session, Zend_Soap, Zend_View,
> Zend_Mail)
> In the course of the review preparation the latest details will be
> obtained from ZF developers.
>=20
>=20
> =3D=3D=3D jQuery and Dojo Toolkit JavaScript-frameworks Integration wit=
h
> Zend Framework =3D=3D=3D
> Georgy Turevich (Wizartech, Lead Web Programmer)
>=20
> During the presentation we will take a detailed look at different
> aspects of the integration and examine some examples:
> 1.  ZF + jQuery and ZF + Dojo Toolkit features overview
> 2. jQuery
>     * Setup jQuery Core and jQuery UI enviroments
>     * Automation work with jQuery UI-components
>     * Working with "autocompletion"
>     * Zend_Form customization with jQuery UI
>     * Looking to the future!
> 3.    Dojo Toolkit
>     * Setup Dojo-enviroment
>     * Automation with dijit's
>     * Working with "autocompletion"
>     * Zend_Form customization with Dijit
>     * Generation of data in specialized format (dojo.data)
>     * Automation Deployment Dojo Toolkit
>     * Looking to the future!
> 4. Several practical demontstrations
>=20
>=20
> Best Regards,
> Georgy Turevich

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Sun, 26 Jul 2009 11:35:36 +0200
Subject: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to ZendX
	Proposal

Hello Everyone,

i took the time today to look at the Problem of Zend_Service_Amazon. Due to an 
API upgrade the ZF component won't work anymore come August 15th. I just saw 
that the component uses the API from 2005, so its hopelessly out of date. I'll 
look into a possible fix, but i can't guarantee for this to work with the 2005 
API and i dont know how complex a migration to the latest 2009 API is.

This out of date problem is the case with most of the other Service components 
besides Twitter, S3 and EC2. Their code-base is mostly crap and they are all 
unmaintained.

I want to propose a change to ZFs handling of Service components. Since they 
all rely on third party API (through them having to rely on the stability of 
external webservices) they should all be moved into ZendX for 2.0. Also every 
new service component from now on should only be included in ZendX, with the 
exception of service integration being programmed from companies that have an 
agreement with Zend, such as the Infocard, Google and AMF components, where 
the stability and up-to-date API can be somewhat guaranteed.

greetings,
Benjamin

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 16 Jul 2009 17:00:57 +0100
From: Juozas <[email-masked]>
To: till <[email-masked]>
Cc: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend_Db_Adapter_Sqlsrv ready for review

--001485f19ac8f8ee25046ed4c661
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

component recently has been recently updated to pass all unit-tests.
However, since this is very technology-related component, we would like to
receive input on special cases, problems of Microsoft SQL.General
functionality works well and without a problems, but person with good
Microsoft SQL experience would really help.

Thanks for good words, hopefully it will be completed quite soon (proposal
was added after 99% of code and unit-tests were written :).

Juozas Kaziuk=C4=97nas

On Wed, Jul 15, 2009 at 3:41 PM, till <[email-masked]> wrote:

> Just want to second, Ralph.
>
> I do know a lot of people who will want to use this! :-)
>
> On Tue, Jul 14, 2009 at 5:39 PM, Ralph
> Schindler<[email-masked]> wrote:
> > This is an awesome addition for the windows devlopment environment.
> >
> > Nice work!
> > -ralph
> >
> > Rob Allen wrote:
> >>
> >> Hi all,
> >>
> >> Juozas and myself worked on an adapter for the MS SQL Server Driver fo=
r
> >> PHP during the euro-win-php competition. As this is a useful component
> for
> >> anyone working on Windows with SQL Server, we've created a proposal
> which is
> >> now ready for review:
> >>
> >>
> >>
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Adapter_Sqlsrv+-+Ju=
ozas+Kaziukenas+and+Rob+Allen
> >>
> >> There's also working source code at
> https://zfmssql.svn.codeplex.com/svn/
> >>
> >> We'd appreciate any and all comments on it :)
> >>
> >> Regards,
> >>
> >> Rob...
> >>
> >>
> >
>

--001485f19ac8f8ee25046ed4c661
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,<br><br>component recently has been recently updated to pass all
unit-tests. However, since this is very technology-related component,
we would like to receive input on special cases, problems of Microsoft
SQL.General functionality works well and without a problems, but person
with good Microsoft SQL experience would really help.<br>
<br>Thanks for good words, hopefully it will be completed quite soon
(proposal was added after 99% of code and unit-tests were written :).<br><b=
r>Juozas Kaziuk=C4=97nas<br><br><div class=3D"gmail_quote">On Wed, Jul 15, =
2009 at 3:41 PM, till <span dir=3D"ltr">&lt;<a href=3D"mailto:klimpong@gmai=
l.com">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Just want to seco=
nd, Ralph.<br>
<br>
I do know a lot of people who will want to use this! :-)<br>
<div><div></div><div class=3D"h5"><br>
On Tue, Jul 14, 2009 at 5:39 PM, Ralph<br>
Schindler&lt;<a href=3D"mailto:[email-masked]">ralph.schindler@ze=
nd.com</a>&gt; wrote:<br>
&gt; This is an awesome addition for the windows devlopment environment.<br=
&gt;<br>
&gt; Nice work!<br>
&gt; -ralph<br>
&gt;<br>
&gt; Rob Allen wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi all,<br>
&gt;&gt;<br>
&gt;&gt; Juozas and myself worked on an adapter for the MS SQL Server Drive=
r for<br>
&gt;&gt; PHP during the euro-win-php competition. As this is a useful compo=
nent for<br>
&gt;&gt; anyone working on Windows with SQL Server, we&#39;ve created a pro=
posal which is<br>
&gt;&gt; now ready for review:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_A=
dapter_Sqlsrv+-+Juozas+Kaziukenas+and+Rob+Allen" target=3D"_blank">http://f=
ramework.zend.com/wiki/display/ZFPROP/Zend_Db_Adapter_Sqlsrv+-+Juozas+Kaziu=
kenas+and+Rob+Allen</a><br>

&gt;&gt;<br>
&gt;&gt; There&#39;s also working source code at <a href=3D"https://zfmssql=
.svn.codeplex.com/svn/" target=3D"_blank">https://zfmssql.svn.codeplex.com/=
svn/</a><br>
&gt;&gt;<br>
&gt;&gt; We&#39;d appreciate any and all comments on it :)<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt;<br>
&gt;&gt; Rob...<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br>

--001485f19ac8f8ee25046ed4c661--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 16:39:47 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] [[email-masked]: Re: [zf-contributors]
	Proposal to update Abstract/Interface Naming Conventions]

Forwarding from Ben, who intended to copy the list...

----- Forwarded message from Benjamin Eberlei <[email-masked]> -----

From: Benjamin Eberlei <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>
Date: Fri, 10 Apr 2009 18:58:02 +0000
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

moving to this new namespace implementation and breaking all old ones is a
serious BC,
so why do we only allow slight changes for everything else? I thought we
would just go to "change the serious technical debt, but as BC as
possible", changing the name of an interface is the exact difference of
that.

additionally, the generic name one seems strange in my eyes. How would you
do that for
the example of request, response, dispatcher? Validation interface? i don't
seem to find good ones. ResponseObject, RequestObject, Validatable are ok,
but from the typehints its very hard to suggest that these are interfaces
in contrast to concrete implementation.

furthermore, why break with the ways of java, python, and .net? this is
what many programmers are used to.

As a last point, having implementation and interface in different packages
is actually the single most important issue about having an interface
anyways and a huge benefit for object oriented design. this separates the
concerns and reduces dependencies, so I would love to see this in a 2.0
version.

That is what i am greatly missing in ZF, that for example the controller is
implemented with several very large abstract classes only and the
dependencies are so hard-wired that its impossible to exchange just one
part of the controller to add specific functionality without having to
change considerable other parts also.

On Fri, 10 Apr 2009 14:24:34 -0400, Matthew Weier O'Phinney
<[email-masked]> wrote:
> Greetings, all --
> 
> Below is a proposal I am making to modify the Zend Framework Coding
> Standards conventions for the naming of Interfaces and Abstract classes.
> 
> This decision is basically already made, but I'd appreciate any feedback
> that you may have on the matter.
> 
> Thanks!
> 
> The problem
> ===========
> PHP 5.3 introduces namespaces to the PHP language. While this won't have
> an
> impact much on userland code, it will have an impact on library and
> framework
> code, as it provides a useful paradigm for organizing components as well
> as
> simplifying syntax. Instead of having to say things like:
> 
>     $analyzer = new
Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> 
> we can instead do something like this:
> 
>     namespace Zend\Search\Lucene\Analysis\Analyzer;
> 
>     $analyzer = new Common_TextNum();
> 
> or even:
> 
>     namespace Zend\Search\Lucene\Analysis\Analyzer;
> 
>     class Common_TextNum extends Common
>     {
>     }
> 
> The problem that arises for Zend Framework has to do with how we name
> abstract
> classes and interfaces. Currently, the final segment of such classes are
> expected to end with _Abstract and _Interface, respectively. This will
not
> work
> when we migrate to utilize namespaces, for two reasons.
> 
> First, and most obviously, 'abstract' and 'interface' are reserved PHP
> keywords.
> As such, in situations such as the following:
> 
>     namespace Zend\Controller\Request;
> 
>     class Abstract
>     {
>     }
> 
>     // or:
> 
>     namespace Zend\Controller\Dispatcher;
> 
>     interface Interface
>     {
>     }
> 
> we'll run into issues.
> 
> Second, and less obvious, is that perhaps the easiest solution breaks one
> of the
> key principles of namespaces (which are designed to help encapsulate
> components). This one's harder to explain, so let's look at examples.
> Consider a
> component such as Zend_Controller_Request. The simplest solution would be
> to
> name the abstract class or interface Zend\Controller\Request, and then
> have the
> various concrete implementations under that namespace:
> 
>     namespace Zend\Controller;
> 
>     interface Request
>     {
>     }
> 
>     // and concrete ones:
> 
>     namespace Zend\Controller\Request;
> 
>     class Http
>     {
>     }
> 
> What's the problem here? The interface is not in the same namespace as
the
> concrete implementations.
> 
> Potential solutions and recommendation
> ======================================
> So, how should Zend Framework "solve" these issues? A number of proposals
> and
> recommendations have been floated around, both within ZF circles and in
> the
> greater PHP community.
> 
> Considerations include:
> 
>  * Avoiding the use of PHP reserved keywords (already noted).
>  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
> name
>    describe its type -- which, to a degree, the current naming
conventions
>    already violate). (See
http://en.wikipedia.org/wiki/Hungarian_Notation,
> the
>    sections "Disadvantages of Systems Hungarian" and "Notable Opinions"
> for some
>    of the arguments against using Hungarian Notation.)
> 
> Approaches that have been considered include:
> 
>  * Using 'I' to prefix interfaces. This derives from standards in other
>    programming languages (.Net and python, in particular). This is just
> another
>    form of Hungarian Notation, however.
> 
>  * Using "Interface" or "Abstract" as a class name suffix:
> RequestInterface,
>    RequestAbstract. Again, however this is Hungarian Notation.
> 
>  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
> Base.
>    This is just substituting the word Base for Abstract, however, and is
> really
>    not much different than the above.
> 
>  * Use generic, descriptive names indicative of functionality or
behavior.
> As
>    examples from the SPL, "Countable", "Iterator", "ArrayObject".
> 
> My recommendation is to use the latter, as it solves all considerations.
> It will
> take more thought when naming, but will ensure that components can live
in
> a
> self-contained namespace, do not use reserved keywords, and avoid
> Hungarian
> Notation.
> 
> Plan for implementation
> =======================
> I recommend that the Coding Standards documentation be updated to reflect
> this
> approach.
> 
> All new components going into 1.8 and onwards should adopt these
> standards. In
> releases 1.9 and forward, we will begin migrating existing
> interfaces/abstract
> classe. First, new classes/interfaces will be created that follow these
> conventions and which extend the originals; later, any type-hinting based
> on the
> original class/interface names will be updated to point to the new names;
> and
> finally, in 2.0, we will remove the old interfaces/abstract classes
> entirely.
> 
> --
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/

----- End forwarded message -----

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Mon, 22 Mar 2010 15:27:13 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

We were planning to move Doctrine 2 development to Git also, however
one problem we saw was the alpha/beta-only git support for Jira, have
you evaluated the possibilities in this area?

On Mon, 22 Mar 2010 08:36:52 -0400, Matthew Weier O'Phinney
<[email-masked]> wrote:
> Greetings, all --
>=20
> Based on the wiki and the poll on this list, it looks like it makes
> sense to move forward with git. We're still trying to iron on some
> details about how this will work, but some details are falling into
> place.
>=20
> First, the things we plan:
>=20
>  * Git will be hosted on the ZF servers. This is so that we can have
>    full control over hooks (i.e., no network latency from web hooks),
>    integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
>    will offer both anonymous access as well as selective writable
>    access.
>=20
>    Some will say, "why not just use Github?" The above does not preclud=
e
>    using github in any way; git allows you to specify multiple remotes
>    from your repository. I already plan to have a mirror of my personal
>    repo on github, as well as push to the ZF repo from the same
>    location. This will allow people to use some of githubs powerful
>    features such as pull queues while still allowing us to retain some
>    control over the repository. (It also insulates us from githubs
>    growing pains a bit -- I love github, but they are certainly
>    suffering from rapid growth the last few months!)
>=20
>  * We plan to have a read-only subversion mirror of the git repository.
>    This will allow those using svn:externals to continue to do so, as
>    well as allow folks more familiar with svn to continue to provide
>    patches.
>=20
> Next, things we're still researching:
>=20
>  * How to handle contributions. Since we require a signed CLA, we need
>    some way of verifying that a patch came from an author who has signe=
d
>    the CLA. There have been some suggestions that this may be possible
>    with some sort of pre-commit verifications when committing to the
>    master repository (or when someone with commit privileges commits to
>    their own repository). We're still researching how this might be
>    implemented.
>=20
>  * Submodules...
>    For those unfamiliar with git submodules, they are roughly equivalen=
t
>    to svn:externals. I say "roughly", because they differ in many ways:
>    they have to be manually initialized on each person's repository
>    (though they can be defined in the master repository); they need to
>    be manually updated periodically (unlike svn:externals, where anytim=
e
>    you do an "svn up", it also syncs the external); etc.
>=20
>    They are quite powerful, however, and give us the ability to offer a
>    "lean" initial checkout, allowing developers to sync in only the
>    submodules they plan to utilize or commit to.
>=20
>    On this note, I've fielded a number of suggestions. Some were
>    suggesting the library directory be its own submodule, some suggeste=
d
>    all top-level directories be their own submodule, etc. I've done som=
e
>    experimentation, and now propose the following structure:
>=20
>     MAIN REPO:
>         INSTALL.txt
>         LICENSE.txt
>         README.txt
>         bin/
>         library
>         tests/
>         documentation/manual/
>             Makefile
>             README.txt
>             en/
>     SUBMODULES:
>         demos/
>         resources/
>         tools/
>         documentation/manual/:
>             all languages except "en"
>=20
>    Now, for an explanation of the "whys" behind this. As contributors,
>    it's important to make atomic commits: your code fix should also
>    include a corresponding unit test, and potentially a documentation
>    commit as well. If we split the library and tests directories out
>    into their own submodules, we cannot do so; the code and test must b=
e
>    committed separately, which is (a) more work, and (b) unintuitive.
>    The same goes for related documentation commits.
>=20
>    Translations, on the other hand, are usually managed in a
>    per-language capacity, flowing from English to the target language.
>    Most developers do not need the docbook source for anything but thei=
r
>    target language and English (the latter because it's used for
>    fallbacks, and because it contains the build scripts). While we
>    potentially lose the history of an "svn cp", I think this
>    organization provides reasonable benefits.
>=20
>    Finally, the demos, resources, and tools (the latter is a new
>    directory) are all "opt-in" items -- if you need them, you can pull
>    them in; if you don't, there's no reason to.
>=20
> I'd love to get some feedback on the incomplete items. I think the
> submodule layout I've come up with makes the most sense for contributor=
s
> (and based on testing, it's the cleanest and simplest way I've found to
> accomplish most common development tasks on our tree), but am open to
> further suggestions. If you have any ideas on handling ACLs, I'd love t=
o
> hear them, and sooner rather than later!

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Wed, 22 Apr 2009 11:44:30 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] 1.8 release branch

Hi all,

1.8 release branch is created.

So trunk is free for development.
But this also means, that all 1.8 features have to be merged into
branch. Don't forget it! :)

With best regards,
   Alexander Veremyev.

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 20 Mar 2009 14:02:25 -0700
From: "Wil Sinclair" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>, <[email-masked]>
Subject: RE: [zf-contributors] Release Policies and Conventions

OK, I changed it. There will inevitably be some hand-waving around what
is a new feature and what is a functionality enhancement. I'd rather
confine this thread to the issue of release policies and conventions. :)

New components pretty clearly fall under the category of 'new features'
in my mind. If others are confused, we should further clarify it.

,Wil

-----Original Message-----
From: Thomas Weidner [mailto:[email-masked]]=20
Sent: Friday, March 20, 2009 1:42 PM
To: Wil Sinclair; [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

Hy Wil,

"A mini release may contain only bug fixes. Note that no new features or
API=20
changes are allowed whatsoever."

This sentence could imply that new features are not allowed, but
improvments=20
of existing features are allowed as long as they don't change existing
API.=20
The word "only" could be overseen.

The question is also what's for us the difference between a feature=20
enhancement and a new feature.
Feature Enhancement could be for example to add a new option. It would
not=20
change API. So a textual clearification would be great :-)

Also to note: Are new components allowed within minor releases or only=20
within major releases? Should also be defined.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Wil Sinclair" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>;=20
<[email-masked]>
Sent: Friday, March 20, 2009 9:31 PM
Subject: RE: [zf-contributors] Release Policies and Conventions

Hey Thomas, I'm not quite sure what you are referring to. Your
understanding is correct, and the wiki page seems to reflect it
perfectly. Can you tell me exactly what needs to be updated? Maybe with
the string that you're referring to?

Thanks.
,Wil

-----Original Message-----
From: Thomas Weidner [mailto:[email-masked]]
Sent: Friday, March 20, 2009 12:57 PM
To: Wil Sinclair; [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

Hy Wil,

In my understanding also "feature enhancements" are actually not allowed
to
be integrated within mini-releases.
Only "Bug fixes" which do not add additional API are allowed.

Maybe you should also add a definition for what's a bug fix, a
improvement
and a new feature to get that also defined, and we can all speak of the
same
in future.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 20, 2009 8:47 PM
Subject: [zf-contributors] Release Policies and Conventions

Over the 2 years that I've been involved with the project, there have
been many questions about what can go in to a given release and if there
are any guidelines for the release schedules. While many of you have
pieced the picture together from different mails, IRC chats, etc. I've
owed you a document for a long time now. Here it is:

http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
tions

I ask all contributors to review this and reply with any question or
edits- especially if I missed something- in this forum.

As always, thanks for all the time and effort. Also, go 1.8!

,Wil

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 5 Feb 2010 18:59:36 +1100
From: Nigel Chapman <[email-masked]>
To: Zend Contributors List <[email-masked]>
Subject: [zf-contributors] New Proposal: Zend_Array

Hi All,  (? -- not sure how active this list is.)

Just a note to announce a new proposal:

Zend_Array is a fluent wrapper for PHP's array functions.

It lets you deal with arrays rather as you would in Ruby or JQuery,
with chained operators and closures.

Over the next few weeks, I'll be workign on the doc standards and test
suite, and thinking if it needs more (or less!) core methods.

Comments? Improvements?

* http://chapman.id.au/zend-array/

* http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman

I sometimes appear on #zftalk as kale77in.

Thanks,

Nigel.

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Cc: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
From: Simon R Jones <[email-masked]>
To: Juozas <[email-masked]>
Date: Mon, 7 Dec 2009 14:38:31 +0000
Subject: Re: [zf-contributors] Zend Framework modularity and application
	structure

hi Juozas,

my first post to this mailing list, but this topic is something I've  
been thinking a lot about recently in an effort to streamline our  
internal development at Studio 24.

At present we install ZF either in the doc root, or a sub-folder,  
depending on whether we need to mix the ZF app with an existing  
system. Simple projects will just have one modules folder for default  
+ admin, and possibly some custom module folders if the project needs  
to be split up. This is probably the most common ZF deployment model.

Recently we have a requirement to organise things better and install  
re-usable code from project to project. But re-usable code we can  
customise for each project, without messing with the original module  
itself.

The first step this took was admin modules, which map to /admin/module- 
name type URLs. This is achieved with two module folders, one called  
'modules' (normal ZF use) and one called 'admin-modules'.

Sample URLs may be:

Admin dashboard - http://www.example.com/admin/ - maps to app/admin- 
modules/default/
User management - http://www.example.com/admin/user/  - maps to app/ 
admin-modules/user/
CMS - http://www.example.com/admin/cms/ - maps to app/admin-modules/cms/

This is technically achieved by a new Zend_Application resource which  
sets up routes and autoloading. This helps create a more consistent  
experience for the user and have one admin system to manage multiple  
systems.

The second requirement we have is to have re-usable modules that we  
can install for a client, customise, and ideally upgrade in the future  
if we have a bug patch. The classic use case being user management.

To do this we have a library/modules/ folder. This has sub-folders  
which basically contain a full MVC app with the normal ZF folder  
structure. I.e. for user management this has library/modules/user

When used for a client site we SVN external the library/modules  
folders and treat this codebase as non-changeable (so we can update it  
in the future if we wished to). We then have some Zend_Application  
code which sorts out the autoloading and simply extend a few skeleton  
controllers in the normal app/modules/ folders to actually hook into  
the library module functionality.

So app/modules/user/controllers/LoginController.php will extend  
library/Modules/User/application/default/controllers/Login.php

We also have a view helper which looks in the library/modules folder  
first for views, then can be overridden by the local app/modules folder.

This idea of organised admin modules/URLs and extendable library  
modules is one we've struggled a little with recently but is very  
important to a web agency like us who develop a lot of common stuff  
for clients - and need to customise it on a project-by-project basis.  
Zend Framework has been good for us in many ways, it's just sometimes  
difficult working out the best way to achieve this kind of re-usable  
module setup.

I've been planning to write a blog post on this topic for a while, to  
get feedback from the community and see if anyone thinks this is an  
insane/good approach! I'd welcome any comments and would be happy to  
give any more feedback that may assist in ZF 2.0

best wishes,
Simon

-------------------------------------------------------------------
  Simon R Jones
  Managing Director
  Studio 24 Ltd
  e  [email-masked]
  t  0870 241 6159
  w  www.studio24.net

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Sun, 12 Jul 2009 13:26:27 +0200
Subject: [zf-contributors] Zend_Entity & Zend_Db_Mapper ready for
	recommendation

Hello everyone,

after a very long feedback phase from the community (and me having problems 
with time also) I finished lots of refactoring and API redesign on the Entity & 
Mapper components (which go hand in hand).

What I now ended up with is an API that somewhat follows the EJB 3.0 
specification, but has some PHP and Zend specific features to match. Details of 
the API are still not finished and further exploration might make me refactor 
the whole thing for the 100st time, but I think it is "finished enough" to go 
to ready for recommendation.

I updated the proposal a bit with more requirements and details in 
description. I also removed the large example and just point to the SVN where 
two integration test-cases are currently residing.

http://framework.zend.com/wiki/pages/viewpage.action?pageId=9437243

Furthermore I refactored alot in these last days and hope to get some 
additional feedback on the current API :-)

greetings,
Benjamin
-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Fri, 28 Aug 2009 08:41:25 +0200
Subject: Re: [zf-contributors] Discussions of the possible Query API in
	Zend_Entity

Helly Rafael,

good point, but in my opinion not compelling on second sight. Both ORMs are 
active record implementations.

Since yesterday propel is not being actively maintained anymore, so this will 
not necessarily be an option for large new projects anymore.

Doctrine is being completly rewritten for the 2.0 release, because they are 
unhappy with the current internals and everything, so although they clearly 
have the expertise the solution is not yet finished either.

As for a Zend ORM, the abstraction is already implemented. Its not on a very 
high level, so other implementations except RDBMS still have to go a long way, 
however they can make use of a range of data mapping utilities. The question 
of my post was, in which way do i make the differences in Query API between 
different storages explicit.

Personally i guess competition never hurts anyone. :-)

greetings,
Benjamin

On Friday 28 August 2009 01:34:54 am Rafael Dohms wrote:
> Guys,
>
> Just a quick notice and question.
>
> Isn't this an area where ORMs like Doctrine have already mastered
> solutions? aren't they rather easy to integrate into Zend Framework?
> Wouldnt it be easier to provide interaction points to doctrine, propel and
> others instead of bulging ZF with all stuff needed to fully abstract all
> databases and storage stuff.
>
> Sorry if this is waaay out of line, but its just seems to heavy an area to
> include.

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 12:00:15 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

-- Rob Allen <[email-masked]> wrote
(on Monday, 22 March 2010, 03:35 PM +0000):
> On 22 Mar 2010, at 02:44, Matthew Weier O'Phinney wrote:
> > -- Giorgio Sironi <[email-masked]> wrote
> > (on Sunday, 21 March 2010, 03:15 PM +0100):
> > > From the wiki guidelines I thought the direct() method would be
> > > enforced in the Zend_View_Helper_Interface.
> > 
> > Yes -- this is exactly the idea, and the reason we started defining
> > this. (Currently, however, we do not support it in any meaningful way.)
> > 
> > I'm trying to decide if "direct" (which suggests strategy) or
> > "execute" makes more sense for the method name.
> 
> execute() would be my preference. But for consistency with
> action_helpers, I can see the benefit of direct().

The irony of that is that the view helpers were refactored to follow the
action helpers. :)

Actually... this is likely all moot anyways: we've been discussing using
__invoke() for most plugins and helpers. :)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 22 Dec 2009 11:33:24 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] 1.10 release branch removed

I branched yesterday for the 1.10 alpha release, but this was never
intended to be a permanent branch; new features are still coming in. As
such, I've deleted it for now, until we branch for the beta; at that
time, the branch will become permanent.

Sorry for any confusion!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 19 Mar 2009 07:29:36 +0100
From: Tobias Gies <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [zf-contributors] Proper place to report incubator 
	issues/requests?

Hi A.J.,

as far as I know, the best place to do so is in the comments of the
proposal's wiki page.

http://framework.zend.com/wiki/display/ZFPROP/Zend_Queue+-+Justin+Plock#com=
ments

Best regards,
Tobias

2009/3/19 A.J. Brown <[email-masked]>:
> Hey guys,
>
> I have some requests I want to file for a component currently in the
> standard incubator (specifically Zend_Queue).=A0 Where's the place to do =
so?
> --
> A.J. Brown
> web | http://ajbrown.org
> phone | (937) 660-3969

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 13:53:40 -0400
From: "A.J. Brown" <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method 
	signatures

--0016364c7ed38888000481eead7c
Content-Type: text/plain; charset=ISO-8859-1

Again I'm in agreement here.  That's how all other namespaced languages
write their signatures, so why change that?

On Tue, Mar 16, 2010 at 7:59 AM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> -- Benjamin Eberlei <[email-masked]> wrote
> (on Tuesday, 16 March 2010, 11:25 AM +0100):
> > I disagree with FQN for other packages. Its very verbose and the
> importing
> > is pretty much why we want to port to namespaces in the first place.
>
> Well said -- +1.
>
> > My argument for importing all classes is easy: You have a central place
> > where all dependencies of a class are listed. This is a very powerful
> > concept to see classes that have too much dependencies or see what
> > dependencies are required at all.
>
> Exactly.
>
> > Plus IDEs make it easy to see where a class was imported from.
> >
> > greetings,
> > Benjamin
> >
> > On Tue, 16 Mar 2010 09:35:28 +0000, Rob Allen <[email-masked]> wrote:
> > > On 16 Mar 2010, at 06:26, Ralph Schindler wrote:
> > >>
> > >>
> > >> Should library/framework specific code be more expressive using fully
> > >> qualified names in method signatures and consequently in docblocks? Or
> > is
> > >> using unqualified names just as easy to understand and/or more
> > readable?
> > >
> > > I think that within a component, aliasing to the component should be
> > used
> > > as you know where you are. If other components are used, then fully
> > > qualified names should be used for clarity.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

-- 
A.J. Brown
Software Engineer, ZCE
blog : http://ajbrown.org
talk  : (937) 540-0099
chat : IntypicaAJ

--0016364c7ed38888000481eead7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Again I&#39;m in agreement here.=A0 That&#39;s how all other namespaced lan=
guages write their signatures, so why change that?<br><br><br><div class=3D=
"gmail_quote">On Tue, Mar 16, 2010 at 7:59 AM, Matthew Weier O&#39;Phinney =
<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">-- Benjamin Eberl=
ei &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; w=
rote<br>

(on Tuesday, 16 March 2010, 11:25 AM +0100):<br>
<div class=3D"im">&gt; I disagree with FQN for other packages. Its very ver=
bose and the importing<br>
&gt; is pretty much why we want to port to namespaces in the first place.<b=
r>
<br>
</div>Well said -- +1.<br>
<div class=3D"im"><br>
&gt; My argument for importing all classes is easy: You have a central plac=
e<br>
&gt; where all dependencies of a class are listed. This is a very powerful<=
br>
&gt; concept to see classes that have too much dependencies or see what<br>
&gt; dependencies are required at all.<br>
<br>
</div>Exactly.<br>
<div><div></div><div class=3D"h5"><br>
&gt; Plus IDEs make it easy to see where a class was imported from.<br>
&gt;<br>
&gt; greetings,<br>
&gt; Benjamin<br>
&gt;<br>
&gt; On Tue, 16 Mar 2010 09:35:28 +0000, Rob Allen &lt;<a href=3D"mailto:ro=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; &gt; On 16 Mar 2010, at 06:26, Ralph Schindler wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Should library/framework specific code be more expressive usi=
ng fully<br>
&gt; &gt;&gt; qualified names in method signatures and consequently in docb=
locks? Or<br>
&gt; is<br>
&gt; &gt;&gt; using unqualified names just as easy to understand and/or mor=
e<br>
&gt; readable?<br>
&gt; &gt;<br>
&gt; &gt; I think that within a component, aliasing to the component should=
 be<br>
&gt; used<br>
&gt; &gt; as you know where you are. If other components are used, then ful=
ly<br>
&gt; &gt; qualified names should be used for clarity.<br>
<br>
</div></div><font color=3D"#888888">--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"mailto:[email-masked]">m=
[email-masked]</a><br>
Zend Framework =A0 =A0 =A0 =A0 =A0| <a href=3D"http://framework.zend.com/" =
target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>A.J. Brown<br>So=
ftware Engineer, ZCE<br>blog : <a href=3D"http://ajbrown.org">http://ajbrow=
n.org</a><br>talk =A0: (937) 540-0099<br>chat : IntypicaAJ<br>

--0016364c7ed38888000481eead7c--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 28 Jul 2009 07:32:15 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Contributor list

-- P=C3=A1draic Brady <[email-masked]> wrote
(on Tuesday, 28 July 2009, 04:05 AM -0700):
> Just a reference to something I edited while adding myself since I'm un=
clear on
> how it should be handled. In components with muliple parts (for example
> Zend_Feed also hosts the completely independent Zend_Feed_Reader) we ma=
y not
> have a single lead. In that case was it okay for me to add Zend_Feed_Re=
ader as
> a separate entry on the table? Easily reversed if not :).

Absolutely. I actually created a separate component within JIRA for
Zend_Feed_Reader as well, as it's clear these are two independent
components.

> =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=
> From: Thomas Weidner <[email-masked]>
> To: [email-masked]
> Sent: Tuesday, July 28, 2009 8:12:05 AM
> Subject: Re: [zf-contributors] Contributor list
>=20
> Like for all other pages within our wiki you need to login.
> It's the same process as if you edit one of your proposals.
>=20
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>=20
> ----- Original Message ----- From: "Daniel Lo" <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>
> Sent: Tuesday, July 28, 2009 8:00 AM
> Subject: Re: [zf-contributors] Contributor list
>=20
>=20
> Hello Thomas,
>=20
> How do we edit this page? or do we turn in this information to you pers=
onally?
>=20
> -daniel
>=20
> Jira: danlo
>=20
> Monday, July 27, 2009, 8:25:10 AM, you wrote:
>=20
> > Hy all,
>=20
> > we have since several months a contributor list.
> > http://framework.zend.com/wiki/pages/viewpage.action?pageId=3D11036
>=20
> > Now for 1.9 it's time again to update this list.
> > Every contributor/maintainer/component lead is announced to update th=
is list
> > with his own informations within the proper component.
>=20
> > Greetings
> > Thomas Weidner, I18N Team Leader, Zend Framework
> > http://www.thomasweidner.com
>=20
>=20
>=20
>=20
> -- Best regards,
> Daniel                            mailto:[email-masked]

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 26 Sep 2009 15:41:29 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] IMPORTANT: svn read-only and developer tools
	down tonight

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Friday, 25 September 2009, 10:20 AM -0400):
> Our hosting provider is relocating our servers to a different facility
> this evening, starting at 16:00 PDT. While we have arranged for a backup
> server, we feel it would be safest during the transition if we:
> 
>  * mark SVN read-only
>  * take down the developer tools (wiki, issue tracker, fisheye)
> 
> As such, I will be taking the above steps at 13:00 PDT today. They will
> be down for 12-15 hours.
> 
> I will send an email when each transition occurs (taking them down,
> bringing them back up).

DNS has been switched back over and should be propagating any moment now
for most users. SVN is now re-opened, as are the developer tools.

Thanks everyone for your patience!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 13 Apr 2009 08:49:06 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

I'm going to break a couple of rules here: I'm replying to my own email,
as well as top-posting. Bear with me...

Robin S. raised an interesting point that Matt R. picked up and agreed
with:

    I also notice that namespaces are written in Uppercase\Notation --
    Zend\Controller\Request. Will this be the standard? Another
    alternative is zend\controller\Request, which clearly distinguishes
    what's the namespace and what's the class/interface.

Additionally, it seems the primary push-back is with abstract class
naming, particularly when there are also interfaces defined in the same
namespace.

After reading these responses, I reached out to some friends in the PEAR
community, some of whom I've spoken with before about these issues. "Why
PEAR?" some may ask. ZF standards are based on PEAR standards. One goal
since the beginning of the ZF project has been to promote
interoperability with established standards. PEAR CS are the "gold
standard" in the PHP community, and whether you like or agree with them
or not, they are used widely.

The PEAR Group has been debating new standards to adopt for PEAR2 for
some time now. PEAR2 is targeting a minimum required version of PHP 5.3,
so they are addressing the very same issues we're discussing. They have
also basically reached consensus, though they have not formally adopted
the new standards yet. When it comes to namespaces and class naming, it
is the ZF team's opinion that we need to be as close to PEAR standards
as possible.

The relevant documents are here:

    http://wiki.php.net/pear/rfc/pear2_class_naming
    http://wiki.php.net/pear/rfc/pear2_naming_standards

In a nutshell, here's what they define:

 * Namespaces are lowercase: zend\codegenerator\php
 * Class names are MixedCase: zend\codegenerator\php\File
 * Namespaces may contain underscores, but they do not translate to the
   directory separator
 * Class names may contain underscores, and they *do* translate to the
   directory separator
 * Interfaces should be named descriptively, and not contain the word
   "Interface" or the sigil "I".
 * It is preferred that Abstract classes are also named descriptively,
   but *may* contain the *suffix* Abstract.

There are some good arguments for each point in the linked RFCs.

I think that adopting these standards addresses most concerns the ZF
team has, as well as many if not most concerns posted in this thread. 

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Friday, 10 April 2009, 02:24 PM -0400):
> Greetings, all --
> 
> Below is a proposal I am making to modify the Zend Framework Coding
> Standards conventions for the naming of Interfaces and Abstract classes.
> 
> This decision is basically already made, but I'd appreciate any feedback
> that you may have on the matter.
> 
> Thanks!
> 
> The problem
> ===========
> PHP 5.3 introduces namespaces to the PHP language. While this won't have an
> impact much on userland code, it will have an impact on library and framework
> code, as it provides a useful paradigm for organizing components as well as
> simplifying syntax. Instead of having to say things like:
> 
>     $analyzer = new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> 
> we can instead do something like this:
> 
>     namespace Zend\Search\Lucene\Analysis\Analyzer;
> 
>     $analyzer = new Common_TextNum();
> 
> or even:
> 
>     namespace Zend\Search\Lucene\Analysis\Analyzer;
> 
>     class Common_TextNum extends Common
>     {
>     }
> 
> The problem that arises for Zend Framework has to do with how we name abstract
> classes and interfaces. Currently, the final segment of such classes are
> expected to end with _Abstract and _Interface, respectively. This will not work
> when we migrate to utilize namespaces, for two reasons.
> 
> First, and most obviously, 'abstract' and 'interface' are reserved PHP keywords.
> As such, in situations such as the following:
> 
>     namespace Zend\Controller\Request;
> 
>     class Abstract
>     {
>     }
> 
>     // or:
> 
>     namespace Zend\Controller\Dispatcher;
> 
>     interface Interface
>     {
>     }
> 
> we'll run into issues.
> 
> Second, and less obvious, is that perhaps the easiest solution breaks one of the
> key principles of namespaces (which are designed to help encapsulate
> components). This one's harder to explain, so let's look at examples. Consider a
> component such as Zend_Controller_Request. The simplest solution would be to
> name the abstract class or interface Zend\Controller\Request, and then have the
> various concrete implementations under that namespace:
> 
>     namespace Zend\Controller;
> 
>     interface Request
>     {
>     }
> 
>     // and concrete ones:
> 
>     namespace Zend\Controller\Request;
> 
>     class Http
>     {
>     }
> 
> What's the problem here? The interface is not in the same namespace as the
> concrete implementations.
> 
> Potential solutions and recommendation
> ======================================
> So, how should Zend Framework "solve" these issues? A number of proposals and
> recommendations have been floated around, both within ZF circles and in the
> greater PHP community. 
> 
> Considerations include:
> 
>  * Avoiding the use of PHP reserved keywords (already noted).
>  * Avoiding Hungarian Notation (i.e., having the name or a portion of the name
>    describe its type -- which, to a degree, the current naming conventions
>    already violate). (See http://en.wikipedia.org/wiki/Hungarian_Notation, the
>    sections "Disadvantages of Systems Hungarian" and "Notable Opinions" for some
>    of the arguments against using Hungarian Notation.)
> 
> Approaches that have been considered include:
> 
>  * Using 'I' to prefix interfaces. This derives from standards in other
>    programming languages (.Net and python, in particular). This is just another
>    form of Hungarian Notation, however.
> 
>  * Using "Interface" or "Abstract" as a class name suffix: RequestInterface,
>    RequestAbstract. Again, however this is Hungarian Notation.
> 
>  * Using the term "Base" for abstract classes: BaseRequest, RequestBase, Base.
>    This is just substituting the word Base for Abstract, however, and is really
>    not much different than the above.
> 
>  * Use generic, descriptive names indicative of functionality or behavior. As
>    examples from the SPL, "Countable", "Iterator", "ArrayObject".  
>    
> My recommendation is to use the latter, as it solves all considerations. It will
> take more thought when naming, but will ensure that components can live in a
> self-contained namespace, do not use reserved keywords, and avoid Hungarian
> Notation.
> 
> Plan for implementation
> =======================
> I recommend that the Coding Standards documentation be updated to reflect this
> approach. 
> 
> All new components going into 1.8 and onwards should adopt these standards. In
> releases 1.9 and forward, we will begin migrating existing interfaces/abstract
> classe. First, new classes/interfaces will be created that follow these
> conventions and which extend the originals; later, any type-hinting based on the
> original class/interface names will be updated to point to the new names; and
> finally, in 2.0, we will remove the old interfaces/abstract classes entirely.
> 
> -- 
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/
> 

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Ashley Broadley <[email-masked]>
To: Vincent de Lau <[email-masked]>
Date: Thu, 25 Feb 2010 08:08:55 +0000
Cc: "<[email-masked]>" <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

It's great to know that 2.0 is starting to get on its way. And with  
this version I plan on becoming a lot more involved in contributing.

A few thoughts on Doctrine Integration:

In my opinion if Doctrine integration is to be left until ZF 2.0, then  
the integrated version of Doctrine should be the 2.0 version. Since  
both 2.0 versions will require PHP 5.3.

This would allow both languages to take advantage of the new PHP  
features, and keep things simpler with the use of namespaces.

If there was to be an integration with Doctrine 1.2, then I would  
recommend that it be released under the 1.X branch of ZF.

Doctrine 2 is already at the alpha4 stage, meaning that it has  
undergone quite a lot of development. This could also mean that the  
final release is also ready before the first release of ZF2.x.

Kind regards
Ashley Broadley

On 24 Feb 2010, at 23:57, "Vincent de Lau" <[email-masked]> wrote:

>> -----Original Message-----
>> From: Matthew Weier O'Phinney [mailto:[email-masked]]
>> Sent: Thursday, February 25, 2010 12:06 AM
>>
>> Those of you paying attention to the SVN commits will have noticed  
>> that
>> I just created a new branch, development-2.0. This is a new branch
>> intended for development of ZF 2.0.
>
> <snip>
>
>> For the initial development, I'm trying to (a) gauge what works, and
>> (b)
>> get a good sense for the amount of work ahead, so I can estimate a
>> release date. This latter will help determine if we should release a
>> 1.11 release with new features between now and 2.0, or go straight to
>> 2.0.
>
>
> Hooray! Good to hear that the first steps are taken. I was wondering  
> about
> the current state of things.
>
> You are also mentioning 1.11, so I'll take to opportunity to ask:  
> What are
> the plans for Doctrine integration?
>
> I can imagine a 1.11 being published with Doctrine 1.2 integration,  
> but I
> would also understand if this has to wait for ZF 2.0, maybe even with
> Doctrine 2.
>
> The reason I'm asking is because I'm planning some refactoring of  
> existing
> code based on ZF 1.7 and 1.9. I'm also planning to start using  
> Doctrine.
> I've got a couple of options (on order of preference):
> - wait for a ZF 1 version with Doctrine integration
> - use 1.10 for now and wait with Doctrine until ZF 2.0 is released
> - use 1.10 and do a custom Doctrine integration
>
> I can understand that you don't have the definitive answer ready yet  
> (see
> point b), but I'll take any indication.
>
> Thanks,
>
> Vincent de Lau
>

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 21 Sep 2009 20:38:59 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.9.3 sanity check packages

Sanity check packages for Zend Framework 1.9.3 are now available, and at
the following locations:

  Full packages:
    tarball: http://framework.zend.com/releases/preview/ZendFramework-1.9.3/ZendFramework-1.9.3.tar.gz
    zip:     http://framework.zend.com/releases/preview/ZendFramework-1.9.3/ZendFramework-1.9.3.zip

  Minimal packages:
    tarball: http://framework.zend.com/releases/preview/ZendFramework-1.9.3/ZendFramework-1.9.3-minimal.tar.gz
    zip:     http://framework.zend.com/releases/preview/ZendFramework-1.9.3/ZendFramework-1.9.3-minimal.zip

Please test the packages, and let myself, Alex, or Ralph know ASAP if
you identify any show stopper issues.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 25 Oct 2009 13:53:50 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code Freeze for 1.9.5 today

Hey, all --

Forgot to send an announcement earlier, but code freeze for 1.9.5 starts
at midnight PDT this evening; get your changesets merged in before then
if you want them included in the upcoming maintenance release.

Assuming all goes well, 1.9.5 will release this Tuesda, the 27th of
October. I will send an announcement when code freeze is lifted.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 23 Mar 2010 06:46:19 -0700
From: Matthew Ratzloff <[email-masked]>
To: Sascha-Oliver Prolic <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

Oh, that's a good point.  I forgot about that new magic method.  +1

-Matt

On Monday, March 22, 2010, Sascha-Oliver Prolic
<[email-masked]> wrote:
> Hi all,
>
> As view helpers are neither strategy nor command, I prefer the use of
> the "__invoke" method, instead of "execute" or "direct". This will
> also give a much smoother interface.
>
> --
> Sascha-Oliver Prolic
> Intelligent Web Services Ltd.
>

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 5 Feb 2010 11:30:21 -0600
From: Shawn Stratton <[email-masked]>
To: Nigel Chapman <[email-masked]>
Cc: Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

--000e0cd6ae48de1826047eddce4f
Content-Type: text/plain; charset=ISO-8859-1

Not to knock on the importance of what you're trying to do but wouldn't that
really be a language level issue that should be handled in SPL or at least
at the C level via Pecl?

On Feb 5, 2010 1:59 AM, "Nigel Chapman" <[email-masked]> wrote:

Hi All,  (? -- not sure how active this list is.)

Just a note to announce a new proposal:

Zend_Array is a fluent wrapper for PHP's array functions.

It lets you deal with arrays rather as you would in Ruby or JQuery,
with chained operators and closures.

Over the next few weeks, I'll be workign on the doc standards and test
suite, and thinking if it needs more (or less!) core methods.

Comments? Improvements?

* http://chapman.id.au/zend-array/

* http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman

I sometimes appear on #zftalk as kale77in.

Thanks,

Nigel.

--000e0cd6ae48de1826047eddce4f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Not to knock on the importance of what you&#39;re trying to do but would=
n&#39;t that really be a language level issue that should be handled in SPL=
 or at least at the C level via Pecl?</p>
<p><blockquote type=3D"cite">On Feb 5, 2010 1:59 AM, &quot;Nigel Chapman&qu=
ot; &lt;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a>&gt; wrote:<br><br>Hi All, =A0(? -- not sure how active this list is.)<b=
r>

<br>
Just a note to announce a new proposal:<br>
<br>
Zend_Array is a fluent wrapper for PHP&#39;s array functions.<br>
<br>
It lets you deal with arrays rather as you would in Ruby or JQuery,<br>
with chained operators and closures.<br>
<br>
Over the next few weeks, I&#39;ll be workign on the doc standards and test<=
br>
suite, and thinking if it needs more (or less!) core methods.<br>
<br>
Comments? Improvements?<br>
<br>
* <a href=3D"http://chapman.id.au/zend-array/" target=3D"_blank">http://cha=
pman.id.au/zend-array/</a><br>
<br>
* <a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nig=
el+Chapman" target=3D"_blank">http://framework.zend.com/wiki/display/ZFPROP=
/Zend_Array+-+Nigel+Chapman</a><br>
<br>
I sometimes appear on #zftalk as kale77in.<br>
<br>
Thanks,<br>
<font color=3D"#888888"><br>
Nigel.<br>
</font></blockquote></p>

--000e0cd6ae48de1826047eddce4f--

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 24 Aug 2009 22:59:22 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.9.2 sanity check packages

Greetings!

We have packaged ZF 1.9.2, and plan to release tomorrow (Tuesday)
mid-afternoon EDT. There have been a stellar number of issues resolved
for this release, and I'd like to thank all of you for chipping in!

You can test the packages here:

    http://framework.zend.com/releases/preview/ZendFramework-1.9.2/ZendFramework-1.9.2.tar.gz
    http://framework.zend.com/releases/preview/ZendFramework-1.9.2/ZendFramework-1.9.2-minimal.tar.gz
    http://framework.zend.com/releases/preview/ZendFramework-1.9.2/ZendFramework-1.9.2.zip
    http://framework.zend.com/releases/preview/ZendFramework-1.9.2/ZendFramework-1.9.2-minimal.zip

Please let myself, Alex, or Ralph know ASAP if you see any show
stoppers.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 15:48:57 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

-- Graham Anderson <[email-masked]> wrote
(on Thursday, 25 February 2010, 08:54 PM +0100):
> On Thursday 25 February 2010 17:44:54 Luke Crouch wrote:
> > Maybe I'm turning into a crotchety old programmer, but I'm not really
> > impressed with git. We switched from svn to git at my day job and I
> > haven't really seen any big benefits aside from a few sweet syntactic
> > shortcuts like git stash. For larger projects with well-organized
> > branching I just haven't seen much additional value from git.
> 
> I think if I was working in house with a centralised core of programmers, 
> there is a compelling argument to perhaps stay with SVN. You can enforce 
> practices in the organisation and you can deploy a common set of tools. SVN 
> access is much easier to manage.
> 
> ZF on the other hand is already a distributed project and Git's work-flow and 
> utilities are very well matched. The cheap branching and merging is in it's 
> own right reason enough to switch, in my opinion; but there are many other 
> aspects to Git that make it better for ZF's needs.

I've been using git+svn for around 18 months now, and the cheap
branching and ease of merging are what keep me using the combo.

As an example, earlier this week I was working on several different bug
fixes at once, and waiting for some from other contributors that
affected what I was working on. 

I branched locally for the code that needed collaboration, did my bits,
and then returned to my master branch. I then branched again to work on
another fix, got interrupted, checked out the collaboration branch,
merged in some changes, finished up, pushed, went back to my other
bugfix branch, finished up...

This would have been next to impossible to do cleanly with svn.

Other times, I've been working on something, and needed to put it aside for
awhile. "git stash" to the rescue -- stashed my changes, worked on trunk
for a bit, and then "git stash pop" to restore my work. Again, basically
impossible with svn.

> Remote tracking of multiple branches on multiple repo's combined with cheap 
> and easy merging is a killer feature. Not only does it make a maintainers life 
> a ton easier, it makes collaboration very much easier than SVN too, one of the 
> reasons GitHub/Gitorius are so successful... 

One thing I'd never quite understood with git was the multiple remotes
bit, until I saw a talk by Scott Chacon at symfony live last week. And
suddenly it clicked. You give a handful of people write access to the
main repository, and this is what everyone tracks. People clone it, and
then issue a pull request to a release master. The release master can
track multiple repos from multiple collaborators, and then selectively
merge into their own "master" -- and push those patches into the
mainline.

Best of all, git keeps track of the original source, unlike when I merge
people's code from incubator to trunk today. :)

> Sure, I'm passionate about Git but it's because it has helped me
> become more productive, and to me that is utter invaluable. I want ZF
> to switch to Git not because I think it's the better tool or because
> it's not SVN, I want ZF to switch to Git because I believe ZF as a
> project and anyone who uses ZF will benefit more so than staying with
> SVN.

Well-stated, sir. 

My personal preference is to use Git -- mainly because I think it will
give us more flexibility in organizing the project's processes, and
because I think it will lead to more democratic development.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 1 Mar 2010 11:23:12 +0100
From: Julien Pauli <[email-masked]>
To: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

+1 for PEAR channel

J.Pauli

On Fri, Feb 26, 2010 at 11:22 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Renan de Lima <[email-masked]> wrote
> (on Friday, 26 February 2010, 06:46 PM -0300):
>> About package dependencies...
>> I think it could be nice if we should prepare it for 2 (or more)
>> levels of dependency (or relashionship):
>> =A0 =A0 1 - strong, some package that does not work without other
>> (example: Zend\Soap and Zend\Server)
>> =A0 =A0 2 - weak, when the dependency is just a suggestion (example:
>> Zend\Auth and Zend\Db)
>>
>> For end-users we could provide a download picker as well, like this:
>> http://phpjs.org/packages/configure
>
> Actually, the above will be addressed by creating PEAR packages, as we
> can then specify optional dependencies, or create bundles.
>
> We do plan to offer a PEAR channel with per-component downloads for 2.0,
> as this will make cherry-picking easier, and also provide an easier path
> for integrating with other frameworks (the symfony CLI tool, for
> instance, can install 3rd party code by proxying to PEAR, and this is
> just one such example).
>
>> On 26 February 2010 10:59, Matthew Weier O'Phinney <[email-masked]> wr=
ote:
>> > Hey, all --
>> >
>> > This is the first in a series of emails I'll be posting to this list
>> > with status updates on 2.0. I plan to do these several times a week
>> > throughout the process.
>> >
>> > Since branching 2.0 a couple days ago, I've been busy working on
>> > stripping require_once calls from the ZF library.
>> >
>> > My initial idea was to simply run the same find/sed script from the
>> > performance guide, but quickly discarded this for two reasons:
>> >
>> > =A0* It only comments out those lines. Yes, it can be modified to remo=
ve
>> > =A0 the lines as well, but this does not address other concerns such a=
s
>> > =A0 preceding docblocks.
>> >
>> > =A0* To package individual components, we need some way to determine
>> > =A0 dependencies. Currently, require_once statements can help with tha=
t,
>> > =A0 but stripping them makes this harder. My solution is to add @uses
>> > =A0 annotations at the class docblock level. This assists the API docs=
,
>> > =A0 but also should make it possible to use automated scanners to
>> > =A0 determine dependencies.
>> >
>> > To accomodate these concerns, the process has to be manual. I've
>> > currently completed the top-level classes, and all components through
>> > Zend_Config. I'm committing to a local git branch incrementally, and
>> > will be pushing a squashed commit to the development-2.0 branch once
>> > complete.
>> >
>> > --
>> > Matthew Weier O'Phinney
>> > Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
>> > Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>> >
>>
>> --
>> Renan de Lima Barbosa
>> gtalk/msn: [email-masked]
>> skype: renandelima
>> +55 61 8166-7755
>> renandelima.com
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

nFrom nobody Wed Apr  7 08:46:16 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 15 Jan 2010 00:32:56 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] 1.10 has been branched!

oh sorry - forget this - i see it is already done
my mistake

Am 15.01.2010 00:27, schrieb Marc Bennewitz:
> Great :)
>
> Can you add the new components of 1.10 on issue tracker and move the
> incubator components to Zend Framework project please.
>
> Greetings
> Marc B.
>
> Am 14.01.2010 22:55, schrieb Matthew Weier O'Phinney:
>   
>> Greetings, all!
>>
>> I've just created the official 1.10 branch, and will be tagging the beta
>> off of this branch momentarily.
>>
>> >From this point forward, no API changes are allowed in the release-1.10
>> branch -- but DO please assist in fixing bugs, translating, etc.!
>>
>> Thanks!
>>
>>   
>>     

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Tue, 16 Mar 2010 11:25:46 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

I disagree with FQN for other packages. Its very verbose and the importin=
g
is pretty much why we want to port to namespaces in the first place.

My argument for importing all classes is easy: You have a central place
where all dependencies of a class are listed. This is a very powerful
concept to see classes that have too much dependencies or see what
dependencies are required at all.

Plus IDEs make it easy to see where a class was imported from.

greetings,
Benjamin

On Tue, 16 Mar 2010 09:35:28 +0000, Rob Allen <[email-masked]> wrote:
> On 16 Mar 2010, at 06:26, Ralph Schindler wrote:
>>=20
>>=20
>> Should library/framework specific code be more expressive using fully
>> qualified names in method signatures and consequently in docblocks? Or
is
>> using unqualified names just as easy to understand and/or more
readable?
>=20
> I think that within a component, aliasing to the component should be
used
> as you know where you are. If other components are used, then fully
> qualified names should be used for clarity.
>=20
> Regards,
>=20
> Rob...

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 7 Dec 2009 09:25:12 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Nico Edtinger <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] XSS And Malformed HTML Vulnerabilities In
	Zend_Filter_StripTags

--0-646074440-1260206712=:76776
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I just deleted my last response to this list and will leave folk with this =
somewhat bitter note.=0A=0AI did not report a security vulnerability on my =
blog. I revealed a potential avenue of misuse by end-users. On Twitter this=
 has been challenged despite three very obvious clarifications I intentiona=
lly added to that blog entry to dispel any appearance the ZF was at fault.=
=0A=0AIn subsequent discussions, I became convinced this was...slightly...m=
ore serious. I cannot anticipate the changing currents of my mind, and with=
out the blog post and subsequent discussions with members of the community,=
 I may never have changed my mind. You may never have heard of these issues=
.=0A=0ABut I did change my mind. By then the blog post was out for over a d=
ay, and withdrawing it out of concern for public disclosure was not an opti=
on. My blog is syndicated - it was all over Google within mere hours.=0A=0A=
I also inflicted on Nico Edtinger a response on this list that was undeserv=
ed, full of outrage, and wholly unnecessary. Nico - I apologise. It was stu=
pendously stupid of me to have allowed that email go out.=0A=0AI do however=
 retain the right to change my mind. I retain the write about things of int=
erest to just about anybody. I do not regret doing so. And I will not toler=
ate attacks laid against me in full public view because I altered an opinio=
n I held up to the light of reality and found flawed. And it was flawed.=0A=
=0AI'll return to the list once I can trust myself not to explode :).=0A=0A=
 P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethed=
eepend.com=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=0A=0A=
=0A________________________________=0AFrom: Nico Edtinger <zf-contributors@=
lists.zend.com>=0ATo: P=E1draic Brady <[email-masked]>=0ASent: Mon=
, December 7, 2009 4:10:04 PM=0ASubject: Re: [zf-contributors] XSS And Malf=
ormed HTML Vulnerabilities In Zend_Filter_StripTags=0A=0A=0AAm 07.12.2009 u=
m 15:26 schrieb P=E1draic Brady:=0AI would also suggest the following:=0A>=
=0A>a) Rework the filter's current four lines of documentation (http://fram=
ework.zend.com/manual/en/zend.filter.set.html#zend.filter.set.striptags) to=
 cover the component in greater detail clarifying its use cases, potential =
for misuse, and clarifying it is not XSS  or malformed HTML safe.=0A>b) Imm=
ediately deprecate in 1.9 branch (and remove in 2.0 - preferably 1.10 given=
 its significance) its ability to flexibly allow some HTML/comments thus pr=
eserving its only truly worthwhile feature - stripping ALL HTML.=0A>c) Do t=
his ASAP.=0A>=0A=0AI'm missing the most important thing: write a unit test =
with known attack vectors. If I'd want an improvement as important as secur=
ity I'd write a unit test to prove that it works (or fails). Putting the bu=
rden on someone else by hiding testable examples in a blog post or email le=
aves a bad aftertaste.=0A=0Anico
--0-646074440-1260206712=:76776
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">I just deleted my last response to this list and will leave fo=
lk with this somewhat bitter note.<br><br>I did not report a security vulne=
rability on my blog. I revealed a potential avenue of misuse by end-users. =
On Twitter this has been challenged despite three very obvious clarificatio=
ns I intentionally added to that blog entry to dispel any appearance the ZF=
 was at fault.<br><br>In subsequent discussions, I became convinced this wa=
s...slightly...more serious. I cannot anticipate the changing currents of m=
y mind, and without the blog post and subsequent discussions with members o=
f the community, I may never have changed my mind. You may never have heard=
 of these issues.<br><br>But I did change my mind. By then the blog post wa=
s out for over a day, and withdrawing it out of concern for public
 disclosure was not an option. My blog is syndicated - it was all over Goog=
le within mere hours.<br><br>I also inflicted on Nico Edtinger a response o=
n this list that was undeserved, full of outrage, and wholly unnecessary. N=
ico - I apologise. It was stupendously stupid of me to have allowed that em=
ail go out.<br><br>I do however retain the right to change my mind. I retai=
n the write about things of interest to just about anybody. I do not regret=
 doing so. And I will not tolerate attacks laid against me in full public v=
iew because I altered an opinion I held up to the light of reality and foun=
d flawed. And it was flawed.<br><br>I'll return to the list once I can trus=
t myself not to explode :).<br><div>&nbsp;</div><span style=3D"color: rgb(0=
, 0, 191);"><font style=3D"font-family: times new roman,new york,times,seri=
f;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></=
span></font><span style=3D"font-style: italic;"><font style=3D"font-family:=
 times
 new roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com<=
/a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethed=
eepend.com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" tar=
get=3D"_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundatio=
n Irish Representative</a><br></font></span></span><div><br></div><div styl=
e=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;"><=
br><div style=3D"font-family: times new roman,new york,times,serif; font-si=
ze: 12pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=
=3D"font-weight: bold;">From:</span></b> Nico Edtinger &lt;zf-contributors@=
lists.zend.com&gt;<br><b><span style=3D"font-weight: bold;">To:</span></b> =
P=E1draic Brady &lt;[email-masked]&gt;<br><b><span style=3D"font-w=
eight: bold;">Sent:</span></b> Mon, December 7, 2009 4:10:04 PM<br><b><span=
 style=3D"font-weight:
 bold;">Subject:</span></b> Re: [zf-contributors] XSS And Malformed HTML Vu=
lnerabilities In Zend_Filter_StripTags<br></font><br>=0A<meta http-equiv=3D=
"x-dns-prefetch-control" content=3D"off"><base><div><div>Am 07.12.2009 um 1=
5:26 schrieb P=E1draic Brady:</div><blockquote type=3D"cite"><span class=3D=
"Apple-style-span" style=3D"border-collapse: separate; font-family: Helveti=
ca; font-size: medium; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: 2; word-spaci=
ng: 0px;"><div><div style=3D"margin: 0px; font-family: 'times new roman','n=
ew york',times,serif; font-size: 12pt;">I would also suggest the following:=
<br><br><span><span>a) Rework the filter's current four lines of documentat=
ion (<a target=3D"_blank" href=3D"http://framework.zend.com/manual/en/zend.=
filter.set.html#zend.filter.set.striptags">http://framework.zend.com/manual=
/en/zend.filter.set.html#zend.filter.set.striptags</a>) to cover the compon=
ent in greater detail clarifying its use cases, potential for
 misuse, and clarifying it is not XSS&nbsp; or malformed HTML safe.</span><=
/span><br>b) Immediately deprecate in 1.9 branch (and remove in 2.0 - prefe=
rably 1.10 given its significance) its ability to flexibly allow some HTML/=
comments thus preserving its only truly worthwhile feature - stripping ALL =
HTML.<br>c) Do this ASAP.<font class=3D"Apple-style-span" color=3D"#000000"=
 face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"font-size: me=
dium;"><font class=3D"Apple-style-span" color=3D"#144fae" face=3D"'times ne=
w roman', 'new york', times, serif" size=3D"4"><span class=3D"Apple-style-s=
pan" style=3D"font-size: 16px;"><br></span></font></span></font></div></div=
></span></blockquote><br></div><div>I'm missing the most important thing: w=
rite a unit test with known attack vectors. If I'd want an improvement as i=
mportant as security I'd write a unit test to prove that it works (or fails=
). Putting the burden on someone else by hiding testable examples in a blog=
 post or email
 leaves a bad aftertaste.</div><div><br></div><div>nico</div><meta http-equ=
iv=3D"x-dns-prefetch-control" content=3D"on"></div></div>=0A<!-- cg2.c902.m=
ail.ac4.yahoo.com compressed/chunked Mon Dec  7 03:29:14 PST 2009 -->=0A</d=
iv></body></html>
--0-646074440-1260206712=:76776--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
Date: Mon, 22 Mar 2010 15:35:26 +0000
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

On 22 Mar 2010, at 02:44, Matthew Weier O'Phinney wrote:

> -- Giorgio Sironi <[email-masked]> wrote
> (on Sunday, 21 March 2010, 03:15 PM +0100):
>> =46rom the wiki guidelines I thought the direct() method would be
>> enforced in the Zend_View_Helper_Interface.
>=20
> Yes -- this is exactly the idea, and the reason we started defining
> this. (Currently, however, we do not support it in any meaningful =
way.)
>=20
> I'm trying to decide if "direct" (which suggests strategy) or
> "execute" makes more sense for the method name.

execute() would be my preference. But for consistency with =
action_helpers, I can see the benefit of direct().

Regards,

Rob...=

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 11:03:06 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

-- drm <[email-masked]> wrote
(on Tuesday, 17 November 2009, 04:50 PM +0100):
> By the way: on what bases gets decided if something goes into the
> minimal package right now?

Minimal package is simply everything under library/ and bin/ under the
standard library (i.e., nothing from Extras, nothing pulled in from
svn:externals).

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 20:14:14 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

How would you create a reproducible benchmark ?
  - Is the DB local or reading from net ?
  - how many fields are in this table and which type ?
(In past I saw user tables have ALL configuration in it, incl. css styles.)

In my opinion this would be a good solution if the default is set to *.

@Diego
$fields[] = $credentialExpression is more high-performance than
array_push( $fields, $credentialExpression );

--
Marc

Am 25.01.2010 18:45, schrieb Dolf Schimmel:
> I would indeed like to see some (reproducable) benchmarks that show a
> significant improvement
>
> -- Freeaqingme
>
> On Mon, Jan 25, 2010 at 5:39 PM, Kevin McArthur <[email-masked]> wrote:
>   
>> The performance difference between a * and selected columns will be almost
>> nil.... short of something like an unmaterialized and complex view [in the
>> db sense] that is.
>>
>> I'd think this would add a fair amount of complication to the api and
>> codebase for what will be, for most people, practically zero benefit.
>> In-fact, for most, the additional requirement of a couple method invocations
>> and string operations will likely negate the effect of not returning the
>> extraneous columns in the first place.
>>
>> I'd vote no on this change.
>>
>> Kevin
>>
>>
>> Diego Henrique Oliveira wrote:
>>     
>>> In the adapter DbTable, the generated query to the database is a 'select
>>> *', and as it was being a bottleneck in my application (users table with
>>> many fields), i made these changes in the component
>>> Zend_Auth_Adapter_DbTable.
>>>
>>>
>>> class Zend_Auth_Adapter_DbTable
>>> {
>>>      protected $_returnedFields;
>>>      public function setReturnedFields( array $fields )
>>>    {
>>>        $this->_returnedFields = $fields;
>>>    }
>>>      public function getReturnedFields()
>>>    {
>>>        if (is_null($this->_returnedFields))
>>>        {
>>>            return array('*');
>>>        }
>>>        return $this->_returnedFields;
>>>    }
>>>      /**
>>>     * _authenticateCreateSelect() - This method creates a Zend_Db_Select
>>> object that
>>>     * is completely configured to be queried against the database.
>>>     *
>>>     * @return Zend_Db_Select
>>>     */
>>>    protected function _authenticateCreateSelect()
>>>    {
>>>        // build credential expression
>>>        if (empty($this->_credentialTreatment) ||
>>> (strpos($this->_credentialTreatment, '?') === false)) {
>>>            $this->_credentialTreatment = '?';
>>>        }
>>>
>>>        $credentialExpression = new Zend_Db_Expr(
>>>            '(CASE WHEN ' .
>>>            $this->_zendDb->quoteInto(
>>>                $this->_zendDb->quoteIdentifier($this->_credentialColumn,
>>> true)
>>>                . ' = ' . $this->_credentialTreatment, $this->_credential
>>>                )
>>>            . ' THEN 1 ELSE 0 END) AS '
>>>            . $this->_zendDb->quoteIdentifier(
>>>                $this->_zendDb->foldCase('zend_auth_credential_match')
>>>                )
>>>            );
>>>
>>>        // get select
>>>        $fields   = $this->getReturnedFields();
>>>        array_push( $fields, $credentialExpression );
>>>        $dbSelect = clone $this->getDbSelect();
>>>        $dbSelect->from($this->_tableName, $fields)
>>>
>>> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . ' =
>>> ?', $this->_identity);
>>>
>>>        return $dbSelect;
>>>    }
>>>   }
>>>
>>>
>>>
>>> What you guys think about these changes? And should I submit them to the
>>> project?
>>>
>>>
>>> Cheers
>>>
>>> Diego
>>> http://diegoholiveira.com
>>>
>>>       
>>     
>   

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Mon, 12 Oct 2009 23:29:55 +0200
Cc: Trevor Johns <[email-masked]>
Subject: [zf-contributors] Re: ZF Git repo,
	(was Re: [zf-contributors] Code Review)

On Monday 12 October 2009 21:08:02 Trevor Johns wrote:
>There is a mechanism to upload a patch file, but that's done outside of=20
>SVN/Git. I don't believethere's any way to start a code review from my=20
>command line.
>

Apologies in advance for thread hi-jack.

Trevor, on the subject of Git, first off thanks for making the effort to tr=
ack=20
the SVN repo on github. Second, would you please add the standard incubator=
 as=20
a remote tracking  branch?

Thanks,
Graham

=2D-=20
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D
 =E2=98=98 Oscar Wilde

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Fri, 26 Feb 2010 09:09:06 +0100
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

On Friday 26 February 2010 01:32:33 Ben Scholzen 'DASPRiD' wrote:
>Would that mean, that the component maintainers would not have any
>commit access anymore but only the liasions? Or would those component
>maintainers become the release masters? Because if only a handful of
>people (like those 3 liasions) would get commit access, the entire
>colaboration process would become pretty slow.

I don't want to speak for Matthew but I presume he was just illustrating on=
e=20
of the ways in which you can use multi branch/repo tracking.=20

Git is flexible enough to allow the current commit model (centralised commi=
ts)=20
and at the same time contributors and developers can track each others feat=
ure=20
branches and collaborate in a distributed fashion.

=2D-=20
=E2=80=9CWhat can be asserted without proof can be dismissed without proof.=
=E2=80=9D
=2D Christopher Hitchens

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 17 Jan 2010 10:54:56 +0100
From: Julien Pauli <[email-masked]>
To: Marc Bennewitz <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend_Serializer work

--0016e65b6298a702bd047d593ab1
Content-Type: text/plain; charset=ISO-8859-1

Ok no problem for your patch ;-)

(I think to change the status you have to re-open the issue, then re-close
it specifying a fix/version)

J.Pauli

On Sun, Jan 17, 2010 at 2:08 AM, Marc Bennewitz <[email-masked]>wrote:

> Hi Julien,
>
> I changed ZF-8842 to use class_implements because on creating an
> instance you executes code on an unchecked class.
>
> I don't know how to change the "Fix/Version" on a closed issue.
> ZF-8842 is changed now because reopened.
>
> Marc
>
> Am 16.01.2010 23:52, schrieb Julien Pauli:
> > Hi,
> >
> > I recently commited 20343-20345-20346 for Zend_Serializer.
> > See http://framework.zend.com/issues/browse/ZF-8844 -
> > http://framework.zend.com/issues/browse/ZF-8842
> >
> > I forgot to set the "Fix/Version" to next minor (1.10) , how can I
> > edit that later ? Reopening the issue seems the only way right ?
> >
> > Anyway, tell me if something goes wrong with the patches (shouldn't) ;-)
> >
> > J.Pauli
>

--0016e65b6298a702bd047d593ab1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ok no problem for your patch ;-)<br><br>(I think to change the status you h=
ave to re-open the issue, then re-close it specifying a fix/version)<br><br=
>J.Pauli<br><br><div class=3D"gmail_quote">On Sun, Jan 17, 2010 at 2:08 AM,=
 Marc Bennewitz <span dir=3D"ltr">&lt;<a href=3D"mailto:marc-bennewitz@arco=
r.de">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Julien,<br>
<br>
I changed ZF-8842 to use class_implements because on creating an<br>
instance you executes code on an unchecked class.<br>
<br>
I don&#39;t know how to change the &quot;Fix/Version&quot; on a closed issu=
e.<br>
ZF-8842 is changed now because reopened.<br>
<br>
Marc<br>
<br>
Am 16.01.2010 23:52, schrieb Julien Pauli:<br>
<div><div></div><div class=3D"h5">&gt; Hi,<br>
&gt;<br>
&gt; I recently commited 20343-20345-20346 for Zend_Serializer.<br>
&gt; See <a href=3D"http://framework.zend.com/issues/browse/ZF-8844" target=
=3D"_blank">http://framework.zend.com/issues/browse/ZF-8844</a> -<br>
&gt; <a href=3D"http://framework.zend.com/issues/browse/ZF-8842" target=3D"=
_blank">http://framework.zend.com/issues/browse/ZF-8842</a><br>
&gt;<br>
&gt; I forgot to set the &quot;Fix/Version&quot; to next minor (1.10) , how=
 can I<br>
&gt; edit that later ? Reopening the issue seems the only way right ?<br>
&gt;<br>
&gt; Anyway, tell me if something goes wrong with the patches (shouldn&#39;=
t) ;-)<br>
&gt;<br>
&gt; J.Pauli<br>
</div></div></blockquote></div><br>

--0016e65b6298a702bd047d593ab1--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 26 Jan 2010 11:00:51 -0500
From: Court Ewing <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Proposal: Zend_Loader Improvements

--001485f4238ae14072047e1363a8
Content-Type: text/plain; charset=ISO-8859-1

I'm a new contributor to ZF, and I'm writing a proposal for improvements to
Zend_Loader_PluginLoader and Zend_Loader_Autoloader_Resource that would
facilitate the support of PHP 5.3 namespaces.  I'd greatly appreciate any
input about the proposal before I push it off for review, though.  I'd much
rather have too much information than too little, and I'm not really sure
what is expected from the proposal itself:

http://framework.zend.com/wiki/display/ZFPROP/Zend_Loader+Improvements+-+Court+Ewing

I outlined what I think is the most appropriate implementation in the class
skeletons, but I am open to any ideas/opinions in terms of implementation as
well.

Regards,
Court Ewing

--001485f4238ae14072047e1363a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;m a new contributor to ZF, and I&#39;m writing a proposal for improve=
ments to Zend_Loader_PluginLoader and Zend_Loader_Autoloader_Resource that =
would facilitate the support of PHP 5.3 namespaces.=A0 I&#39;d greatly appr=
eciate any input about the proposal before I push it off for review, though=
.=A0 I&#39;d much rather have too much information than too little, and I&#=
39;m not really sure what is expected from the proposal itself:<br>
<br><a href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Loader+Im=
provements+-+Court+Ewing">http://framework.zend.com/wiki/display/ZFPROP/Zen=
d_Loader+Improvements+-+Court+Ewing</a><br><br>I outlined what I think is t=
he most appropriate implementation in the class skeletons, but I am open to=
 any ideas/opinions in terms of implementation as well.<br>
<br>Regards,<br>Court Ewing<br>

--001485f4238ae14072047e1363a8--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Wed, 30 Sep 2009 00:47:03 +0200
Subject: [zf-contributors] Re: Google Wave Invites

On Tuesday 29 September 2009 18:17:15 Graham Anderson wrote:
>The first wave (pardon the pun) of mass invites for Google Wave are going
> out tomorrow, people with existing accounts and new invitees will be
> allocated 8 additional invites.
>
>If you don't already have a wave account and have *not* signed up to get
> one, I'll send out my 8 invites in on a first come first served basis on
> this list.
>
>Graham
>

Ok by chronological order I'll send an invite to the following people as so=
on=20
as my account is activated tomorrow. Sorry I won't have any more invites to=
=20
give out.

James
Zeev
Dolf
Tobias
Shawn
Brenton
Jon
Eric

Tobias, I'll maybe delay your invite by an hour or so in case you get sent =
one=20
by google.

Perhaps there are others who may get one of the base invitations (with 8=20
additional invites) tomorrow and might share them on this list ;)

Graham

=2D-=20
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D
 =E2=98=98 Oscar Wilde

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Sune Kibsgaard Pedersen <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Date: Sat, 5 Dec 2009 11:00:26 +0100
Subject: Re: [zf-contributors] Zend Framework modularity and application
	structure

--Apple-Mail-1-379668854
Content-Type: text/plain;
	charset=UTF-8;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Hello,

I work at a danish TV channel company in the webdevelopment =20
department. We have a lot of sites, maybe 30 or so, and is starting to =20=

transform them to ZF. Currently about 7-8 is running ZF. Each site is =20=

a independent ZF application with a twist. They use the same =20
bootstrapper (extended ZF Application/Bootstrap) and have the same =20
folder structure, which is pretty much the same structure as ZF =20
suggests.

on each site we have a public module, which is mapped to xxx.tv2.dk, =20
where xxx is the sitename, a module named update is update.xxx.tv2.dk, =20=

which is the management module, and last the robot module. =20
robot.xxx.tv2.dk, which is where we put api's that is used by 3'rd =20
parties. The two latter has limited access based on firewall rules. etc.

Beside theese modules, we have a global module repository, eg, a video =20=

module, articles module and so fourth. This is the components that =20
would be shared across sites, and is put here instead of copy/pasting =20=

things around. Usually theese module actions is accessed by the site =20
via the action helper.

What i would like to see in ZF2 is something a bit smarter/lighter =20
than the action helper, for using a global module repository.

Please ask if you have further questions.

Best regards

Sune Kibsgaard

Den 05/12/2009 kl. 04.58 skrev Juozas:

> Hello everyone,
>
> as you know, Zend Framework 2.0 is having a major rewrite in some =20
> parts and a lot things can be arranged to make development easier/=20
> more flexible/etc.
>
> After discussing this with Matthew, I'm asking you to:
>
> Write in short, how do you use Zend Framework
>
> What interests us is how you work with modules (blog, products, =20
> news, users), how you divide your applications in to parts (admin, =20
> public, something else) and how other parts of code (acl, =20
> configuration, resources) comes into play here.
>
> The reason why I'm asking this, is because I'm using Zend Framework =20=

> for quote big applications and for me it's important to have ability =20=

> to create application with self-contained modules and sub-=20
> applications. For example I have e-commerce products having admin, =20
> public and supplier sub-applications, but everything is still nicely =20=

> divided into modules (products, warehouse, orders, customers etc.) =20
> and App_Application and FrontController plugins does some work to =20
> make one application code to be divided in these parts.
>
> However, I know that some people use applications completely based =20
> on acl - there is one site and only depending on what your =20
> permissions are, you see data, can edit or delete if you want to. =20
> Here again somewhat different structure comes into play. Also quite =20=

> popular thing to do is to have admin/default modules. Even though I =20=

> completely don't understand this approach, some people like it and =20
> use everyday, hence it should also be possible to use.
>
> So please write what you think about such things, I will try to read =20=

> them all, generalize into a comparison table and make it into a =20
> proposal of what functions from core are needed to support it =20
> (without any hacking, which I done quite a lot)
>
> --
> Juozas Kaziuk=C4=97nas ([email-masked])
> A=C5=A1 internete - JuoKaz (http://www.juokaz.com)

--Apple-Mail-1-379668854
Content-Type: text/html;
	charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Hello,<div><br></div><div>I =
work at a danish TV channel company in the webdevelopment department. We =
have a lot of sites, maybe 30 or so, and is starting to transform them =
to ZF. Currently about 7-8 is running ZF. Each site is a independent ZF =
application with a twist. They use the same bootstrapper (extended ZF =
Application/Bootstrap) and have the same folder structure, which is =
pretty much the same structure as ZF =
suggests.</div><div><br></div><div>on each site we have a public module, =
which is mapped to xxx.tv2.dk, where xxx is the sitename, a module named =
update is update.xxx.tv2.dk, which is the management module, and last =
the robot module. robot.xxx.tv2.dk, which is where we put api's that is =
used by 3'rd parties. The two latter has limited access based on =
firewall rules. etc.</div><div><br></div><div>Beside theese modules, we =
have a global module repository, eg, a video module, articles module and =
so fourth. This is the components that would be shared across sites, and =
is put here instead of copy/pasting things around. Usually theese module =
actions is accessed by the site via the action =
helper.</div><div><br></div><div>What i would like to see in ZF2 is =
something a bit smarter/lighter than the action helper, for using a =
global module repository.</div><div><br></div><div>Please ask if you =
have further questions.</div><div><br></div><div>Best =
regards</div><div><br></div><div>Sune =
Kibsgaard</div><div><div><div><br></div><div><br></div><div>Den =
05/12/2009 kl. 04.58 skrev Juozas:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Hello =
everyone,<div><br></div><div>as you know, Zend Framework 2.0 is having a =
major rewrite in some parts and a lot things can be arranged to make =
development easier/more flexible/etc.</div><div><br></div><div>After =
discussing this with Matthew, I'm asking you to:</div> =
<div><br></div><div><b>Write in short, how do you use Zend =
Framework</b></div><div><b><br></b></div><div>What&nbsp;interests us is =
how you work with modules (blog, products, news, users), how you divide =
your applications in to parts (admin, public, something else)&nbsp;and =
how other parts of code (acl, configuration, resources) comes into play =
here.&nbsp;</div> <div><br></div><div>The reason why I'm asking this, is =
because I'm using Zend Framework for quote big applications and for me =
it's important to have ability to create application with self-contained =
modules and sub-applications. For example I have e-commerce products =
having admin, public and supplier sub-applications, but everything is =
still nicely divided into modules (products, warehouse, orders, =
customers etc.) and App_Application and FrontController plugins does =
some work to make one application code to be divided in these =
parts.&nbsp;</div> <div><br></div><div>However, I know that some people =
use applications completely based on acl - there is one site and only =
depending on what your permissions are, you see data, can edit or delete =
if you want to. Here again somewhat different structure comes into =
play.&nbsp;Also quite popular thing to do is to have admin/default =
modules. Even though I completely don't understand this approach, some =
people like it and use everyday, hence it should also be possible to =
use.&nbsp;</div> <div><br></div><div>So please write what you think =
about such things, I will try to read them all, generalize into a =
comparison table and make it into a proposal of what functions from core =
are needed to support it (without any hacking, which I done quite a =
lot)</div> <div><br clear=3D"all">--<br>Juozas Kaziuk=C4=97nas (<a =
href=3D"mailto:[email-masked]">[email-masked]</a>)<br>A=C5=A1 =
internete - JuoKaz (<a =
href=3D"http://www.juokaz.com">http://www.juokaz.com</a>)<br> =
</div></blockquote></div><br></div></body></html>=

--Apple-Mail-1-379668854--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 15:27:26 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Bug Hunt Days this week

-- Tommy Smith <[email-masked]> wrote
(on Tuesday, 17 November 2009, 01:11 PM -0700):
> Matthew, I haven't sent in my CLA yet - have it here ready to scan in. I read
> it takes a few days to get done. Can I still do the Bug Hunt stuff?

If you get it sent in, and then ping me on Thursday/Friday on IRC, I can
verify manually before we officially process them; that way you can
contribute this week.

> On Tue, Nov 17, 2009 at 12:34 PM, Matthew Weier O'Phinney <[email-masked]>
> wrote:
> 
>     Just a reminder to everyone -- November's Bug Hunt Days are this week on
>     Thursday and Friday. Please help out as you can -- log into #zftalk.dev
>     on Freenode, or triage issues via this mailing list. Let's close *200*
>     bugs this month! :)
> 
>     Thanks in advance for all the help -- and for all the assistance each of
>     you provides each day!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 20 Mar 2009 14:59:09 -0700
From: "Wil Sinclair" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>,
	"till" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [zf-contributors] Release Policies and Conventions

Hmmm. New features are not allowed in mini releases. That's a very
important point that all contributors have to keep in mind. New features
and functionality enhancements *must* wait until the next minor release.

,Wil

-----Original Message-----
From: Thomas Weidner [mailto:[email-masked]]=20
Sent: Friday, March 20, 2009 2:38 PM
To: Wil Sinclair; till
Cc: [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

Wil, when that's the case then you should rewrite it because "ONLY BUG=20
FIXES" means for me that also new features are not allowed within mini=20
releases ;-)

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----=20
From: "Wil Sinclair" <[email-masked]>
To: "till" <[email-masked]>
Cc: "Thomas Weidner" <[email-masked]>;=20
<[email-masked]>
Sent: Friday, March 20, 2009 10:10 PM
Subject: RE: [zf-contributors] Release Policies and Conventions

You can add new API's and new features that don't affect API's much in
mini releases. They have to be BC, however. I'm pretty sure that's
called out in the document, but let me know if it's not.

Thanks.
,Wil

-----Original Message-----
From: till [mailto:[email-masked]]
Sent: Friday, March 20, 2009 2:07 PM
To: Wil Sinclair
Cc: Thomas Weidner; [email-masked]
Subject: Re: [zf-contributors] Release Policies and Conventions

What if I added a "feature" to an existing component.

I mean, from what I understand -- the mini releases shouldn't break BC
-- that's all. But if I add to the api that's allowed? (asking)

On Fri, Mar 20, 2009 at 10:02 PM, Wil Sinclair <[email-masked]> wrote:
> OK, I changed it. There will inevitably be some hand-waving around
what
> is a new feature and what is a functionality enhancement. I'd rather
> confine this thread to the issue of release policies and conventions.
:)
>
> New components pretty clearly fall under the category of 'new
features'
> in my mind. If others are confused, we should further clarify it.
>
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 1:42 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> "A mini release may contain only bug fixes. Note that no new features
or
> API
> changes are allowed whatsoever."
>
> This sentence could imply that new features are not allowed, but
> improvments
> of existing features are allowed as long as they don't change existing
> API.
> The word "only" could be overseen.
>
> The question is also what's for us the difference between a feature
> enhancement and a new feature.
> Feature Enhancement could be for example to add a new option. It would
> not
> change API. So a textual clearification would be great :-)
>
> Also to note: Are new components allowed within minor releases or only
> within major releases? Should also be defined.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: "Thomas Weidner" <[email-masked]>;
> <[email-masked]>
> Sent: Friday, March 20, 2009 9:31 PM
> Subject: RE: [zf-contributors] Release Policies and Conventions
>
>
> Hey Thomas, I'm not quite sure what you are referring to. Your
> understanding is correct, and the wiki page seems to reflect it
> perfectly. Can you tell me exactly what needs to be updated? Maybe
with
> the string that you're referring to?
>
> Thanks.
> ,Wil
>
> -----Original Message-----
> From: Thomas Weidner [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 12:57 PM
> To: Wil Sinclair; [email-masked]
> Subject: Re: [zf-contributors] Release Policies and Conventions
>
> Hy Wil,
>
> In my understanding also "feature enhancements" are actually not
allowed
> to
> be integrated within mini-releases.
> Only "Bug fixes" which do not add additional API are allowed.
>
> Maybe you should also add a definition for what's a bug fix, a
> improvement
> and a new feature to get that also defined, and we can all speak of
the
> same
> in future.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message -----
> From: "Wil Sinclair" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, March 20, 2009 8:47 PM
> Subject: [zf-contributors] Release Policies and Conventions
>
>
> Over the 2 years that I've been involved with the project, there have
> been many questions about what can go in to a given release and if
there
> are any guidelines for the release schedules. While many of you have
> pieced the picture together from different mails, IRC chats, etc. I've
> owed you a document for a long time now. Here it is:
>
>
>
>
http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
> tions
>
>
>
> I ask all contributors to review this and reply with any question or
> edits- especially if I missed something- in this forum.
>
>
>
> As always, thanks for all the time and effort. Also, go 1.8!
>
>
>
> ,Wil
>
>=20

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Menno Luiten <[email-masked]>
To: Julien Pauli <[email-masked]>
Cc: Marc Bennewitz <[email-masked]>,
	zf-contributors <[email-masked]>
Organization: NL-Eyes
Date: Sun, 17 Jan 2010 11:21:33 +0100
Subject: Re: [zf-contributors] Zend_Serializer work

Don't think so; can't you just edit the issue, go to the tab called
'Internal Project Management Fields' and set Fix version/s from there?

--Menno

On zo, 2010-01-17 at 10:54 +0100, Julien Pauli wrote:
> Ok no problem for your patch ;-)
> 
> (I think to change the status you have to re-open the issue, then
> re-close it specifying a fix/version)
> 
> J.Pauli
> 
> On Sun, Jan 17, 2010 at 2:08 AM, Marc Bennewitz
> <[email-masked]> wrote:
>         Hi Julien,
>         
>         I changed ZF-8842 to use class_implements because on creating
>         an
>         instance you executes code on an unchecked class.
>         
>         I don't know how to change the "Fix/Version" on a closed
>         issue.
>         ZF-8842 is changed now because reopened.
>         
>         Marc
>         
>         Am 16.01.2010 23:52, schrieb Julien Pauli:
>         
>         > Hi,
>         >
>         > I recently commited 20343-20345-20346 for Zend_Serializer.
>         > See http://framework.zend.com/issues/browse/ZF-8844 -
>         > http://framework.zend.com/issues/browse/ZF-8842
>         >
>         > I forgot to set the "Fix/Version" to next minor (1.10) , how
>         can I
>         > edit that later ? Reopening the issue seems the only way
>         right ?
>         >
>         > Anyway, tell me if something goes wrong with the patches
>         (shouldn't) ;-)
>         >
>         > J.Pauli
>         
> 

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 17:43:38 +0200
From: Pieter Kokx <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

This is a multi-part message in MIME format.
--------------060906090709010803060605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Matthew Weier O'Phinney schreef:
> -- Andy Fowler <[email-masked]> wrote
> (on Monday, 22 March 2010, 11:38 AM -0400):
>   
>> Eric, that sounds right to me -- it's how most Github workflows
>> operate, and it'd be terrific if we could use Github to submit pull
>> requests to Matthew, even though he'll be merging them into the
>> Zend-hosted repo.
>>     
>
> Please see my previous response to Eric.
>
>   
>> A quick note on "atomic commits" in git. One of the things I had to
>> learn when moving to Git was to get away from huge end-of-feature
>> commits, like one would make in SVN. Eventually, it becomes easier to
>> commit, revert, commit, revert many times during the course of a
>> feature. At the end of the feature branch you can squash those many
>> commits into a single atomic commit that contains all unit tests and
>> docs:
>>     
>
> Yes, but that's exactly what I was getting at. If we do library/ and
> tests/ and documentation/ all as submodules, we can't have that final
> atomic commit that has the tests and docs and code all together. :) 
>   
Well, actually you can. By making a commit to the super repository that
includes the new commits to the submodules, you have that atomic commit
that combines tests, code and docs.
> I thoroughly enjoy the flexibility Git offers, but when it comes to
> the master repository, we need the atomicity -- and the proposed
> submodule layout I provided earlier in the thread answers that.
>
>   
>> http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
>>
>> As a CLA'd but rare contributor, I'm really looking forward to the
>> move to Git. In the past few months, I had given up on submitting
>> patches. Nagging the IRC channel to pull something from JIRA was
>> terribly inefficient -- hopefully this can smooth things along!
>>     
>
> That's my hope as well.
>
>
>   
>> On Mar 22, 2010, at 11:21 AM, Eric Clemmons wrote:
>>
>>     
>>> So, would a hypothetical (Github) workflow be as follows?
>>> ...
>>> 3.  Make atomic commits for unit tests, code changes, and new documentation
>>> ...
>>> On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:
>>>
>>>       
>>>> ...
>>>>  Now, for an explanation of the "whys" behind this. As contributors,
>>>>  it's important to make atomic commits: your code fix should also
>>>>  include a corresponding unit test, and potentially a documentation
>>>>  commit as well. If we split the library and tests directories out
>>>>  into their own submodules, we cannot do so; the code and test must be
>>>>  committed separately, which is (a) more work, and (b) unintuitive.
>>>>  The same goes for related documentation commits.
>>>>         
-- Best Regards, Pieter Kokx PHP Developer Zend Framework developer

--------------060906090709010803060605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Matthew Weier O'Phinney schreef:
<blockquote cite="mid:20100322160429.GN4061@localhost" type="cite">
  <pre wrap="">-- Andy Fowler <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote
(on Monday, 22 March 2010, 11:38 AM -0400):
  </pre>
  <blockquote type="cite">
    <pre wrap="">Eric, that sounds right to me -- it's how most Github workflows
operate, and it'd be terrific if we could use Github to submit pull
requests to Matthew, even though he'll be merging them into the
Zend-hosted repo.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Please see my previous response to Eric.

  </pre>
  <blockquote type="cite">
    <pre wrap="">A quick note on "atomic commits" in git. One of the things I had to
learn when moving to Git was to get away from huge end-of-feature
commits, like one would make in SVN. Eventually, it becomes easier to
commit, revert, commit, revert many times during the course of a
feature. At the end of the feature branch you can squash those many
commits into a single atomic commit that contains all unit tests and
docs:
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes, but that's exactly what I was getting at. If we do library/ and
tests/ and documentation/ all as submodules, we can't have that final
atomic commit that has the tests and docs and code all together. :) 
  </pre>
</blockquote>
Well, actually you can. By making a commit to the super repository that
includes the new commits to the submodules, you have that atomic commit
that combines tests, code and docs.<br>
<blockquote cite="mid:20100322160429.GN4061@localhost" type="cite">
  <pre wrap="">I thoroughly enjoy the flexibility Git offers, but when it comes to
the master repository, we need the atomicity -- and the proposed
submodule layout I provided earlier in the thread answers that.

  </pre>
  <blockquote type="cite">
    <pre wrap=""><a class="moz-txt-link-freetext" href="http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html">http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html</a>

As a CLA'd but rare contributor, I'm really looking forward to the
move to Git. In the past few months, I had given up on submitting
patches. Nagging the IRC channel to pull something from JIRA was
terribly inefficient -- hopefully this can smooth things along!
    </pre>
  </blockquote>
  <pre wrap=""><!---->
That's my hope as well.

  </pre>
  <blockquote type="cite">
    <pre wrap="">On Mar 22, 2010, at 11:21 AM, Eric Clemmons wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">So, would a hypothetical (Github) workflow be as follows?
...
3.  Make atomic commits for unit tests, code changes, and new documentation
...
On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:

      </pre>
      <blockquote type="cite">
        <pre wrap="">...
 Now, for an explanation of the "whys" behind this. As contributors,
 it's important to make atomic commits: your code fix should also
 include a corresponding unit test, and potentially a documentation
 commit as well. If we split the library and tests directories out
 into their own submodules, we cannot do so; the code and test must be
 committed separately, which is (a) more work, and (b) unintuitive.
 The same goes for related documentation commits.
        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
</blockquote>
<pre wrap=""><div class="moz-txt-sig">-- 
Best Regards,

Pieter Kokx
PHP Developer
Zend Framework developer

</div></pre>
</body>
</html>

--------------060906090709010803060605--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 09:52:04 +0100
From: mikaelkael <[email-masked]>
To: =?windows-1252?Q?Jurri=EBn_Stutterheim?= <[email-masked]>
CC: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

Hi all,

For the usual user of TortoiseSVN, there is also TortoiseGit=20
(http://code.google.com/p/tortoisegit/).

Mickael

Le 26/02/2010 09:27, Jurri=EBn Stutterheim a =E9crit :
> Personally, I would love to see Git being used, but I agree with Thomas=
. Good tooling across all platforms is a must-have. Unfortunately, (tooli=
ng) support for Git on Windows is severely lacking.
> A good alternative could be Bazaar[1]. Even though I have hardly used i=
t, I will try and summarize what I've read about it so far.
> Tooling support across platforms is good. There is an Eclipse plugin[2]=
, a TortoiseBzr client[3] that acts much like the popular ToirtoiseSVN, a=
nd a cross-platform standalone tool, called BzrExplorer[4].
> Another nice property of Bazaar is that it seems to be a bit more "mana=
ged" (by my current lack of a better word) than Git. The default workflow=
s it supports are "safer" than those in Git. On one project I did, we tri=
ed Git, and the lack of enforced workflow by Git caused some commits to j=
ust get lost or overridden. Granted, that was because we were all inexper=
ienced with Git, but if that can happen in a small team, it can most defi=
nitely happen in a larger team, such as the team of all ZF contributors. =
For more information, check out [5].
>
> This email serves mostly as food for thought. I think the discussion sh=
ould not be Git vs SVN, but rather SVN vs DVCS.*
>
> Cheers,
>
> - Jurri=EBn
>
>
> [1] http://bazaar.canonical.com/en/
> [2] http://wiki.bazaar.canonical.com/BzrEclipse
> [3] http://wiki.bazaar.canonical.com/WindowsDownloads
> [4] http://wiki.bazaar.canonical.com/BzrExplorer
> [5] http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.h=
tml
>
>
> On Friday, February 26, 2010, at 08:46AM, "Thomas Weidner"<thomas.weidn=
[email-masked]>  wrote:
>   =20
>> If there is a working integration into Eclipse than things are also ok=
 for
>> people who are using Windows (like me).
>>
>> But when you must always open a linux virtual machine or go down to co=
mmand
>> line from Eclipse to commit anything than this is a real blocker as it
>> breaks the complete workflow and makes them less efficient.
>>
>> I have this problem and actually I am between 150 to 300 commits per m=
onth
>> just to give a number.
>>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com
>>
>> ----- Original Message -----
>> From: "P=E1draic Brady"<[email-masked]>
>> To: "Dolf Schimmel"<[email-masked]>
>> Cc: "Zend Framework Contributors"<[email-masked]>
>> Sent: Friday, February 26, 2010 12:45 AM
>> Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development beg=
ins!
>>
>>
>> I suppose just to make two points (I am pro-git but they need
>> consideration).
>>
>>     =20
>>>> Tooling across platforms is not as mature or robust
>>>>         =20
>>> Who needs
>>>       =20
>> anything else than /usr/bin/git? Obviously should the
>>     =20
>>> Atlassian tools should support git as well, but I guess they do these
>>> days.
>>>       =20
>> Original comment was referring to Windows. The tools are heavily Linux
>> centric and I'm sure many of us are more than comfortable doing things=
 the
>> Linux way. I know I rarely, if ever, leave the command line except to =
switch
>> to my editor or browser ;). Is everyone though? On Windows, the story =
is
>> less kind and the tools somewhat cumbersome. On the other hand, for SV=
N, the
>> Windows tooling is very mature, easy to use, and integrates right in
>> alongside pretty much everything.
>>
>> Paddy
>>
>> P=E1draic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> OpenID Europe Foundation Irish Representative
>>
>>
>>
>>
>>
>> ________________________________
>> From: Dolf Schimmel<[email-masked]>
>> To: Graham Anderson<[email-masked]>
>> Cc: [email-masked]
>> Sent: Thu, February 25, 2010 11:20:26 PM
>> Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development beg=
ins!
>>
>> I guess I'll have to confess I've been convinced ZF should use GIT,
>> not only because other major projects like Zym use it (:wink:), but
>> also because it seems to bring quite a lot of advantages, while hardly
>> bringing any disadvantages.
>>
>> The cons (from the wiki):
>>     =20
>>> Tracking CLAs becomes more difficult. Currently with SVN, we only gra=
nt
>>> access to those who have signed a CLA; if anybody can fork, we now ne=
ed
>>> some way to verify CLA status before pulling patches.
>>>       =20
>> After all there's always someone who's committing to the 'main'
>> (master?) repository. You can always track who makes those 'main'
>> commits? The person committing to the main repos should then keep
>> track of
>> everybody contributing to a certain commit has signed a CLA (as is
>> done now when a patch is applied). There should however be a clear and
>> uptodate list of everybody who signed a CLA (that's more than a
>> selectbox in jira...).
>>
>>
>>     =20
>>> No good svn:externals equivalent
>>>       =20
>> We could just commit a checkout of Dojo (and possibly Dcotrine) into
>> the ZF repository, making it read-only by anybody who's not a release
>> manager. For people who use svn for their own projects, there should
>> be an svn mirror for people to use for their svn:externals. If Zend
>> can't provide such mirror I (my company) would be happy to do so.
>>
>>     =20
>>> Tooling across platforms is not as mature or robust
>>>       =20
>> Who needs anything else than /usr/bin/git? Obviously should the
>> Atlassian tools should support git as well, but I guess they do these
>> days.
>>
>>     =20
>>> Would potentially require (re-)training contributors
>>>       =20
>> I have never worked with git myself, but how difficult can the basics
>> be? git clone, git pull, git status, git add, git commit -a should be
>> things any contributor can understand (right?). Instead of actively
>> train them, I'd be a fan of putting a link to
>> http://git.or.cz/course/svn.html in the topic of #zftalk.dev on
>> freenode (and the wiki etc...).
>>
>>
>> --Freeaqingme
>>
>> P.s. For all of those not following me, I indeed had a different
>> opinion on this a few days ago...
>>
>> On Thu, Feb 25, 2010 at 11:53 PM, Graham Anderson
>> <[email-masked]>  wrote:
>>     =20
>>> On Thursday 25 February 2010 21:48:57 Matthew Weier O'Phinney wrote:
>>>       =20
>>>> The release master can
>>>> track multiple repos from multiple collaborators, and then selective=
ly
>>>> merge into their own "master" -- and push those patches into the
>>>> mainline.
>>>>         =20
>>> For the benefit of those who don't currently use Git one other powerf=
ul
>>> aspect
>>> of this collaborative work-flow is being able to cherry pick commits.
>>>
>>> In this situation you may have multiple branches, some of them may or=
 may
>>> not
>>> track other developers remote branches. Rather than merge the whole b=
ranch
>>> from HEAD to 6 commits previously, you see that only one of the commi=
ts
>>> has
>>> the changeset you need. Git cherry-pick allows you to merge a single
>>> commit.
>>>
>>> This, and being able to merge at will from multiple remote branches i=
s the
>>> kind of functionality I believe makes Git more suitable than SVN for =
what
>>> we
>>> do.
>>>
>>> There's more, much more. One of the key differences between Git and S=
VN,
>>> and
>>> this is extremely important, is that Git tracks the _content_ of your
>>> files
>>> whereas SVN tracks the files themselves. Git really doesn't care that
>>> there
>>> are 10 or 20 or 1,000 files, it only cares about the content and it o=
nly
>>> cares
>>> how the content changes.
>>>
>>> Here's an example, since Layout.php has been in the codebase for a wh=
ile I
>>> wanted to see who was responsible for last editing it. So i looked at=
 the
>>> source and decided to lookup the method setMvcSuccessfulActionOnly().=
 It's
>>> on
>>> line number 483-487.
>>>
>>>     git blame -L 483,487 Layout.php
>>>
>>> I'll trim the output and ommit the actual code which is appended to t=
he
>>> end of
>>> the following lines but you can see the detailed info that is availab=
le.
>>>
>>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21
>>> +0000
>>> 483)
>>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21
>>> +0000
>>> 484)
>>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21
>>> +0000
>>> 485)
>>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21
>>> +0000
>>> 486)
>>> b1b8f48b incubator/library/Zend/Layout.php (ralph 2007-11-16 15:40:21
>>> +0000
>>> 487)
>>>
>>> So in less than a quarter of a second I can search the whole commit
>>> history of
>>> the main ZF repo and see who was responsible for last editing any lin=
e of
>>> any
>>> file. There's lots more gems like this that let you unleash the power=
 of
>>> Git
>>> if you want to look below the surface.
>>>
>>> The surface is a good place to be as well, let me offer a common work=
-flow
>>> situation with git using every day commands.
>>>
>>> git checkout -b foobar
>>> edit foo/bar.php
>>> ... hack hack hack ...
>>> *ring ring* oops emergency fix needed
>>> git stash
>>> git checkout master
>>> edit emergency/fix.php
>>> git commit -am "Commit fix!"
>>> git checkout foobar
>>> git stash pop
>>> ... hack hack hack ...
>>> git checkout master
>>> git merge foobar
>>> *glug glug glug* cold beers while your colleagues are still fighting =
SVN.
>>>
>>> The story above is: Create and move into feature branch "foobar". Sta=
rt
>>> hacking on the feature. Boss calls, X is broken!, stash your changes =
and
>>> quickly switch to master(trunk). Fix broken things, commit them, swit=
ch
>>> back
>>> to foobar branch. Pop your changes from the stash into your working s=
et,
>>> continue hacking. Switch to master(trunk) and merge your new feature
>>> Foobar.
>>> Profit!
>>>
>>> --
>>> =93What can be asserted without proof can be dismissed without proof.=
=94
>>> - Christopher Hitchens
>>>       =20

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Mon, 3 Aug 2009 22:26:07 +0200
Subject: Re: [zf-contributors] Re: [fw-general] Proposal for Extensions to
	Zend_Db_Expr

the ifnull example is bad yes, maybe it would be a good idea to find unbiased 
names for this functionality by extending them, for example IfIsNull() and 
equalsNull() or something.

I agree with you, its definately a good idea starting from ANSI sql and then 
going steps further.

greetings,
Benjamin

On Monday 03 August 2009 10:07:13 pm Andrew Ballard wrote:
> On Mon, Aug 3, 2009 at 3:16 PM, Benjamin Eberlei<[email-masked]> wrote:
> > Hello everyone,
> >
> > in combination with the Zend_Entity and Zend_Db_Mapper proposals I felt
> > the need for an extension of Zend_Db_Expr. This functionality would also
> > be a huge step for Zend_Db_Select to abstract vendor specific
> > functionality even more.
> >
> > A common expression object offers access to abstract from vendor specfic
> > syntax of building database queries, conditions, functions and such. It
> > should implement as much common functionality of the current supported
> > database drivers as possible.
> >
> > http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Expr+Extension+-+Be
> >njamin+Eberlei
> >
> > The expression object utilizes Zend_Db_Expr when necessary and offers
> > convenience functionality to escape the inputs correctly.
> >
> > I hope you can give me valuable feedback!
>
> If the intent is truly to abstract from "vendor specific syntax", the
> first thought that comes to mind is to start with ANSI SQL and work
> out from there. For instance, use case 6 suggests an ifnull() function
> rather than coalesce(). The former, I believe, is implemented in MySQL
> and SQLite, while the latter is standard and is supported across
> MySQL, SQLite, Oracle, SQL Server, and PostgreSQL.
>
> It gets further confusing since there is a function ISNULL in both
> MySQL and SQL Server that do totally different things. In MySQL, it
> returns 1 if the argument is NULL and 0 if it is not. In SQL Server,
> it is similar to COALESCE (but not the same).
>
> Andrew

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "H.N." <[email-masked]>
To: <[email-masked]>,
	<[email-masked]>
Date: Wed, 16 Dec 2009 02:57:50 +0100
Subject: [zf-contributors] Fwd

This is a multi-part message in MIME format.

------=_NextPart_000_003B_01C2A9A6.32485CE2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Change into the HTML-View to show the Message.

------=_NextPart_000_003B_01C2A9A6.32485CE2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-asci=
i">
<META content=3D"MSHTML 6.00.2600.0000" name=3DGENERATOR>
</HEAD>
<BODY bgcolor=3D#FFFFFF leftmargin=3D5 topmargin=3D5 rightmargin=3D5=20=
bottommargin=3D5>
<FONT size=3D2 color=3D#000000 face=3D"Arial">
<DIV align=3Dcenter><FONT size=3D1 color=3D#FFFFFF>yhbnokdc - oqvffooxg=
afduw - prkjojirq</FONT></DIV>
<DIV align=3Dcenter>&nbsp;</DIV>
<DIV align=3Dcenter><FONT size=3D7 color=3D#D5D500 face=3D"Times New=20=
Roman"><U>Merry Christmas!</U></FONT></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>There are two different opinions regarding to the emergence of=20=
this world, some people think this world with all live and all events=20=
would be a tiny part of the logical causal chain which started with the=
 big bang, the others are convinced of it, that it is finally the fault=
 of Adam and Eve because they have not observed the one holy law of God=
: "When the woman saw that the fruit of the tree was good for food and=20=
pleasing to the eye, and also desirable for gaining wisdom, she took=20=
some and ate it. She also gave some to her husband, who was with her=20=
. . ." According to this the big bang etc would be a willfully deceptio=
n of God, because without the doubt in God it wouldn't be possible to=20=
test the faith and unbelief of mankind and the sense of this world woul=
d get lost. In contrast to the religious view, a causal chain out of=20=
cause and effect can not have a beginning recently not emerge out of=20=
nothing, this contradicts to the laws of science, therewith there's not=
 only no cause before or for the big bang, but also no energy which wou=
ld have been necessary for the big bang, even not a tiny disbalance bet=
ween anything. If two fingers are pressed together then is nothing betw=
een them or rather no matter, of course the universe, the human himself=
 and the bright world which surrounds the human not emerged out of the=20=
completely harmless nothing between two fingers or without God, this=20=
are simply stories which were invented by some humans and which are bel=
ieved by children if they are told to them early enough, in the first=20=
states of the USA such stories were deleted already successfully from=20=
the curriculum, so that they weren't taught any more to the children=20=
in the schools!</B></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>If the big bang could have happened without God, practically=20=
everything could have emerged out of this, but this universe was build=20=
exactly so, that the suppositions for live are given, for example witho=
ut voltage no brainwaves could flow, without radiation this world would=
 be dark and ice-cold, without atoms and the possibility to build molec=
ules live would be impossible, the same would be without many other che=
mical properties and reactions or without elements like oxygen or nitro=
gen or carbon or hydrogen or . . . , also the lost of time or movement=20=
or space or matter or the three states of matter or physical energy or=20=
chemical energy or different agencies or continuity or . . . would make=
 live finally impossible. Without intelligence something absolute sense=
less would have emerged out of the big bang or out of nothing, but of=20=
course no live. Yes, the frightening recognition is, that this universe=
 was constructed deliberately exactly so, that the suppositions for liv=
e and higher live are given!</B></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>For the alleged chemical evolution of live, a first living and=20=
survivable unicellular organism would have been necessary, but a just=20=
10 =B5m large cell, a very complex, perfectly compound, three-dimension=
al puzzle or a survivable machine out of at least 10 quadrillion pieces=
 (16 g/mol), atoms of different kind and attribute, impossibly could=20=
be washed together in an unrealistic puddle out of cytoplasm, be bound=20=
together in the same second by many different chemical processes into=20=
a flexible unit and get enliven also in the same moment, to start to=20=
breathe, to eat, to grow . . . and to produce randomly complete and liv=
ing self-copies, which will grow up some day to intelligent structured=20=
humans. If we are honest we must admit, that even not only one single=20=
dead DNA strand could be washed together in a liquid or the belonging=20=
to copysystems, already the DNA strands of the first survivable cell=20=
must randomly have conformed exactly to the cell construction, beside=20=
this DNA strands are written in a very high programming language, until=
 today nobody can understand how or by which encoding systems this code=
s get transcribed into commands, movements and material constructions.=20=
Also for all the different cell organelles or sub-systems of the first=20=
survivable cell, must have been directly there the belonging to copysys=
tems or already the first cell division would have been impossible, but=
 how high must be the technology of a material system which could copy=20=
itself, try to build a computer which could copy itself!</B></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>The functions of cells partially happen on the molecular and=20=
atomic level, if the dateless old atoms, out of which we and the cells=20=
are set together, would be as big as table tennis balls, an average hum=
an brain with exactly 1374 g would take in one time the whole planet=20=
earth with its diameter of 12700 km (the average molecular mass of cere=
bral tissue is 13,5 g/mol, the volume of a table tennis ball is 33,5=20=
cm^3) and a 10 =B5m large unicellular organism out of 10 quadrillion=20=
atoms would take in the whole city Tokyo by a hight of more than 500=20=
meters. If God would build a machine out of 10 quadrillion atoms of dif=
ferent kind and attribute, this machine wouldn't die any more after its=
 commissioning, because it really would be able to breathe, to eat, to=20=
grow, to move . . . and to survive independently in its world and to=20=
divide itself many trillion times, to conquer the planet and to travel=20=
to the moon. If God would construct a machine with such properties, it=20=
would be so small, that we even couldn't see it with our multicellular=20=
eyes. We have got no idea about the intelligence of God the creator out=
 of nothing, but surly it's not grateful to use the by God constructed=20=
brain to say, that a dirty puddle was the inventor of live.</B></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>A just 10 =B5m large unicellular organism is a very complex,=20=
perfectly compound, three-dimensional puzzle out of at least 10 quadril=
lion pieces of different kind and attribute, but a chemical evolution=20=
even wouldn't be able to wash correctly together a DNA string or a two-=
dimensional computer program character string out of 1000 signs, which=20=
is written with only 10 different letters, because with every sign, whi=
ch will be attached after the first sign, the probability that the prog=
ram was written correctly sinks by the factor 10, so the probability=20=
that a computer program out of 1000 signs will be written correctly by=20=
random or will be washed together in a dirty puddle is 10^1000 (a 1 wit=
h one thousand 0). In contrast to this today we know, that the whole=20=
universe contains less than 10^100 atoms totally and that it is less=20=
than 10^18 seconds old. If the universe would be 100 times smaller or=20=
younger, the chance that the chemical evolution really happened would=20=
be 100 times less, if the 1000 sign computer program would be 100 times=
 shorter, the chance that the chemical evolution really happened would=20=
be 100 times bigger, so we can stroke out the zeros: 10^1000 - 10^100=20=
- 10^18 =3D 10^882. We have reduced the whole universe to one atom and=20=
an age of one second through only 118 letters! So the iron proof for=20=
the absolute impossibility of a chemical evolution was written down!</B=
></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>The live in this world seems to be real, but its existence is=20=
only a wonder, so are we the causal chain out of nothing, a network in=20=
the dark which thinks about itself or are we made by an unimaginable=20=
high intelligence? Some humans will be happy for 100 years and some wil=
l be sad for 100 years, but when this life ends will the eternity begin=
, so why to life for a worthless dust particle when it comes about the=20=
entire universe.</B></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>This message was sent from Mongolia to millions of people world=
wide.</B></DIV>
<DIV><B>&nbsp;</B></DIV>
<DIV><B>This email can't be answered because it was sent over an anonym=
 remailer string.</B></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dcenter><FONT size=3D1 color=3D#FFFFFF>psebgxycrnpr - r -=20=
nypsnm</FONT></DIV>
</FONT>
</BODY></HTML>

------=_NextPart_000_003B_01C2A9A6.32485CE2--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 16 Jan 2010 23:52:37 +0100
From: Julien Pauli <[email-masked]>
To: zf-contributors <[email-masked]>
Subject: [zf-contributors] Zend_Serializer work

--001636416dfb038162047d4ffae1
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I recently commited 20343-20345-20346 for Zend_Serializer.
See http://framework.zend.com/issues/browse/ZF-8844 -
http://framework.zend.com/issues/browse/ZF-8842

I forgot to set the "Fix/Version" to next minor (1.10) , how can I edit that
later ? Reopening the issue seems the only way right ?

Anyway, tell me if something goes wrong with the patches (shouldn't) ;-)

J.Pauli

--001636416dfb038162047d4ffae1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I recently commited 20343-20345-20346 for Zend_Serializer.<br>Se=
e <a href=3D"http://framework.zend.com/issues/browse/ZF-8844">http://framew=
ork.zend.com/issues/browse/ZF-8844</a> - <a href=3D"http://framework.zend.c=
om/issues/browse/ZF-8842">http://framework.zend.com/issues/browse/ZF-8842</=
a><br>
<br>I forgot to set the &quot;Fix/Version&quot; to next minor (1.10) , how =
can I edit that later ? Reopening the issue seems the only way right ?<br><=
br>Anyway, tell me if something goes wrong with the patches (shouldn&#39;t)=
 ;-)<br>
<br>J.Pauli<br>

--001636416dfb038162047d4ffae1--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 20:53:43 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

Matthew Weier O'Phinney wrote on 26.02.2010 14:59:
>  * To package individual components, we need some way to determine
>    dependencies. Currently, require_once statements can help with that,
>    but stripping them makes this harder. My solution is to add @uses
>    annotations at the class docblock level. This assists the API docs,
>    but also should make it possible to use automated scanners to
>    determine dependencies.

The idea is in fact better than tracking depencies through require_once
calls, since there were still depencies via autoloading, which thus can
be resolved via the @uses tag.

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 11:36:12 -0800 (PST)
From: Diego Henrique Oliveira <[email-masked]>
To: Marc Bennewitz <[email-masked]>, [email-masked]
Cc: Kevin McArthur <[email-masked]>, Dolf Schimmel <[email-masked]>
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

--0-736007829-1264448172=:9890
Content-Type: text/plain; charset=us-ascii

@Kevin
I do not think this solution could complicate the API. It's just another option for the developer, he can use or not.

@Dolf
I have not done benchmarks, but in a query that was returning 20 fields now returns only 4 (which is the answer for my authentication).

@Marc
Thanks for the tip, I will change in my code.

Cheers.

Diego

________________________________
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Sent: Mon, January 25, 2010 5:14:14 PM
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

How would you create a reproducible benchmark ?
  - Is the DB local or reading from net ?
  - how many fields are in this table and which type ?
(In past I saw user tables have ALL configuration in it, incl. css styles.)

In my opinion this would be a good solution if the default is set to *.

@Diego
$fields[] = $credentialExpression is more high-performance than
array_push( $fields, $credentialExpression );

--
Marc

Am 25.01.2010 18:45, schrieb Dolf Schimmel:
> I would indeed like to see some (reproducable) benchmarks that show a
> significant improvement
>
> -- Freeaqingme
>
> On Mon, Jan 25, 2010 at 5:39 PM, Kevin McArthur <[email-masked]> wrote:
>  
>> The performance difference between a * and selected columns will be almost
>> nil.... short of something like an unmaterialized and complex view [in the
>> db sense] that is.
>>
>> I'd think this would add a fair amount of complication to the api and
>> codebase for what will be, for most people, practically zero benefit.
>> In-fact, for most, the additional requirement of a couple method invocations
>> and string operations will likely negate the effect of not returning the
>> extraneous columns in the first place.
>>
>> I'd vote no on this change.
>>
>> Kevin
>>
>>
>> Diego Henrique Oliveira wrote:
>>    
>>> In the adapter DbTable, the generated query to the database is a 'select
>>> *', and as it was being a bottleneck in my application (users table with
>>> many fields), i made these changes in the component
>>> Zend_Auth_Adapter_DbTable.
>>>
>>>
>>> class Zend_Auth_Adapter_DbTable
>>> {
>>>      protected $_returnedFields;
>>>      public function setReturnedFields( array $fields )
>>>    {
>>>        $this->_returnedFields = $fields;
>>>    }
>>>      public function getReturnedFields()
>>>    {
>>>        if (is_null($this->_returnedFields))
>>>        {
>>>            return array('*');
>>>        }
>>>        return $this->_returnedFields;
>>>    }
>>>      /**
>>>     * _authenticateCreateSelect() - This method creates a Zend_Db_Select
>>> object that
>>>     * is completely configured to be queried against the database.
>>>     *
>>>     * @return Zend_Db_Select
>>>     */
>>>    protected function _authenticateCreateSelect()
>>>    {
>>>        // build credential expression
>>>        if (empty($this->_credentialTreatment) ||
>>> (strpos($this->_credentialTreatment, '?') === false)) {
>>>            $this->_credentialTreatment = '?';
>>>        }
>>>
>>>        $credentialExpression = new Zend_Db_Expr(
>>>            '(CASE WHEN ' .
>>>            $this->_zendDb->quoteInto(
>>>                $this->_zendDb->quoteIdentifier($this->_credentialColumn,
>>> true)
>>>                . ' = ' . $this->_credentialTreatment, $this->_credential
>>>                )
>>>            . ' THEN 1 ELSE 0 END) AS '
>>>            . $this->_zendDb->quoteIdentifier(
>>>                $this->_zendDb->foldCase('zend_auth_credential_match')
>>>                )
>>>            );
>>>
>>>        // get select
>>>        $fields   = $this->getReturnedFields();
>>>        array_push( $fields, $credentialExpression );
>>>        $dbSelect = clone $this->getDbSelect();
>>>        $dbSelect->from($this->_tableName, $fields)
>>>
>>> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . ' =
>>> ?', $this->_identity);
>>>
>>>        return $dbSelect;
>>>    }
>>>   }
>>>
>>>
>>>
>>> What you guys think about these changes? And should I submit them to the
>>> project?
>>>
>>>
>>> Cheers
>>>
>>> Diego
>>> http://diegoholiveira.com
>>>
>>>      
>>    
>  

--0-736007829-1264448172=:9890
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10pt"><div><span style="font-family: verdana,helvetica,sans-serif;"><span style="font-family: verdana,helvetica,sans-serif;">@Kevin<br>I do not think this solution could complicate the API. It's just another option for the developer, he can use or not.<br><br>@Dolf<br>I have not done benchmarks, but in a query that was returning 20 fields now returns only 4 (which is the answer for my authentication).<br><br>@Marc<br>Thanks for the tip, I will change in my code.</span><br><br></span><br><span style="font-family: verdana,helvetica,sans-serif;">Cheers.<br><br>Diego<br></span><br></div><div style="font-family: Courier New,courier,monaco,monospace,sans-serif; font-size: 10pt;"><br><div style="font-family: verdana,helvetica,sans-serif; font-size: 10pt;"><font size="2" face="Tahoma"><hr
 size="1"><b><span style="font-weight: bold;">From:</span></b> Marc Bennewitz &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">To:</span></b> [email-masked]<br><b><span style="font-weight: bold;">Sent:</span></b> Mon, January 25, 2010 5:14:14 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable<br></font><br>
How would you create a reproducible benchmark ?<br>&nbsp; - Is the DB local or reading from net ?<br>&nbsp; - how many fields are in this table and which type ?<br>(In past I saw user tables have ALL configuration in it, incl. css styles.)<br><br>In my opinion this would be a good solution if the default is set to *.<br><br>@Diego<br>$fields[] = $credentialExpression is more high-performance than<br>array_push( $fields, $credentialExpression );<br><br>--<br>Marc<br><br>Am 25.01.2010 18:45, schrieb Dolf Schimmel:<br>&gt; I would indeed like to see some (reproducable) benchmarks that show a<br>&gt; significant improvement<br>&gt;<br>&gt; -- Freeaqingme<br>&gt;<br>&gt; On Mon, Jan 25, 2010 at 5:39 PM, Kevin McArthur &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>&gt;&nbsp;  <br>&gt;&gt; The performance difference between a * and selected columns will be almost<br>&gt;&gt; nil.... short of
 something like an unmaterialized and complex view [in the<br>&gt;&gt; db sense] that is.<br>&gt;&gt;<br>&gt;&gt; I'd think this would add a fair amount of complication to the api and<br>&gt;&gt; codebase for what will be, for most people, practically zero benefit.<br>&gt;&gt; In-fact, for most, the additional requirement of a couple method invocations<br>&gt;&gt; and string operations will likely negate the effect of not returning the<br>&gt;&gt; extraneous columns in the first place.<br>&gt;&gt;<br>&gt;&gt; I'd vote no on this change.<br>&gt;&gt;<br>&gt;&gt; Kevin<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; Diego Henrique Oliveira wrote:<br>&gt;&gt;&nbsp; &nbsp;  <br>&gt;&gt;&gt; In the adapter DbTable, the generated query to the database is a 'select<br>&gt;&gt;&gt; *', and as it was being a bottleneck in my application (users table with<br>&gt;&gt;&gt; many fields), i made these changes in the component<br>&gt;&gt;&gt;
 Zend_Auth_Adapter_DbTable.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; class Zend_Auth_Adapter_DbTable<br>&gt;&gt;&gt; {<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; protected $_returnedFields;<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; public function setReturnedFields( array $fields )<br>&gt;&gt;&gt;&nbsp; &nbsp; {<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_returnedFields = $fields;<br>&gt;&gt;&gt;&nbsp; &nbsp; }<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; public function getReturnedFields()<br>&gt;&gt;&gt;&nbsp; &nbsp; {<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; if (is_null($this-&gt;_returnedFields))<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; {<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return array('*');<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; }<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; return $this-&gt;_returnedFields;<br>&gt;&gt;&gt;&nbsp; &nbsp; }<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; /**<br>&gt;&gt;&gt;&nbsp; &nbsp;  *
 _authenticateCreateSelect() - This method creates a Zend_Db_Select<br>&gt;&gt;&gt; object that<br>&gt;&gt;&gt;&nbsp; &nbsp;  * is completely configured to be queried against the database.<br>&gt;&gt;&gt;&nbsp; &nbsp;  *<br>&gt;&gt;&gt;&nbsp; &nbsp;  * @return Zend_Db_Select<br>&gt;&gt;&gt;&nbsp; &nbsp;  */<br>&gt;&gt;&gt;&nbsp; &nbsp; protected function _authenticateCreateSelect()<br>&gt;&gt;&gt;&nbsp; &nbsp; {<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; // build credential expression<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; if (empty($this-&gt;_credentialTreatment) ||<br>&gt;&gt;&gt; (strpos($this-&gt;_credentialTreatment, '?') === false)) {<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_credentialTreatment = '?';<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $credentialExpression = new Zend_Db_Expr(<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '(CASE WHEN '
 .<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_zendDb-&gt;quoteInto(<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_credentialColumn,<br>&gt;&gt;&gt; true)<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . ' = ' . $this-&gt;_credentialTreatment, $this-&gt;_credential<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; )<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . ' THEN 1 ELSE 0 END) AS '<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . $this-&gt;_zendDb-&gt;quoteIdentifier(<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_zendDb-&gt;foldCase('zend_auth_credential_match')<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; )<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; );<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp;
 // get select<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $fields&nbsp;  = $this-&gt;getReturnedFields();<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; array_push( $fields, $credentialExpression );<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $dbSelect = clone $this-&gt;getDbSelect();<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $dbSelect-&gt;from($this-&gt;_tableName, $fields)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; -&gt;where($this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_identityColumn, true) . ' =<br>&gt;&gt;&gt; ?', $this-&gt;_identity);<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; return $dbSelect;<br>&gt;&gt;&gt;&nbsp; &nbsp; }<br>&gt;&gt;&gt;&nbsp;  }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; What you guys think about these changes? And should I submit them to the<br>&gt;&gt;&gt; project?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Cheers<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Diego<br><span>&gt;&gt;&gt; <a target="_blank"
 href="http://diegoholiveira.com">http://diegoholiveira.com</a></span><br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  <br>&gt;&gt;&nbsp; &nbsp;  <br>&gt;&nbsp;  <br></div></div>
<!-- cg15.c2.mail.re1.yahoo.com compressed Mon Jan 25 09:31:45 PST 2010 -->
</div><br>

      </body></html>
--0-736007829-1264448172=:9890--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Leonid Komarovsky <[email-masked]>
To: [email-masked]
Date: Tue, 25 Aug 2009 15:33:44 +0300
Subject: [zf-contributors] test

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Carlton Gibson <[email-masked]>
Date: Tue, 15 Sep 2009 13:17:54 +0100
Cc: [email-masked]
To: "Matthew Weier O'Phinney" <[email-masked]>
Subject: Re: [zf-contributors] Announcement: Monthly Bug Hunt!

On 15 Sep 2009, at 13:07, Matthew Weier O'Phinney wrote:

> -- Carlton Gibson <[email-masked]> wrote
> (on Tuesday, 15 September 2009, 09:01 AM +0100):
>>
>> On 14 Sep 2009, at 18:10, P draic Brady wrote:
>>
>>
>>    * If you already have commit access, commit the test and fix to  
>> the
>>      repository, and either resolve the issue or ask somebody from  
>> Zend to
>>      review and resolve.  Don't forget to merge your changes to the  
>> 1.9
>>      release branch!
>>
>>
>> Just a few questions:
>>
>> 1) I'm a bit slow (as I've mentioned before) but, having committed  
>> changes back
>> to trunk, how exactly does one merge back into the release branch?
>
> Assuming you've done a single commit, the easiest way is to checkout
> both the trunk and branches/release-1.9 trees, and then merge between
> them. Let's assume the following directory structure:
>
>    zf/
>        trunk/         (checkout of trunk)
>        release-1.9/   (checkout of branches/release-1.9)
>
>> From the zf/ directory, do this:
>
>    % svn merge -c <revnum> trunk release-1.9
>
> where <revnum> is the revision number from trunk you want to merge to
> the 1.9 branch.
>
> This will merge all changes introduced in that revision into the 1.9
> branch. You then commit those:
>
>    % svn ci release-1.9 -m 'ZF-XXXX merge rXYZ to 1.9 release branch'
>
> substituting the appropriate issue ID and revision number, of course.
>
>> 2) The issue tracker has "Resolve" and "Close". Which should we  
>> use? (There
>> seem to be a lot of resolved issues that have never been closed.)
>
> "Resolve". Issues will be marked as "Closed" when we do a release.
>
>> 3) How much time do you Zend guys realistically have to review  
>> fixes? I like to
>> have another human review all my code (especially in a _high  
>> profile_ project
>> like this one :-) but if we're waiting ages for a review on a fix  
>> we're
>> confident with should we just resolve it? (Should we just harass  
>> you? Is their
>> a pool of willing reviewers? -- everyone is busy right?)
>
> During the bug hunt days, harrass us. :)
>
> If you already have commit access, though, then only ask for review if
> you're uncertain about the changes you're introducing. And don't limit
> yourself to just Zend folks -- ask on #zftalk.dev, and you'll likely
> find someone there willing and able to help review as well.
>

Thanks Matthew, good answers.

Regards,
Carlton

> -- 
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: [email-masked]
From: Justin Plock <[email-masked]>
Date: Tue, 29 Sep 2009 18:46:48 -0400
Lines: 15
Sender: news <[email-masked]>
Subject: [zf-contributors]  Re: Google Wave Invites

I'll take one - [email-masked]

Thanks!

-Justin

Graham Anderson wrote:
> The first wave (pardon the pun) of mass invites for Google Wave are going out 
> tomorrow, people with existing accounts and new invitees will be allocated 8 
> additional invites.
> 
> If you don't already have a wave account and have *not* signed up to get one, 
> I'll send out my 8 invites in on a first come first served basis on this list.
> 
> Graham

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Fri, 1 May 2009 15:30:20 +0200
Subject: [zf-contributors] ZF has mostly integration-tests, no unittests

Running a grep on the function 'getMock' of phpunit in the Zend Framework code 
basis shows that there are exactly 13 calls. Running any single testsuite 
shows that tests mostly depend on several other components, who depend on 
other components and so on.

Tests are for defect localization, otherwise they are integration tests and 
produce a large set of unmaintainable test-code which bites any component lead 
in the back some day.

We should maybe revisit our testing-strategy and enforce test-driven 
development on new components, additionally old unittests should be refactored 
to be more unittest like and not general tests that are build after the fact 
and only by tricking get to > 80% code-coverage . Any Ideas on how to improve 
test-code? Its totally going to get back at us.

For example look at Zend_Service_Amazon_OnlineTest. It talks to amazon for ALL 
its tests and asserts nothing. Still if you for example only run the 
"testItemSearchPhp" test you get a coverage of 76%! This is just bullhist!

Many ZF testsuites are that bad. They dont really test much and produce false 
comfort. The high number of bugs in many of the components are an indicator 
that there is something wrong somewhat.

greetings,
Benjamin

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 7 Apr 2009 22:20:52 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Zend Framework 1.8 Preview Release is released

Greetings, all!

I've just finished releasing the 1.8 preview release, and you can
download it from http://framework.zend.com/download/latest. The manual
has also been updated to reflect the new functionality.

On that note, there was a snafu when merging in the ZendX documentation.
Alex will hit that first thing in the morning so that it's present. If
you see any other anomolies, please send an email in reply to this one.

Thanks everyone for all the hard work in getting contributions ready for
this milestone. Let's work on polishing it and getting additional
bugfixes in before the final release later this month!

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 9 Aug 2009 18:39:52 -0700
From: Daniel Lo <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] API/Interface changes?

Hello,

Someone recently brought to my attention that fsockopen's dependency on
get_ini('default_socket_timeout') was really inconvenient in a web applicat=
ion
because it is 60 seconds by default. ( http://www.php.net/manual/en/ini.lis=
t.php
)

I thought about it, and I agreed that this was probably unreasonable and sh=
ould
allowed to be set in some manner via a configuration setting.

However, implementing this change has become fairly difficult because of the
"depth" of the final class that needs to be modified.

Zend_Queue is a class that returns a Zend_Queue + an adapter attached
on.  The adapter in this question is Activemq.  However, Activemq uses Stom=
p (a
simple protocol for messaging), but the Stomp uses another class for
actually doing the connection IO.

So in affect, a configuration change passed to

Zend_Queue($options['timeout']) -> Activemq -> Stomp wrapper -> Stomp IO.

In eagle hindsight, I should have made the "connection" options an associat=
ive
array for several of the constructor calls instead of using open($scheme, $=
host,
$port...).  Does anyone have any suggestions for fixing this that don't inv=
olve an
API change, which I understand is verbotten between minor revisions.

The best that comes to my mind is to use a class variable

class Zend_Queue_Stomp_Client_Connection {
    static protected $timeout =3D 10;
    static public function getTimeout() {
        return $this->timeout;
    }

    static public function setTimeout() { ... }
}

This saves me from disrupting a large section of code to implement a minor =
"useful"
change, but I don't like this idea of setting a "singleton" -in effect, glo=
bal
configuration variable.  Then in Zend Frameworks 2.0 - fix this flaw, which
should allow API changes.

Does anyone know a better solution?

-daniel

 =20

--=20
Best regards,
 Daniel                          mailto:[email-masked]

nFrom nobody Wed Apr  7 08:46:17 2010
Date: Tue, 20 Oct 2009 06:59:30 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Subject: Re: [zf-contributors] JIRA Incubator Components Update
To: Matthew Weier O'Phinney <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>

--0-1399783883-1256047170=:9736
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

The list I have is:=0A=0AZend_Feed_Pubsubhubbub=0AZend_Cache_Manager=0A=0AC=
an I stop now? No? ;)=0A=0AZend_Cache_Backend_Blackhole=0AZend_Amf=0AZend_A=
uth_Adapter_Cas=0AZend_Config_Writer=0AZend_Controller_Action_Helper_MultiP=
ageForm=0AZend_Db_Mapper=0AZend_Entity=0AZend_Environment=0AZend_Form_Decor=
ator_File=0AZend_Http_Client_Adapter_Curl=0AZend_Image=0AZend_Json_Server=
=0AZend_Markup=0AZend_Mime_Message=0AZend_Service_[LiveDocx|RememberTheMilk=
|TinyUrlCom|Gravatar|Tumblr|JdemCz]=0AZend_ShortUrl=0AZend_Validate_[Credit=
Card|EmailAddress|InArray|Isbn]=0AZend_View_Helper_Currency=0A=0AThere are =
also a few files in the Zend directory but no matching name directory, e.g.=
 Zend_Calendar.=0A=0ANot sure how fine-grained you want to get though, or e=
ven if all of these qualify. I'm not familiar with all of their activity/ag=
e. Also a few directories in the repository which are basically empty.=0A=
=0AHope everyone's having a grand time at Zendcon while the rest of us anal=
yse the Incubator :P.=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.c=
om=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish Repr=
esentative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Matthe=
w Weier O'Phinney <[email-masked]>=0ATo: [email-masked]=
=0ASent: Mon, October 19, 2009 5:01:02 AM=0ASubject: Re: [zf-contributors] =
JIRA Incubator Components Update=0A=0A-- P=E1draic Brady <padraic.brady@yah=
oo.com> wrote=0A(on Saturday, 17 October 2009, 06:15 AM -0700):=0A> Just re=
questing that we add in the missing Incubator components to JIRA if=0A> pos=
sible. At present we can't create issues for these.=0A=0ACan you refresh my=
 memory as to which incubator components need to be=0Aadded? I'll try and d=
o so Tuesday, once I have a list.=0A=0A> Assuming everyone has recovered fr=
om fixing 100 issues during the bug hunt! :P=0A=0AIndeed! Awesome job, ever=
yone! The final count for the official hunt was=0A95, and you can view the =
list here:=0A=0A    http://framework.zend.com/issues/secure/IssueNavigator.=
jspa?mode=3Dhide&requestId=3D11156=0A=0AI'll be announcing the winner on Tu=
esday -- but many thanks now to=0Aeveryone who participated!=0A=0A-- =0AMat=
thew Weier O'Phinney=0AProject Lead            | [email-masked]=0AZend Fr=
amework          | http://framework.zend.com/=0A
--0-1399783883-1256047170=:9736
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">The list I have is:<br><br>Zend_Feed_Pubsubhubbub<br>Zend_Cach=
e_Manager<br><br>Can I stop now? No? ;)<br><br>Zend_Cache_Backend_Blackhole=
<br>Zend_Amf<br>Zend_Auth_Adapter_Cas<br>Zend_Config_Writer<br>Zend_Control=
ler_Action_Helper_MultiPageForm<br>Zend_Db_Mapper<br>Zend_Entity<br>Zend_En=
vironment<br>Zend_Form_Decorator_File<br>Zend_Http_Client_Adapter_Curl<br>Z=
end_Image<br>Zend_Json_Server<br>Zend_Markup<br>Zend_Mime_Message<br>Zend_S=
ervice_[LiveDocx|RememberTheMilk|TinyUrlCom|Gravatar|Tumblr|JdemCz]<br>Zend=
_ShortUrl<br>Zend_Validate_[CreditCard|EmailAddress|InArray|Isbn]<br>Zend_V=
iew_Helper_Currency<br><br>There are also a few files in the Zend directory=
 but no matching name directory, e.g. Zend_Calendar.<br><br>Not sure how fi=
ne-grained you want to get though, or even if all of these qualify. I'm
 not familiar with all of their activity/age. Also a few directories in the=
 repository which are basically empty.<br><br>Hope everyone's having a gran=
d time at Zendcon while the rest of us analyse the Incubator :P.<br><div>&n=
bsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family=
: times new roman,new york,times,serif;" size=3D"3"><span style=3D"font-wei=
ght: bold;">P=E1draic Brady<br><br></span></font><span style=3D"font-style:=
 italic;"><font style=3D"font-family: times new roman,new york,times,serif;=
" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"http://blog.astr=
umfutura.com">http://blog.astrumfutura.com</a><br><a rel=3D"nofollow" targe=
t=3D"_blank" href=3D"http://www.survivethedeepend.com">http://www.surviveth=
edeepend.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://ww=
w.openideurope.eu/">OpenID Europe Foundation Irish Representative</a><br></=
font></span></span><div><br></div><div style=3D"font-family: times new roma=
n,new york,times,serif;
 font-size: 12pt;"><br><div style=3D"font-family: tahoma,new york,times,ser=
if; font-size: 8pt;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><sp=
an style=3D"font-weight: bold;">From:</span></b> Matthew Weier O'Phinney &l=
t;[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">To:</span><=
/b> [email-masked]<br><b><span style=3D"font-weight: bold;"=
>Sent:</span></b> Mon, October 19, 2009 5:01:02 AM<br><b><span style=3D"fon=
t-weight: bold;">Subject:</span></b> Re: [zf-contributors] JIRA Incubator C=
omponents Update<br></font><br>=0A-- P=E1draic Brady &lt;<a ymailto=3D"mail=
to:[email-masked]" href=3D"mailto:[email-masked]">padraic=
[email-masked]</a>&gt; wrote<br>(on Saturday, 17 October 2009, 06:15 AM -=
0700):<br>&gt; Just requesting that we add in the missing Incubator compone=
nts to JIRA if<br>&gt; possible. At present we can't create issues for thes=
e.<br><br>Can you refresh my memory as to which incubator components need t=
o be<br>added? I'll try and do so Tuesday, once I have a list.<br><br>&gt; =
Assuming everyone has recovered from fixing 100 issues during the bug hunt!=
 :P<br><br>Indeed! Awesome job, everyone! The final count for the official =
hunt was<br>95, and you can view the list here:<br><br><span>&nbsp; &nbsp; =
<a target=3D"_blank" href=3D"http://framework.zend.com/issues/secure/IssueN=
avigator.jspa?mode=3Dhide&amp;requestId=3D11156">http://framework.zend.com/=
issues/secure/IssueNavigator.jspa?mode=3Dhide&amp;requestId=3D11156</a></sp=
an><br><br>I'll be announcing the winner on
 Tuesday -- but many thanks now to<br>everyone who participated!<br><br>-- =
<br>Matthew Weier O'Phinney<br>Project Lead&nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; | <a ymailto=3D"mailto:[email-masked]" href=3D"mailto:matthew@z=
end.com">[email-masked]</a><br><span>Zend Framework&nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; | <a target=3D"_blank" href=3D"http://framework.zend.com/">htt=
p://framework.zend.com/</a></span><br></div></div></div></body></html>
--0-1399783883-1256047170=:9736--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 19 May 2009 12:47:24 -0500
From: Ralph Schindler <[email-masked]>
To: Vincent de Lau <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Zend_Session

> Can register_shutdown_function()[1] be savely used to do this kind of stuff?
> In other words, does a function registered with register_shutdown_function()
> run before shutdown cleanup? Reading this[2] comment, I suppose it does.
> 

No, even with register_shutdown_function(), you still cannot throw 
exceptions when there is exceptional behavior.  And this makes sense, 
b/c if PHP is in its shutdown mode, there is no way to execute your 
"exception catching" code anyway as it already might have been destroyed 
in the stack.

You get this error anytime you throw an exception at PHP Shutdown time:

Fatal error: Exception thrown without a stack frame in Unknown on line 0

-ralph

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 8 Mar 2010 16:41:51 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 2.0 Status: 8 Mar 2010

Greetings, all!

Today I completed the first milestone in ZF 2.0 development: stripping
require_once calls from the ZF library. 

I touched over 2k files in doing so. For each file, I removed existing
require_once calls and replaced them with @uses annotations in the
class-level docblock. I also searched for 'Zend_[a-zA-Z0-9_]+::',
'_once', and 'new ' throughout each file to see if other implicit,
undeclared, or lazy-loaded dependencies existed (including SPL and other
PHP classes), and added additional @uses annotations for these. The
rationale behind this was to:

 * Leave the code clean. Many *_once calls had docblocks preceding them
   with @see annotations, and these were also removed.

 * Prepare for namespace declarations. SPL classes will need to be
   imported or prefixed with a namespace separator to ensure global
   namespace lookups. The above excercise will help identify potential
   problem areas. Additionally, we can easily do a first-pass conversion
   to namespaces by analyzing @uses declarations. 

 * Get a handle on extension dependencies. This is incomplete, as I did
   not create @uses annotations for those extensions that only declare
   methods.

I've also begun refactoring the test suite. I've removed all AllTests
files, renamed TestHelper.php to Bootstrap.php and added autoloading
capabilities to it, and created a phpunit.xml file that references
Bootstrap.php as a phpunit bootstrap. Thanks to Bill Karwin's excellent
addition of @group annotations late in 2009, this allows us to run
individual test suites without needing to declare them:

    # from tests/ directory
    % phpunit --group Zend_Acl .

This takes slightly longer than running one of the AllTests suites, but
very much simplifies the process of writing tests, and makes them
self-organizing.

However, I've run into a bit of a sticky situation already: Evidently
several contributors have written TestCase classes that were never
referenced in their AllTests suites. This meant that previously they did
not run -- but now, since phpunit simply looks for classes ending in
"Test", they do.

As an example, tests/Zend/Amf/Value/ArrayCollectionTest.php is one such
test case. It cannot pass tests at this point -- and as a result, could
cause the entire suite to fail in a PHP error.

My solution to this has been the following: first, I've added the
following stanza to the phpunit.xml file:

    <groups>
        <exclude>
            <group>disable</group>
        </exclude>
    </groups>

Then, for each class that I find that was not referenced previously, and
which does not pass, I'm adding the annotation "@group disable". This
effectively skips those tests -- and gives us something to grep on in
order to build automated notifications to contributors about fixing test
suites. :)

Look for more updates this week, as Ralph and Alex are freed up to
assist in getting ZF 2.0 infrastructure into place!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 20:51:42 +0000
From: David Caunt <[email-masked]>
To: Court Ewing <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

--0015174767ae5f9ee90481dd0cb1
Content-Type: text/plain; charset=UTF-8

Hi Matthew,

I strongly agree with the choice of 3, with 2 a distant second. As Court
says, the SPL contains Countable, Serializable and many others, and I've
always found these intuitive without giving it much thought. Seems sensible
to follow a PHP convention if there's no significant benefit of another
style.

For abstract classes there are more options, and none seem to particularly
stand out as ideal. What I like about the ZF1 system is that class names do
contain an indicator that they are Abstract (suffix). Use of the word Base
introduces some ambiguity (albeit small) so I'd prefer the word Abstract,
but an Abstract suffix (5) only feels sensible if Interfaces have the
Interface suffix. Perhaps a Base suffix is the best solution! I guess I'm
happy to be persuaded.

David

On 15 March 2010 20:21, Court Ewing <[email-masked]> wrote:

> Howdy,
>
> I think adjective/noun names for interfaces are ideal because they are far
> more inline with the naming conventions already used in SPL, and I think
> that is something we should be striving to do wherever possible.
>
> I support prefixes for abstract classes rather than suffixes, but it seems
> that has long been shot down as an option.
>
> Regardless of whether we do prefixes or suffixes though, I think we should
> use the word "Abstract" rather than "Base".  All programmatic dogma aside,
> if I were to describe an abstract class to someone else (take an abstract
> Triangle class), I would tell the person that this is an abstract
> representation of a triangle; I wouldn't say it is a base representation of
> a triangle.  If you're going to cite hungarian notation as the reason for
> not using the word "abstract", then I don't know how you can justify using
> any keyword to denote that it is abstract.
>
> -Court
>
>
> On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[email-masked]
> > wrote:
>
>> Hey, all --
>>
>> I know this has been hashed out a fair bit already, and we've already
>> established some guidelines, but as I play with code for ZF2, I'm
>> beginning to question the naming conventions for Interfaces and Abstract
>> Classes.
>>
>> When we made the decisions before, we were looking at the following
>> three options for interfaces:
>>
>>  1. Prefix interfaces with "I" ("IFoobar").
>>  2. Suffix interfaces with "Interface" ("FoobarInterface")
>>  3. Use adjective/noun names such as "Foobarable", "Foobarist"
>>
>> For abstract classes, we looked at:
>>
>>  4. Prefix abstract classes with "A" ("AFoobar")
>>  5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>>  6. Prefix abstract classes with "Base" ("BaseFoobar")
>>  7. Suffix abstract classes with "Base" ("FoobarBase")
>>  8. Use normal class names ("Foobar")
>>
>> Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
>> they smack of Hungarian Notation, the long forms lead to really long
>> names, etc. Prefixing can lead to similar classes not being grouped when
>> doing directory listings (i.e., all abstract class or interface files
>> get clustered together). Also, for classes beginning with "I" or "A",
>> there can potentially be confusion over whether or not the given class
>> is supposed to be concrete. Finally, during refactoring, if you choose
>> to make an interface an abstract class or concrete class, or an abstract
>> class an interface or concrete class, you can't do so without renaming
>> files and classes. (That said, you'll most likely need to make other
>> changes anyways -- and ZF will likely never make an interface an
>> abstract class or vice versa.)
>>
>> Regarding 3 and 8, the primary problems are that it's often hard to come
>> up with meaningful names that do not conflict with concrete
>> implementations, and that for non-native English speakers, this latter
>> problem becomes an even bigger obstacle. Additionally, you can't
>> determine which files contain abstract classes and/or interfaces just by
>> the filename -- you have to look in the file or look in API
>> documentation to determine this information.
>>
>> Now, as to the issues I've seen: the word "Interface" becomes a real
>> pain to type (yes, even with autocompletion), and it doesn't really
>> connote any real information. When type-hinting, I simply know what type
>> I want to use -- the name doesn't need to tell me it's an interface, as
>> I already know that information. If I'm writing code that consumes or
>> interacts with the class, API docs will tell me what I need to do.
>>
>> That said, I don't use Abstract classes that often, but considering they
>> are a foundation on which to build concrete classes (presumably to take
>> care of many of the nitty gritty details and leave the concrete classes
>> to implement specifics), I don't mind using a class suffix. "Abstract"
>> feels like Hungarian notation, though.
>>
>> Based on my experiences writing code, I'm currently recommending that we
>> do the following:
>>
>>  3. Use adjective/noun names for Interfaces such as "Foobarable",
>>    "Foobarist"
>>  7. Suffix abstract classes with "Base" ("FoobarableBase")
>>
>> The above solve most issues - names are reasonably sized, don't smack of
>> Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
>> most importantly, meaningful. Since we already implement code review for
>> any code coming into trunk, I think we can even solve the issues for
>> non-native speakers as well.
>>
>> Thoughts? Votes?
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead            | [email-masked]
>> Zend Framework          | http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>
>
>

-- 
Save Water...Drink Ouzo !

--0015174767ae5f9ee90481dd0cb1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Matthew,<div><br></div><div>I strongly agree with the choice of 3, with =
2 a distant second. As Court says, the SPL contains Countable, Serializable=
 and many others, and I&#39;ve always found these intuitive without giving =
it much thought. Seems sensible to follow a PHP convention if there&#39;s n=
o significant benefit of another style.</div>
<div><br></div><div>For abstract classes there are more options, and none s=
eem to particularly stand out as ideal. What I like about the ZF1 system is=
 that class names do contain an indicator that they are Abstract (suffix). =
Use of the word Base introduces some ambiguity (albeit small) so I&#39;d pr=
efer the word Abstract, but an Abstract suffix (5) only feels sensible if I=
nterfaces have the Interface suffix. Perhaps a Base suffix is the best solu=
tion! I guess I&#39;m happy to be persuaded.<br>
<br></div><div>David</div><div><br><div class=3D"gmail_quote">On 15 March 2=
010 20:21, Court Ewing <span dir=3D"ltr">&lt;<a href=3D"mailto:courtewing@g=
mail.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
Howdy,<br><br>I think adjective/noun names for interfaces are ideal because=
 they are far more inline with the naming conventions already used in SPL, =
and I think that is something we should be striving to do wherever possible=
.<br>

<br>I support prefixes for abstract classes rather than suffixes, but it se=
ems that has long been shot down as an option.<br><br>Regardless of whether=
 we do prefixes or suffixes though, I think we should use the word &quot;Ab=
stract&quot; rather than &quot;Base&quot;.=C2=A0 All programmatic dogma asi=
de, if I were to describe an abstract class to someone else (take an abstra=
ct Triangle class), I would tell the person that this is an abstract repres=
entation of a triangle; I wouldn&#39;t say it is a base representation of a=
 triangle.=C2=A0 If you&#39;re going to cite hungarian notation as the reas=
on for not using the word &quot;abstract&quot;, then I don&#39;t know how y=
ou can justify using any keyword to denote that it is abstract.<br>
<font color=3D"#888888">
<br>-Court</font><div><div></div><div class=3D"h5"><br><br><div class=3D"gm=
ail_quote">On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O&#39;Phinney <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=
[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hey, all --<br>
<br>
I know this has been hashed out a fair bit already, and we&#39;ve already<b=
r>
established some guidelines, but as I play with code for ZF2, I&#39;m<br>
beginning to question the naming conventions for Interfaces and Abstract<br=
Classes.<br>
<br>
When we made the decisions before, we were looking at the following<br>
three options for interfaces:<br>
<br>
=C2=A01. Prefix interfaces with &quot;I&quot; (&quot;IFoobar&quot;).<br>
=C2=A02. Suffix interfaces with &quot;Interface&quot; (&quot;FoobarInterfac=
e&quot;)<br>
=C2=A03. Use adjective/noun names such as &quot;Foobarable&quot;, &quot;Foo=
barist&quot;<br>
<br>
For abstract classes, we looked at:<br>
<br>
=C2=A04. Prefix abstract classes with &quot;A&quot; (&quot;AFoobar&quot;)<b=
r>
=C2=A05. Suffix abstract classes with &quot;Abstract&quot; (&quot;FoobarAbs=
tract&quot;)<br>
=C2=A06. Prefix abstract classes with &quot;Base&quot; (&quot;BaseFoobar&qu=
ot;)<br>
=C2=A07. Suffix abstract classes with &quot;Base&quot; (&quot;FoobarBase&qu=
ot;)<br>
=C2=A08. Use normal class names (&quot;Foobar&quot;)<br>
<br>
Regarding 1, 2, and 4-7, the arguments against were fairly numerous:<br>
they smack of Hungarian Notation, the long forms lead to really long<br>
names, etc. Prefixing can lead to similar classes not being grouped when<br=
doing directory listings (i.e., all abstract class or interface files<br>
get clustered together). Also, for classes beginning with &quot;I&quot; or =
&quot;A&quot;,<br>
there can potentially be confusion over whether or not the given class<br>
is supposed to be concrete. Finally, during refactoring, if you choose<br>
to make an interface an abstract class or concrete class, or an abstract<br=
class an interface or concrete class, you can&#39;t do so without renaming<=
br>
files and classes. (That said, you&#39;ll most likely need to make other<br=
changes anyways -- and ZF will likely never make an interface an<br>
abstract class or vice versa.)<br>
<br>
Regarding 3 and 8, the primary problems are that it&#39;s often hard to com=
e<br>
up with meaningful names that do not conflict with concrete<br>
implementations, and that for non-native English speakers, this latter<br>
problem becomes an even bigger obstacle. Additionally, you can&#39;t<br>
determine which files contain abstract classes and/or interfaces just by<br=
the filename -- you have to look in the file or look in API<br>
documentation to determine this information.<br>
<br>
Now, as to the issues I&#39;ve seen: the word &quot;Interface&quot; becomes=
 a real<br>
pain to type (yes, even with autocompletion), and it doesn&#39;t really<br>
connote any real information. When type-hinting, I simply know what type<br=
I want to use -- the name doesn&#39;t need to tell me it&#39;s an interface=
, as<br>
I already know that information. If I&#39;m writing code that consumes or<b=
r>
interacts with the class, API docs will tell me what I need to do.<br>
<br>
That said, I don&#39;t use Abstract classes that often, but considering the=
y<br>
are a foundation on which to build concrete classes (presumably to take<br>
care of many of the nitty gritty details and leave the concrete classes<br>
to implement specifics), I don&#39;t mind using a class suffix. &quot;Abstr=
act&quot;<br>
feels like Hungarian notation, though.<br>
<br>
Based on my experiences writing code, I&#39;m currently recommending that w=
e<br>
do the following:<br>
<br>
=C2=A03. Use adjective/noun names for Interfaces such as &quot;Foobarable&q=
uot;,<br>
 =C2=A0 =C2=A0&quot;Foobarist&quot;<br>
=C2=A07. Suffix abstract classes with &quot;Base&quot; (&quot;FoobarableBas=
e&quot;)<br>
<br>
The above solve most issues - names are reasonably sized, don&#39;t smack o=
f<br>
Hungarian Notation (okay, so the &quot;Base&quot; verbiage kind of does), a=
nd are,<br>
most importantly, meaningful. Since we already implement code review for<br=
any code coming into trunk, I think we can even solve the issues for<br>
non-native speakers as well.<br>
<br>
Thoughts? Votes?<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:m=
[email-masked]" target=3D"_blank">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
PGP key: <a href=3D"http://framework.zend.com/zf-matthew-pgp-key.asc" targe=
t=3D"_blank">http://framework.zend.com/zf-matthew-pgp-key.asc</a><br>
</font></blockquote></div><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water.=
..Drink Ouzo !<br>
</div>

--0015174767ae5f9ee90481dd0cb1--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 3 Apr 2009 16:47:05 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] What status of Zend_Db_Table_Plugin?

-- Alexey Simonenko <[email-masked]> wrote
(on Saturday, 04 April 2009, 12:14 AM +0400):
> Zend_Db_Table_Plugin code is in incubator long time ago. What's status  
> of this code?

The primary contributors have simply not had time to complete unit tests
and documentation. If somebody would like to assist, I'm sure they'd be
happy to hand it over.

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Carlton Gibson <[email-masked]>
Date: Mon, 21 Dec 2009 12:17:13 +0000
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Status of ZF-6654 - Can/Should I take this on? 

See: http://framework.zend.com/issues/browse/ZF-6654

Hi all,=20

I've got a problem with chained routes not matching wildcards.

This kind of thing doesn't work:=20

$userRoute =3D new
 =
Zend_Controller_Router_Route_Hostname(':nickname..'.$configuration->genera=
l->domain,
                    array('controller'=3D>'profile', 'action'=3D>'view'));=

$userActionsRoute =3D=20
new
  Zend_Controller_Router_Route(':action/*',
					array('action'=3D>'view'));
$router->addRoute('uActionsRoute', =
$userRoute->chain($userActionsRoute));

ZF-6654 was opened for 1.8.1 but doesn't look as if it's received any =
attention.=20

There's a proposed fix but no test case.=20

I don't want to step on anyone's toes (the case is assigned to Ben =
Schlozen) but if it's not being worked on, should I clear it up?=20

Regards,
Carlton=

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 8 Apr 2009 09:29:20 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] 1.8 Components Categories in JIRA

-- Whitcraft, Jon <[email-masked]> wrote
(on Wednesday, 08 April 2009, 08:13 AM -0400):
> I am wondering when the new Component Categories will be created in JIRA for
> the new components in 1.8?

I'll take care of most of those in the next day or so. I know that the
EC2/S3 support and Zend_Navigation need categories; I think most of the
rest already are setup.

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 19 Jan 2010 12:09:05 -0800
From: Chris Thomas <[email-masked]>
To: [email-masked], [email-masked], 
	[email-masked], [email-masked]
Subject: [zf-contributors] Zend_Service_Prowl Ready for Review

Hello All,

I've created a component proposal. It is ready for rewiew. Please check it out.
http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_Prowl+-+Christopher+Thomas
Your comments are welcomed.

Chris

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 8 Oct 2009 21:25:49 +0200
From: Dolf Schimmel <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Code Review

Wasn't this the moment we came up with the idea of a community release mana=
ger?

Dolf
Aka Freeaqingme

On Thu, Oct 8, 2009 at 9:19 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Whitcraft, Jon <[email-masked]> wrote
> (on Thursday, 08 October 2009, 03:11 PM -0400):
>> I have been thinking about the problem that ZF ran into right after 1.9.=
3 was
>> release a few weeks ago and then we had to rush a 1.9.3pl1 into release.=
 =C2=A0Would
>> using a tool such as Crucible from Atlassian help with this problem?
>>
>> What does everyone else think?
>
> In this case, it might not have helped.
>
> There were no tests for the original behavior, and it was not documented
> in the manual either -- it was only documented in passing within the API
> docs.
>
> We may use Crucible in the future (we actually have it setup already),
> but I want to explore a few other options as well.
>
> (My personal experience with Crucible has not been great, but I have
> hope that it can be configured to work better.)
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 28 Nov 2009 07:45:39 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] [FIXED!] Zend_Feed_Reader Assistance Needed (Or
	I'll Go Crazy)

--0-2003587401-1259423139=:64288
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks to everyone on the usual channels (esp. Benjamin Eberlei), the error=
 has been fixed.=0A=0AMy sanity has been preserved...for now ;)=0A=0A P=E1d=
raic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend=
.com=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=0A=0A=0A_____=
___________________________=0AFrom: P=E1draic Brady <[email-masked]=
m>=0ATo: Zend Framework Contributors <[email-masked]>=0ASen=
t: Sat, November 28, 2009 2:30:04 PM=0ASubject: [zf-contributors] Zend_Feed=
_Reader Assistance Needed (Or I'll Go Crazy)=0A=0A=0ABit of an odd reason f=
or this ;). I'm getting a fatal error (see bottom) when running the unit te=
sts for Zend_Feed_Reader (via trunk/tests/Zend/Feed/AllTests.php). After tw=
o hours of staring at gedit without the slightest clue or knock of inspirat=
ion - I've just about exhausted my supply of patience.=0A=0AIf someone is d=
oing any ZF development over the weekend, would truly appreciate any insigh=
t on resolving this. It has me completely stumped.=0A=0AA bit of background=
. The fatal error only occurs from revisions r19280/1. At that time I added=
 a new class Zend_Feed_Reader_Feed_Atom_Source which extends from Zend_Feed=
_Reader_Feed_Atom. As far as I can tell all classes are named and included =
correctly - but that damn fatal error about not finding the class Zend_Feed=
_Reader_FeedAbstract persists. I've verified that r19279 is free of all err=
ors and all unit tests at that time pass.=0A=0AMy final thoughts are that a=
) I'm overlooking the obvious or b) it's a PHP bug. I'm running PHP 5.2.10 =
at the moment on Ubuntu Karmic - no access to another version until Monday =
(not at home). Oh, and for those on Ubuntu the new PHP update made no diffe=
rence when I applied it last night.=0A=0AI half expect this to be an embarr=
assing revelation that I've spent the last day being a total idiot ;).=0A=
=0APaddy=0A=0A=0AFatal error: Class 'Zend_Feed_Reader_FeedAbstract' not fou=
nd in /home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom.ph=
p on line 38=0A=0ACall Stack:=0A    0.0009     110120   1. {main}() /usr/bi=
n/phpunit:0=0A    0.2302    7197488   2. PHPUnit_TextUI_Command::main() /us=
r/bin/phpunit:52=0A    0.2302    7198832   3. PHPUnit_TextUI_Command->run()=
 /usr/share/php/PHPUnit/TextUI/Command.php:147=0A    0.2322    7203088   4.=
 PHPUnit_Runner_BaseTestRunner->getTest() /usr/share/php/PHPUnit/TextUI/Com=
mand.php:168=0A    0.2322    7203496   5. PHPUnit_Runner_BaseTestRunner->lo=
adSuiteClass() /usr/share/php/PHPUnit/Runner/BaseTestRunner.php:112=0A    0=
.2322    7204640   6. PHPUnit_Runner_StandardTestSuiteLoader->load() /usr/s=
hare/php/PHPUnit/Runner/BaseTestRunner.php:170=0A    0.2324    7267184   7.=
 PHPUnit_Util_Fileloader::checkAndLoad() /usr/share/php/PHPUnit/Runner/Stan=
dardTestSuiteLoader.php:102=0A    0.2324    7267680   8. PHPUnit_Util_Filel=
oader::load() /usr/share/php/PHPUnit/Util/Fileloader.php:91=0A    0.2331   =
 7311400   9. include_once('/home/padraic/projects/zf/trunk/tests/Zend/Feed=
/AllTests.php') /usr/share/php/PHPUnit/Util/Fileloader.php:113=0A    0.6806=
   11464144  10. require_once('/home/padraic/projects/zf/trunk/tests/Zend/F=
eed/ReaderTest.php') /home/padraic/projects/zf/trunk/tests/Zend/Feed/AllTes=
ts.php:48=0A    0.7001   11727944  11. require_once('/home/padraic/projects=
/zf/trunk/library/Zend/Feed/Reader.php') /home/padraic/projects/zf/trunk/te=
sts/Zend/Feed/ReaderTest.php:24=0A    0.7180   11966176  12. require_once('=
/home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Rss.php') /ho=
me/padraic/projects/zf/trunk/library/Zend/Feed/Reader.php:30=0A    0.7188  =
 12045672  13. require_once('/home/padraic/projects/zf/trunk/library/Zend/F=
eed/Reader/FeedAbstract.php') /home/padraic/projects/zf/trunk/library/Zend/=
Feed/Reader/Feed/Rss.php:25=0A    0.7200   12176712  14. require_once('/hom=
e/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Entry/Atom.php') /home=
/padraic/projects/zf/trunk/library/Zend/Feed/Reader/FeedAbstract.php:30=0A =
   0.7277   12490040  15. require_once('/home/padraic/projects/zf/trunk/lib=
rary/Zend/Feed/Reader/Extension/Atom/Entry.php') /home/padraic/projects/zf/=
trunk/library/Zend/Feed/Reader/Entry/Atom.php:40=0A    0.9154   17272344  1=
6. require_once('/home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/F=
eed/Atom/Source.php') /home/padraic/projects/zf/trunk/library/Zend/Feed/Rea=
der/Extension/Atom/Entry.php:50=0A    0.9166   17404288  17. require_once('=
/home/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom.php') /h=
ome/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom/Source.php=
:25=0A=0ANote: Just be aware that Zend_Feed_Reader uses no code from Zend_F=
eed (the original component). ZFR uses its own interfaces and abstracts.=0A=
=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survi=
vethedeepend.com=0AOpenID Europe Foundation Irish Representative
--0-2003587401-1259423139=:64288
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Thanks to everyone on the usual channels (esp. Benjamin Eberle=
i), the error has been fixed.<br><br>My sanity has been preserved...for now=
 ;)<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=
=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><span st=
yle=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span style=
=3D"font-style: italic;"><font style=3D"font-family: times new roman,new yo=
rk,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" href=3D"h=
ttp://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><a rel=3D"=
nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.com">http:=
//www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_blank" hr=
ef=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish
 Representative</a><br></font></span></span><div><br></div><div style=3D"fo=
nt-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div=
 style=3D"font-family: times new roman,new york,times,serif; font-size: 12p=
t;"><font face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font-=
weight: bold;">From:</span></b> P=E1draic Brady &lt;[email-masked]=
&gt;<br><b><span style=3D"font-weight: bold;">To:</span></b> Zend Framework=
 Contributors &lt;[email-masked]&gt;<br><b><span style=3D"f=
ont-weight: bold;">Sent:</span></b> Sat, November 28, 2009 2:30:04 PM<br><b=
><span style=3D"font-weight: bold;">Subject:</span></b> [zf-contributors] Z=
end_Feed_Reader Assistance Needed (Or I'll Go Crazy)<br></font><br>=0A<meta=
 http-equiv=3D"x-dns-prefetch-control" content=3D"off"><div style=3D"font-f=
amily: times new roman,new york,times,serif; font-size: 12pt;">Bit of an od=
d reason for this ;). I'm getting a fatal error (see bottom) when running t=
he unit tests for Zend_Feed_Reader (via trunk/tests/Zend/Feed/AllTests.php)=
. After two hours of staring at gedit without the slightest clue or knock o=
f inspiration - I've just about exhausted my supply of patience.<br><br>If =
someone is doing any ZF development over the weekend, would truly appreciat=
e any insight on resolving this. It has me completely stumped.<br><br>A bit=
 of background. The fatal error only occurs from revisions r19280/1. At tha=
t time I added a new class Zend_Feed_Reader_Feed_Atom_Source which extends =
from Zend_Feed_Reader_Feed_Atom. As far as I can tell all classes are named=
 and included correctly - but that damn fatal error about not finding the c=
lass Zend_Feed_Reader_FeedAbstract persists.=0A I've verified that r19279 i=
s free of all errors and all unit tests at that time pass.<br><br>My final =
thoughts are that a) I'm overlooking the obvious or b) it's a PHP bug. I'm =
running PHP 5.2.10 at the moment on Ubuntu Karmic - no access to another ve=
rsion until Monday (not at home). Oh, and for those on Ubuntu the new PHP u=
pdate made no difference when I applied it last night.<br><br>I half expect=
 this to be an embarrassing revelation that I've spent the last day being a=
 total idiot ;).<br><br>Paddy<br><br><br>Fatal error: Class 'Zend_Feed_Read=
er_FeedAbstract' not found in /home/padraic/projects/zf/trunk/library/Zend/=
Feed/Reader/Feed/Atom.php on line 38<br><br>Call Stack:<br>&nbsp;&nbsp;&nbs=
p; 0.0009&nbsp;&nbsp;&nbsp;&nbsp; 110120&nbsp;&nbsp; 1. {main}() /usr/bin/p=
hpunit:0<br>&nbsp;&nbsp;&nbsp; 0.2302&nbsp;&nbsp;&nbsp; 7197488&nbsp;&nbsp;=
 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:52<br>&nbsp;&nbsp;&nbsp=
; 0.2302&nbsp;&nbsp;&nbsp;=0A 7198832&nbsp;&nbsp; 3. PHPUnit_TextUI_Command=
-&gt;run() /usr/share/php/PHPUnit/TextUI/Command.php:147<br>&nbsp;&nbsp;&nb=
sp; 0.2322&nbsp;&nbsp;&nbsp; 7203088&nbsp;&nbsp; 4. PHPUnit_Runner_BaseTest=
Runner-&gt;getTest() /usr/share/php/PHPUnit/TextUI/Command.php:168<br>&nbsp=
;&nbsp;&nbsp; 0.2322&nbsp;&nbsp;&nbsp; 7203496&nbsp;&nbsp; 5. PHPUnit_Runne=
r_BaseTestRunner-&gt;loadSuiteClass() /usr/share/php/PHPUnit/Runner/BaseTes=
tRunner.php:112<br>&nbsp;&nbsp;&nbsp; 0.2322&nbsp;&nbsp;&nbsp; 7204640&nbsp=
;&nbsp; 6. PHPUnit_Runner_StandardTestSuiteLoader-&gt;load() /usr/share/php=
/PHPUnit/Runner/BaseTestRunner.php:170<br>&nbsp;&nbsp;&nbsp; 0.2324&nbsp;&n=
bsp;&nbsp; 7267184&nbsp;&nbsp; 7. PHPUnit_Util_Fileloader::checkAndLoad() /=
usr/share/php/PHPUnit/Runner/StandardTestSuiteLoader.php:102<br>&nbsp;&nbsp=
;&nbsp; 0.2324&nbsp;&nbsp;&nbsp; 7267680&nbsp;&nbsp; 8. PHPUnit_Util_Filelo=
ader::load() /usr/share/php/PHPUnit/Util/Fileloader.php:91<br>&nbsp;&nbsp;&=
nbsp;=0A 0.2331&nbsp;&nbsp;&nbsp; 7311400&nbsp;&nbsp; 9. include_once('/hom=
e/padraic/projects/zf/trunk/tests/Zend/Feed/AllTests.php') /usr/share/php/P=
HPUnit/Util/Fileloader.php:113<br>&nbsp;&nbsp;&nbsp; 0.6806&nbsp;&nbsp; 114=
64144&nbsp; 10. require_once('/home/padraic/projects/zf/trunk/tests/Zend/Fe=
ed/ReaderTest.php') /home/padraic/projects/zf/trunk/tests/Zend/Feed/AllTest=
s.php:48<br>&nbsp;&nbsp;&nbsp; 0.7001&nbsp;&nbsp; 11727944&nbsp; 11. requir=
e_once('/home/padraic/projects/zf/trunk/library/Zend/Feed/Reader.php') /hom=
e/padraic/projects/zf/trunk/tests/Zend/Feed/ReaderTest.php:24<br>&nbsp;&nbs=
p;&nbsp; 0.7180&nbsp;&nbsp; 11966176&nbsp; 12. require_once('/home/padraic/=
projects/zf/trunk/library/Zend/Feed/Reader/Feed/Rss.php') /home/padraic/pro=
jects/zf/trunk/library/Zend/Feed/Reader.php:30<br>&nbsp;&nbsp;&nbsp; 0.7188=
&nbsp;&nbsp; 12045672&nbsp; 13. require_once('/home/padraic/projects/zf/tru=
nk/library/Zend/Feed/Reader/FeedAbstract.php')=0A /home/padraic/projects/zf=
/trunk/library/Zend/Feed/Reader/Feed/Rss.php:25<br>&nbsp;&nbsp;&nbsp; 0.720=
0&nbsp;&nbsp; 12176712&nbsp; 14. require_once('/home/padraic/projects/zf/tr=
unk/library/Zend/Feed/Reader/Entry/Atom.php') /home/padraic/projects/zf/tru=
nk/library/Zend/Feed/Reader/FeedAbstract.php:30<br>&nbsp;&nbsp;&nbsp; 0.727=
7&nbsp;&nbsp; 12490040&nbsp; 15. require_once('/home/padraic/projects/zf/tr=
unk/library/Zend/Feed/Reader/Extension/Atom/Entry.php') /home/padraic/proje=
cts/zf/trunk/library/Zend/Feed/Reader/Entry/Atom.php:40<br>&nbsp;&nbsp;&nbs=
p; 0.9154&nbsp;&nbsp; 17272344&nbsp; 16. require_once('/home/padraic/projec=
ts/zf/trunk/library/Zend/Feed/Reader/Feed/Atom/Source.php') /home/padraic/p=
rojects/zf/trunk/library/Zend/Feed/Reader/Extension/Atom/Entry.php:50<br>&n=
bsp;&nbsp;&nbsp; 0.9166&nbsp;&nbsp; 17404288&nbsp; 17. require_once('/home/=
padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom.php')=0A /home=
/padraic/projects/zf/trunk/library/Zend/Feed/Reader/Feed/Atom/Source.php:25=
<br><br>Note: Just be aware that Zend_Feed_Reader uses no code from Zend_Fe=
ed (the original component). ZFR uses its own interfaces and abstracts.<br>=
<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><font style=3D"=
font-family: times new roman,new york,times,serif;" size=3D"3"><span style=
=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><span style=3D=
"font-style: italic;"><font style=3D"font-family: times new roman,new york,=
times,serif;" size=3D"3"><span><a target=3D"_blank" href=3D"http://blog.ast=
rumfutura.com">http://blog.astrumfutura.com</a></span><br><span><a target=
=3D"_blank" href=3D"http://www.survivethedeepend.com">http://www.survivethe=
deepend.com</a></span><br><a rel=3D"nofollow" target=3D"_blank" href=3D"htt=
p://www.openideurope.eu/">OpenID Europe Foundation Irish Representative</a>=
<br></font></span></span><div><br></div>=0A=0A</div><meta http-equiv=3D"x-d=
ns-prefetch-control" content=3D"on"></div></div></div></body></html>
--0-2003587401-1259423139=:64288--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: "Wil Sinclair" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 6 Apr 2009 22:07:01 +0200
Subject: Re: [zf-contributors] 1.8 PR feature list and *acknowledgements*

My most important additions for 1.8 are:

* several improvements to Zend_File_Transfer and Zend_Form_Element_File, 
contributed by Thomas Weidner
* added file upload progress to Zend_File_Transfer, contributed by Thomas 
Weidner
* added 84 new IDN's and completly reworked Zend_Validate_Hostname, 
contributed by Thomas Weidner
* added locale support to Zend_Validate_Int and Zend_Validate_Float, 
contributed by Thomas Weidner
* added phonecode support to Zend_Locale, contributed by Thomas Weidner
* Zend_Validate_Iban, contributed by Thomas Weidner
* Zend_Validate_File_WordCount, contributed by Thomas Weidner
* Zend_Filter_Encrypt, contributed by Thomas Weidner
* Zend_Filter_Decrypt, contributed by Thomas Weidner
* added logging support to Zend_Translate, contributed by Thomas Weidner
* added documentation of all Zend_Validate messages, contributed by Thomas 
Weidner

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Wil Sinclair" <[email-masked]>
To: "Robin Skoglund" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 06, 2009 8:02 PM
Subject: RE: [zf-contributors] 1.8 PR feature list and *acknowledgements*

I believe Zend_Navigation is in if the minor changes that we have
recommended are made. Matthew can tell you more. It is a really sweet
component, BTW. J

,Wil

From: Robin Skoglund [mailto:[email-masked]]
Sent: Monday, April 06, 2009 11:02 AM
To: Wil Sinclair
Cc: [email-masked]
Subject: Re: [zf-contributors] 1.8 PR feature list and
*acknowledgements*

On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <[email-masked]> wrote:

NOTE: For this release, we'd like to try something new in the feature
list- actually acknowledging the significant contributions that y' all
have made. J The format would be like this:

* Zend_Application, contributed by Matthew Weier O'Phinney and Ben
Scholzen

,Wil

Hi, I haven't gotten any answer on whether Zend_Navigation will be
included in the PR, but here goes:

* Zend_Navigation, contributed by Robin Skoglund

        robinsk

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 4 May 2009 10:26:55 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Planning ZF 1.9

Greetings, all!

Now that 1.8.0 is out the door, I have a couple of topics to bring up.

First, if you are fixing issues in trunk, please be sure to merge them
to the 1.8 release branch so that they will be available for the next
mini release (1.8.1). If you do not know how to do so, please contact
somebody on #zftalk.dev or on this list for help.

Second, we're starting to plan 1.9.0. I went through the various
proposals that are in incubator, or where developers pinged me to merge
to trunk too late for the 1.8.0 cut-off, and we have a huge list.

If you are an author on one of these proposals, or interested in helping
complete them, please reply to this message. I'd like to see *all* of
these features for 1.9.0, and I think the work is probably 75% done if
not more by this point.

Thanks as usual for your contributions!

List follows:

 * Documentation re-organization
    * Versioned documentation
 * Zend_Controller_Router_Route_Rest
 * Zend_Db_Table plugin support (mostly done)
 * Zend_Db persistent connections
 * Zend_Dojo
    * Build layer support (done except for docs)
    * Extended dijit support
    * Tree support for Zend_Dojo_Data (?)
 * Zend_Feed_Reader (in progress; not sure of status)
 * Zend_Form multipage action helper (in progress; not sure of status)
 * Zend_Ldap (done in incubator)
 * Zend_Log factory
 * Zend_Log_Writer_Syslog (done in incubator?)
 * Zend_Oauth (in progress? not sure of status)
 * Zend_OpenId 2.0 support and Zend_Yadis (in progress? not sure of status)
 * Zend_Queue (done in incubator)
 * Zend_Test_PHPUnit database support (in progress)
 * Zend_View_Helper_BaseUrl (done in incubator)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Fri, 3 Apr 2009 12:58:56 -0700
From: "Wil Sinclair" <[email-masked]>
To: "Wil Sinclair" <[email-masked]>, <[email-masked]>,
	<[email-masked]>
Subject: RE: [zf-contributors] Proper place to report incubator
	issues/requests?

I've implemented this proposal and moved all incubator components out of =
the production IT project. Well, except Zend_Tool and Zend_Application, =
which are about to get promoted anyways. Now, when your proposals are =
approved and you request SVN access to commit the code, we will create a =
component here: http://tinyurl.com/dysvmz

,Wil

From: Wil Sinclair [mailto:[email-masked]]=20
Sent: Tuesday, March 24, 2009 1:37 PM
To: [email-masked]; [email-masked]
Subject: RE: [zf-contributors] Proper place to report incubator =
issues/requests?

Hey AJ, I've been meaning to answer this one for days, so I'm the cause =
of the unresponsiveness here. ;) With a recent release of JIRA, it =
became easy to migrate issues between projects. I propose we create a =
separate project for incubator that uses the same issue scheme as the ZF =
project with components that are currently in incubator. We would then =
make migrating these issues part of promoting the component to trunk.
If there are no issues or better suggestions, I'll implement this =
proposal tomorrow.

,Wil

From: [email-masked] [mailto:[email-masked]] On Behalf Of A.J. =
Brown
Sent: Wednesday, March 18, 2009 11:05 PM
To: [email-masked]
Subject: [zf-contributors] Proper place to report incubator =
issues/requests?

Hey guys,

I have some requests I want to file for a component currently in the =
standard incubator (specifically Zend_Queue).=A0 Where's the place to do =
so?

--=20
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Eric Clemmons <[email-masked]>
Date: Mon, 22 Mar 2010 10:21:23 -0500
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Status: 22-Mar-2010 - Git organization

So, would a hypothetical (Github) workflow be as follows?

1.  Fork Matthew's ZF repo
2.  Create local branch for adding feature (ie, OAuth2.0 support)
3.  Make atomic commits for unit tests, code changes, and new =
documentation
4.  Push branch to personal repo
5.  Issue a pull request for said feature
6.  Matthew runs a script that verifies my Github username against the =
CLAs, subsequently adds the remote and pulls the feature branch.

Sounds like you'll be really busy, Matthew.

I'm sure the majority of contributors would not have direct write access =
to the Zend repo, which means the rest of the requests will have to be =
pull requests and properly QA'd prior to merging.

-Eric

On Mar 22, 2010, at 7:36 AM, Matthew Weier O'Phinney wrote:

> Greetings, all --
>=20
> Based on the wiki and the poll on this list, it looks like it makes
> sense to move forward with git. We're still trying to iron on some
> details about how this will work, but some details are falling into
> place.
>=20
> First, the things we plan:
>=20
> * Git will be hosted on the ZF servers. This is so that we can have
>   full control over hooks (i.e., no network latency from web hooks),
>   integrate with other tools (e.g. viewgit, JIRA, etc.), and more. We
>   will offer both anonymous access as well as selective writable
>   access.
>=20
>   Some will say, "why not just use Github?" The above does not =
preclude
>   using github in any way; git allows you to specify multiple remotes
>   from your repository. I already plan to have a mirror of my personal
>   repo on github, as well as push to the ZF repo from the same
>   location. This will allow people to use some of githubs powerful
>   features such as pull queues while still allowing us to retain some
>   control over the repository. (It also insulates us from githubs
>   growing pains a bit -- I love github, but they are certainly
>   suffering from rapid growth the last few months!)
>=20
> * We plan to have a read-only subversion mirror of the git repository.
>   This will allow those using svn:externals to continue to do so, as
>   well as allow folks more familiar with svn to continue to provide
>   patches.
>=20
> Next, things we're still researching:
>=20
> * How to handle contributions. Since we require a signed CLA, we need
>   some way of verifying that a patch came from an author who has =
signed
>   the CLA. There have been some suggestions that this may be possible
>   with some sort of pre-commit verifications when committing to the
>   master repository (or when someone with commit privileges commits to
>   their own repository). We're still researching how this might be
>   implemented.
>=20
> * Submodules...
>   For those unfamiliar with git submodules, they are roughly =
equivalent
>   to svn:externals. I say "roughly", because they differ in many ways:
>   they have to be manually initialized on each person's repository
>   (though they can be defined in the master repository); they need to
>   be manually updated periodically (unlike svn:externals, where =
anytime
>   you do an "svn up", it also syncs the external); etc.
>=20
>   They are quite powerful, however, and give us the ability to offer a
>   "lean" initial checkout, allowing developers to sync in only the
>   submodules they plan to utilize or commit to.
>=20
>   On this note, I've fielded a number of suggestions. Some were
>   suggesting the library directory be its own submodule, some =
suggested
>   all top-level directories be their own submodule, etc. I've done =
some
>   experimentation, and now propose the following structure:
>=20
>    MAIN REPO:
>        INSTALL.txt
>        LICENSE.txt
>        README.txt
>        bin/
>        library
>        tests/
>        documentation/manual/
>            Makefile
>            README.txt
>            en/
>    SUBMODULES:
>        demos/
>        resources/
>        tools/
>        documentation/manual/:
>            all languages except "en"
>=20
>   Now, for an explanation of the "whys" behind this. As contributors,
>   it's important to make atomic commits: your code fix should also
>   include a corresponding unit test, and potentially a documentation
>   commit as well. If we split the library and tests directories out
>   into their own submodules, we cannot do so; the code and test must =
be
>   committed separately, which is (a) more work, and (b) unintuitive.
>   The same goes for related documentation commits.
>=20
>   Translations, on the other hand, are usually managed in a
>   per-language capacity, flowing from English to the target language.
>   Most developers do not need the docbook source for anything but =
their
>   target language and English (the latter because it's used for
>   fallbacks, and because it contains the build scripts). While we
>   potentially lose the history of an "svn cp", I think this
>   organization provides reasonable benefits.
>=20
>   Finally, the demos, resources, and tools (the latter is a new
>   directory) are all "opt-in" items -- if you need them, you can pull
>   them in; if you don't, there's no reason to.
>=20
> I'd love to get some feedback on the incomplete items. I think the
> submodule layout I've come up with makes the most sense for =
contributors
> (and based on testing, it's the cleanest and simplest way I've found =
to
> accomplish most common development tasks on our tree), but am open to
> further suggestions. If you have any ideas on handling ACLs, I'd love =
to
> hear them, and sooner rather than later!
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 17:20:12 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

-- Ben Scholzen 'DASPRiD' <[email-masked]> wrote
(on Friday, 26 February 2010, 08:56 PM +0100):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ben Scholzen 'DASPRiD' wrote on 26.02.2010 20:53:
> > Matthew Weier O'Phinney wrote on 26.02.2010 14:59:
> >>  * To package individual components, we need some way to determine
> >>    dependencies. Currently, require_once statements can help with that,
> >>    but stripping them makes this harder. My solution is to add @uses
> >>    annotations at the class docblock level. This assists the API docs,
> >>    but also should make it possible to use automated scanners to
> >>    determine dependencies.
> > 
> > The idea is in fact better than tracking depencies through require_once
> > calls, since there were still depencies via autoloading, which thus can
> > be resolved via the @uses tag.
> 
> Tho, you should also take @usedby into your consideration, see:
> http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.uses.pkg.html
> 
> @usedby may be useful, if there is one parent class, but many sub
> classes. refering to the child class is not possible, as there are many,
> so the childs have refer to the parent.

Sweet -- that answers one of the issues I was having (adapter/plugin
classes). :)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Wed, 8 Apr 2009 10:46:33 +0200
Subject: Re: [zf-contributors] New Component proposal

The solution could be to have two types of adapters.
One frontend adapter for the credit card type, and a backend adapter for the 
payment provider.

Because a payment provider may access multiple credit card types, and a 
credit card type may access multiple payment provider.
You could automate this by having a list of commonly used payment providers 
per country for example. There are several methods how this could be 
archived.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Vadim Gabriel" <[email-masked]>
To: "Thomas Weidner" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 08, 2009 9:35 AM
Subject: Re: [zf-contributors] New Component proposal

> Thanks Thomas, This sounds like a great approach. I assume using the same
> method for all other providers such as moneybookers, 2checkout etc. To be
> able to process credit cards there will be a need to use some sort of
> provider, For example here in Israel we use Tranzilla as our credit card
> processing provider, I don't think that processing a credit card can be 
> done
> without using one of the commonly used providers, So what would be the 
> point
> in creating the adapter class per credit card type, Instead of creating it
> per payment provider?
>
> I am eager to write down the proposal already, I just can't seem to enter
> the JIRA since i don't remember my password (and waiting for Matthew to 
> take
> a look at my email).
>
> Anyhow the information is much apprecited and helpful. Thanks.
>
> On Wed, Apr 8, 2009 at 10:29 AM, Thomas Weidner 
> <[email-masked]>wrote:
>
>> Vadim,
>>
>> I would go for a adapter plugin.
>> This OOP approach is used very commonly through the complete framework.
>>
>> So all base functions are defined in the base class and it handles how 
>> this
>> calls are delegated to the set adapter.
>>
>> And you only have to create one adapter per each provider
>> (Zend_Payment_Adapter_Visa / Zend_Payment_Adapter_Mastercard /
>> Zend_Payment_Adapter_PayPal and so on). Your use will still only have to
>> handle only the base class without to know about the adapter details.
>>
>> For example:
>> $pay = new Zend_Payment($myOptions);
>> $pay->checkPayment($data);
>> $pay->transferMoney();
>>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com
>>
>> ----- Original Message ----- From: "Vadim Gabriel" <[email-masked]>
>> To: "Ben Scholzen 'DASPRiD'" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Wednesday, April 08, 2009 7:30 AM
>> Subject: Re: [zf-contributors] New Component proposal
>>
>>
>>
>>  Hey,
>>>
>>> Thanks, For the help with the password thing, I will email Matthew.
>>>
>>> About the component, I have no problem in writing a unified API, My full
>>> time job is building Ecommerce stores, So i have quite a log of code
>>> already
>>> written that utilize all sort of payment providers, I could probably 
>>> write
>>> down the ones i have worked with and completely sure that i will be able
>>> to
>>> include them in the unifed API component. The thing is i don't know 
>>> where
>>> to
>>> start really, Where do i open a proposal? What do i need to write down 
>>> in
>>> there?
>>>
>>> For the unified thing, I was thinking on creating a seperate class for
>>> every
>>> payment provider, Like Zend_Payment_Paypal, Zend_Payment_2Checkout etc,
>>> Would that work? or does it have to be just one class and using a
>>> constructor method to initialize the required payment provider class? 
>>> Such
>>> as
>>>
>>> $paypal = new Zend_Payment('paypal');
>>> $2checkout = new Zend_Payment('2checkout');
>>>
>>> I can do either, Which ever sounds better is fine with me.
>>>
>>> Thanks again for the help.
>>>
>>> Vince.
>>>
>>> On Tue, Apr 7, 2009 at 11:57 PM, Ben Scholzen 'DASPRiD' 
>>> <[email-masked]
>>> >wrote:
>>>
>>>  -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> You may probably ask Matthew or Wil about the password thingy.
>>>>
>>>> Then, to your proposal:
>>>> There were some proposals for payment components, but mostly the just
>>>> included single payment methods, and did not cover multiple ones. We
>>>> discussed that a few times, and what we need is a component which 
>>>> offers
>>>> (if possible) a unified API for all payment providers. When you are
>>>> willing to do so, feel free to get on with your proposal, I will follow
>>>> it with interest.
>>>>
>>>> Regards,
>>>> Ben
>>>> ...................................
>>>> :  ___   _   ___ ___ ___ _ ___    :
>>>> : |   \ /_\ / __| _ \ _ (_)   \   :
>>>> : | |) / _ \\__ \  _/   / | |) |  :
>>>> : |___/_/:\_\___/_| |_|_\_|___/   :
>>>> :........:........................:
>>>> : Web    : http://www.dasprids.de :
>>>> : E-mail : [email-masked]       :
>>>> : Jabber : [email-masked]     :
>>>> : ICQ    : 105677955              :
>>>> :........:........................:
>>>>
>>>>
>>>> Vadim Gabriel schrieb:
>>>> > Hey,
>>>> >
>>>> > I have never added a new proposal and searched the wiki about how to
>>>> > make those. I found this "Image" that displays the work flow of 
>>>> > adding
>>>> > a
>>>> > new component, From opening a new proposal in the wiki upto getting 
>>>> > it
>>>> > approved by the Zend Team.
>>>> > I have a few problems tough.
>>>> >
>>>> > First i have lost my password, And now i can't access JIRA. I already
>>>> > signed the CLA, And would have reset my password, I just couldn't 
>>>> > find
>>>> > the lost password feature anywhere. Do i need to ask someone to reset 
>>>> >  >
>>>> it
>>>> > for me?
>>>> > Second, Where and how do i start a new Wiki page about the component 
>>>> > i
>>>> > would like to contribute. Do i need to add anything special like >
>>>> special
>>>> > information about it, Besides the usual description and technical
>>>> > specifications?
>>>> > Third, My component that i would like to share is 
>>>> > Zend_Payments_Paypal
>>>> > class that allows to use paypal. This is the only thing i made so far 
>>>> >  >
>>>> by
>>>> > myself for Zend Framework but since i am working a lot with Ecommerce 
>>>> > i
>>>> > will probably be writting more payment transfer options such as 
>>>> > Google
>>>> > checkout, Moneybookers, 2checkout and more. I would like to know if >
>>>> this
>>>> > is something that might interest people and actually make it's way to
>>>> > the library rather then the archive?
>>>> >
>>>> > Thanks, Vince.
>>>> >
>>>> > --
>>>> > Vincent Gabriel.
>>>> > Lead Developer, Senior Support.
>>>> > Zend Certified Engineer.
>>>> > Zend Framework Certified Engineer.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>>
>>>> iEYEARECAAYFAknbvj4ACgkQ0HfT5Ws789AIsQCffrVw9VETkPXTCgn/i9yD9XHh
>>>> FwoAnRZ2/VyJngOvolSD2Vg7ww7OLgLe
>>>> =Qkwd
>>>> -----END PGP SIGNATURE-----
>>>>
>>>>
>>>
>>>
>>> --
>>> Vincent Gabriel.
>>> Lead Developer, Senior Support.
>>> Zend Certified Engineer.
>>> Zend Framework Certified Engineer.
>>>
>>>
>>
>
>
> -- 
> Vincent Gabriel.
> Lead Developer, Senior Support.
> Zend Certified Engineer.
> Zend Framework Certified Engineer.
> 

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Fri, 26 Feb 2010 10:26:03 +0100
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

On Friday 26 February 2010 09:27:12 Jurri=C3=ABn Stutterheim wrote:
>Unfortunately, (tooling) support for Git on Windows is severely lacking.

This might have been a valid arguement a couple of years ago but not anymor=
e.=20

Msysgit and tortoiseGit offer solid git support for the Windows desktop and=
=20
Shawn Pearce has done an excellent job with the JGit library which serves a=
s=20
the basis for quite mature Netbeans and Eclipse plugins.

=2D-=20
=E2=80=9CWhat can be asserted without proof can be dismissed without proof.=
=E2=80=9D
=2D Christopher Hitchens

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 17 Apr 2009 11:19:54 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Code Freeze starts Monday

-- Ben Scholzen 'DASPRiD' <[email-masked]> wrote
(on Friday, 17 April 2009, 04:58 PM +0200):
> Shouldn't that mid-week release be called RC instead of beta? Beta
> usually comes before a PR. 

... and beta usually comes after alpha (which is what the preview
release was) and before an RC. An RC is not always necessary, but a beta
indicating final API is usually a good idea. That's what I'm shooting
for here.

> And well, I'll get the documentation for Zend_Tag done this weekend,
> so you can promote it to trunk on monday.  

Excellent!

> Also trying to get a screencast about Zend_Tag done for the 1.8
> release, but that's another story.

When you have it up, ping me, and I'll get Eli to link to it from
DevZone. :)

> Matthew Weier O'Phinney schrieb:
> > Greetings, all!
> > 
> > 1.8 is shaping up nicely! We've had a lot of good feedback since the
> > preview release last week, and a number of other components have become
> > stable since then and have either been pushed to trunk or are ready to
> > review for inclusion in trunk.
> > 
> > We are considering doing a beta release mid-week next week. This will
> > ensure that the API stabilizes, and give developers and reviewers a real
> > feel for the final 1.8 product. 
> > 
> > As such, I'm announcing a code freeze, effective 14:00 UTC on Monday, 
> > 20 April 2009. (This is when we have our daily internal meeting.)
> > 
> > If you have components that you have completed in incubator and want
> > reviewed for inclusion, please get them in before then. Please be aware
> > that if the component test coverage or documentation are deemed
> > incomplete or unsatisfactory at that time, they will *NOT* be included
> > in the final 1.8 release. 
> > 
> > If you are working on a new component in the trunk, please have the
> > public API for those components stable by that time.
> > 
> > Again, code freeze is at 14:00 UTC on Monday, 20 April 2009.
> > 
> > Thanks again, and keep up the great work!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 05 Jul 2009 18:33:44 +0200
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] Two Proposals Ready for Review

As far as I know, there won't. 2.0 will not only be a rewrite for PHP
5.3, but also have major refactoring in some components. Maintaining two
parallel releases afterwards wouldn't really be realistic.
...................................
:  ___   _   ___ ___ ___ _ ___    :
: |   \ /_\ / __| _ \ _ (_)   \   :
: | |) / _ \\__ \  _/   / | |) |  :
: |___/_/:\_\___/_| |_|_\_|___/   :
:........:........................:
: Web    : http://www.dasprids.de :
: E-mail : [email-masked]       :
: Jabber : [email-masked]     :
: ICQ    : 105677955              :
:........:........................:

Ralf Eggert schrieb:
> Thanks Benjamin,
> 
> Benjamin Eberlei schrieb am 05.07.2009 17:31:
>> to my knowledge there will definately be a 1.10, and even a slight chance that 
>> there will be a 1.11
> 
> Ok, but will 2.0 be published after 1.10 or 1.11. or will be both major
> release be managed parallel?
> 
> Thanks and best regards,
> 
> Ralf

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 20:44:37 +0100
From: Pieter Kokx <[email-masked]>
To: Diego Henrique Oliveira <[email-masked]>
CC: Marc Bennewitz <[email-masked]>, 
	[email-masked], Kevin McArthur <[email-masked]>, 
	Dolf Schimmel <[email-masked]>
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

This is a multi-part message in MIME format.
--------------070703020607080207000908
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Really, this is just a micro optimalisation from what most people wont
benefit at all!

This only makes the code more complicated, and this way you are
'optimizing' ZF where it doesn't really count.

Regards,

Pieter Kokx
PHP Developer
Zend Framework developer

Diego Henrique Oliveira schreef:
> @Kevin
> I do not think this solution could complicate the API. It's just
> another option for the developer, he can use or not.
>
> @Dolf
> I have not done benchmarks, but in a query that was returning 20
> fields now returns only 4 (which is the answer for my authentication).
>
> @Marc
> Thanks for the tip, I will change in my code.
>
>
> Cheers.
>
> Diego
>
>
> ------------------------------------------------------------------------
> *From:* Marc Bennewitz <[email-masked]>
> *To:* [email-masked]
> *Sent:* Mon, January 25, 2010 5:14:14 PM
> *Subject:* Re: [zf-contributors] changes in component
> Zend_Auth_Adapter_DbTable
>
> How would you create a reproducible benchmark ?
>   - Is the DB local or reading from net ?
>   - how many fields are in this table and which type ?
> (In past I saw user tables have ALL configuration in it, incl. css
> styles.)
>
> In my opinion this would be a good solution if the default is set to *.
>
> @Diego
> $fields[] = $credentialExpression is more high-performance than
> array_push( $fields, $credentialExpression );
>
> --
> Marc
>
> Am 25.01.2010 18:45, schrieb Dolf Schimmel:
> > I would indeed like to see some (reproducable) benchmarks that show a
> > significant improvement
> >
> > -- Freeaqingme
> >
> > On Mon, Jan 25, 2010 at 5:39 PM, Kevin McArthur <[email-masked]
> <mailto:[email-masked]>> wrote:
> > 
> >> The performance difference between a * and selected columns will be
> almost
> >> nil.... short of something like an unmaterialized and complex view
> [in the
> >> db sense] that is.
> >>
> >> I'd think this would add a fair amount of complication to the api and
> >> codebase for what will be, for most people, practically zero benefit.
> >> In-fact, for most, the additional requirement of a couple method
> invocations
> >> and string operations will likely negate the effect of not
> returning the
> >> extraneous columns in the first place.
> >>
> >> I'd vote no on this change.
> >>
> >> Kevin
> >>
> >>
> >> Diego Henrique Oliveira wrote:
> >>   
> >>> In the adapter DbTable, the generated query to the database is a
> 'select
> >>> *', and as it was being a bottleneck in my application (users
> table with
> >>> many fields), i made these changes in the component
> >>> Zend_Auth_Adapter_DbTable.
> >>>
> >>>
> >>> class Zend_Auth_Adapter_DbTable
> >>> {
> >>>      protected $_returnedFields;
> >>>      public function setReturnedFields( array $fields )
> >>>    {
> >>>        $this->_returnedFields = $fields;
> >>>    }
> >>>      public function getReturnedFields()
> >>>    {
> >>>        if (is_null($this->_returnedFields))
> >>>        {
> >>>            return array('*');
> >>>        }
> >>>        return $this->_returnedFields;
> >>>    }
> >>>      /**
> >>>    * _authenticateCreateSelect() - This method creates a
> Zend_Db_Select
> >>> object that
> >>>    * is completely configured to be queried against the database.
> >>>    *
> >>>    * @return Zend_Db_Select
> >>>    */
> >>>    protected function _authenticateCreateSelect()
> >>>    {
> >>>        // build credential expression
> >>>        if (empty($this->_credentialTreatment) ||
> >>> (strpos($this->_credentialTreatment, '?') === false)) {
> >>>            $this->_credentialTreatment = '?';
> >>>        }
> >>>
> >>>        $credentialExpression = new Zend_Db_Expr(
> >>>            '(CASE WHEN ' .
> >>>            $this->_zendDb->quoteInto(
> >>>               
> $this->_zendDb->quoteIdentifier($this->_credentialColumn,
> >>> true)
> >>>                . ' = ' . $this->_credentialTreatment,
> $this->_credential
> >>>                )
> >>>            . ' THEN 1 ELSE 0 END) AS '
> >>>            . $this->_zendDb->quoteIdentifier(
> >>>                $this->_zendDb->foldCase('zend_auth_credential_match')
> >>>                )
> >>>            );
> >>>
> >>>        // get select
> >>>        $fields  = $this->getReturnedFields();
> >>>        array_push( $fields, $credentialExpression );
> >>>        $dbSelect = clone $this->getDbSelect();
> >>>        $dbSelect->from($this->_tableName, $fields)
> >>>
> >>> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn,
> true) . ' =
> >>> ?', $this->_identity);
> >>>
> >>>        return $dbSelect;
> >>>    }
> >>>  }
> >>>
> >>>
> >>>
> >>> What you guys think about these changes? And should I submit them
> to the
> >>> project?
> >>>
> >>>
> >>> Cheers
> >>>
> >>> Diego
> >>> http://diegoholiveira.com
> >>>
> >>>     
> >>   
> > 
>

--------------070703020607080207000908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Really, this is just a micro optimalisation from what most people wont
benefit at all!<br>
<br>
This only makes the code more complicated, and this way you are
'optimizing' ZF where it doesn't really count.<br>
<pre class="moz-signature" cols="72">Regards,

Pieter Kokx
PHP Developer
Zend Framework developer
</pre>
<br>
<br>
Diego Henrique Oliveira schreef:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <style type="text/css"><!-- DIV {margin:0px;} --></style>
  <div
 style="font-family: Courier New,courier,monaco,monospace,sans-serif; font-size: 10pt;">
  <div><span style="font-family: verdana,helvetica,sans-serif;"><span
 style="font-family: verdana,helvetica,sans-serif;">@Kevin<br>
I do not think this solution could complicate the API. It's just
another option for the developer, he can use or not.<br>
  <br>
@Dolf<br>
I have not done benchmarks, but in a query that was returning 20 fields
now returns only 4 (which is the answer for my authentication).<br>
  <br>
@Marc<br>
Thanks for the tip, I will change in my code.</span><br>
  <br>
  </span><br>
  <span style="font-family: verdana,helvetica,sans-serif;">Cheers.<br>
  <br>
Diego<br>
  </span><br>
  </div>
  <div
 style="font-family: Courier New,courier,monaco,monospace,sans-serif; font-size: 10pt;"><br>
  <div
 style="font-family: verdana,helvetica,sans-serif; font-size: 10pt;"><font
 face="Tahoma" size="2">
  <hr size="1"><b><span style="font-weight: bold;">From:</span></b>
Marc Bennewitz <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
  <b><span style="font-weight: bold;">To:</span></b>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
  <b><span style="font-weight: bold;">Sent:</span></b> Mon, January 25,
2010 5:14:14 PM<br>
  <b><span style="font-weight: bold;">Subject:</span></b> Re:
[zf-contributors] changes in component Zend_Auth_Adapter_DbTable<br>
  </font><br>
How would you create a reproducible benchmark ?<br>
&nbsp; - Is the DB local or reading from net ?<br>
&nbsp; - how many fields are in this table and which type ?<br>
(In past I saw user tables have ALL configuration in it, incl. css
styles.)<br>
  <br>
In my opinion this would be a good solution if the default is set to *.<br>
  <br>
@Diego<br>
$fields[] = $credentialExpression is more high-performance than<br>
array_push( $fields, $credentialExpression );<br>
  <br>
--<br>
Marc<br>
  <br>
Am 25.01.2010 18:45, schrieb Dolf Schimmel:<br>
&gt; I would indeed like to see some (reproducable) benchmarks that
show a<br>
&gt; significant improvement<br>
&gt;<br>
&gt; -- Freeaqingme<br>
&gt;<br>
&gt; On Mon, Jan 25, 2010 at 5:39 PM, Kevin McArthur &lt;<a
 moz-do-not-send="true" ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&nbsp; <br>
&gt;&gt; The performance difference between a * and selected columns
will be almost<br>
&gt;&gt; nil.... short of something like an unmaterialized and complex
view [in the<br>
&gt;&gt; db sense] that is.<br>
&gt;&gt;<br>
&gt;&gt; I'd think this would add a fair amount of complication to the
api and<br>
&gt;&gt; codebase for what will be, for most people, practically zero
benefit.<br>
&gt;&gt; In-fact, for most, the additional requirement of a couple
method invocations<br>
&gt;&gt; and string operations will likely negate the effect of not
returning the<br>
&gt;&gt; extraneous columns in the first place.<br>
&gt;&gt;<br>
&gt;&gt; I'd vote no on this change.<br>
&gt;&gt;<br>
&gt;&gt; Kevin<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Diego Henrique Oliveira wrote:<br>
&gt;&gt;&nbsp; &nbsp; <br>
&gt;&gt;&gt; In the adapter DbTable, the generated query to the
database is a 'select<br>
&gt;&gt;&gt; *', and as it was being a bottleneck in my application
(users table with<br>
&gt;&gt;&gt; many fields), i made these changes in the component<br>
&gt;&gt;&gt; Zend_Auth_Adapter_DbTable.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; class Zend_Auth_Adapter_DbTable<br>
&gt;&gt;&gt; {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; protected $_returnedFields;<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; public function setReturnedFields( array $fields )<br>
&gt;&gt;&gt;&nbsp; &nbsp; {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_returnedFields = $fields;<br>
&gt;&gt;&gt;&nbsp; &nbsp; }<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; public function getReturnedFields()<br>
&gt;&gt;&gt;&nbsp; &nbsp; {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; if (is_null($this-&gt;_returnedFields))<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return array('*');<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; }<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; return $this-&gt;_returnedFields;<br>
&gt;&gt;&gt;&nbsp; &nbsp; }<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; /**<br>
&gt;&gt;&gt;&nbsp; &nbsp; * _authenticateCreateSelect() - This method creates a
Zend_Db_Select<br>
&gt;&gt;&gt; object that<br>
&gt;&gt;&gt;&nbsp; &nbsp; * is completely configured to be queried against the
database.<br>
&gt;&gt;&gt;&nbsp; &nbsp; *<br>
&gt;&gt;&gt;&nbsp; &nbsp; * @return Zend_Db_Select<br>
&gt;&gt;&gt;&nbsp; &nbsp; */<br>
&gt;&gt;&gt;&nbsp; &nbsp; protected function _authenticateCreateSelect()<br>
&gt;&gt;&gt;&nbsp; &nbsp; {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; // build credential expression<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; if (empty($this-&gt;_credentialTreatment) ||<br>
&gt;&gt;&gt; (strpos($this-&gt;_credentialTreatment, '?') === false)) {<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_credentialTreatment = '?';<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $credentialExpression = new Zend_Db_Expr(<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '(CASE WHEN ' .<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $this-&gt;_zendDb-&gt;quoteInto(<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
$this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_credentialColumn,<br>
&gt;&gt;&gt; true)<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . ' = ' . $this-&gt;_credentialTreatment,
$this-&gt;_credential<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; )<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . ' THEN 1 ELSE 0 END) AS '<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; . $this-&gt;_zendDb-&gt;quoteIdentifier(<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
$this-&gt;_zendDb-&gt;foldCase('zend_auth_credential_match')<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; )<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; );<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; // get select<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $fields&nbsp; = $this-&gt;getReturnedFields();<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; array_push( $fields, $credentialExpression );<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $dbSelect = clone $this-&gt;getDbSelect();<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; $dbSelect-&gt;from($this-&gt;_tableName, $fields)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;
-&gt;where($this-&gt;_zendDb-&gt;quoteIdentifier($this-&gt;_identityColumn,
true) . ' =<br>
&gt;&gt;&gt; ?', $this-&gt;_identity);<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; return $dbSelect;<br>
&gt;&gt;&gt;&nbsp; &nbsp; }<br>
&gt;&gt;&gt;&nbsp; }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What you guys think about these changes? And should I
submit them to the<br>
&gt;&gt;&gt; project?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cheers<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Diego<br>
  <span>&gt;&gt;&gt; <a moz-do-not-send="true" target="_blank"
 href="http://diegoholiveira.com">http://diegoholiveira.com</a></span><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; <br>
&gt;&gt;&nbsp; &nbsp; <br>
&gt;&nbsp; <br>
  </div>
  </div>
<!-- cg15.c2.mail.re1.yahoo.com compressed Mon Jan 25 09:31:45 PST 2010 -->
  </div>
  <br>
</blockquote>
</body>
</html>

--------------070703020607080207000908--

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 14:24:34 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

Greetings, all --

Below is a proposal I am making to modify the Zend Framework Coding
Standards conventions for the naming of Interfaces and Abstract classes.

This decision is basically already made, but I'd appreciate any feedback
that you may have on the matter.

Thanks!

The problem
===========
PHP 5.3 introduces namespaces to the PHP language. While this won't have an
impact much on userland code, it will have an impact on library and framework
code, as it provides a useful paradigm for organizing components as well as
simplifying syntax. Instead of having to say things like:

    $analyzer = new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();

we can instead do something like this:

    namespace Zend\Search\Lucene\Analysis\Analyzer;

    $analyzer = new Common_TextNum();

or even:

    namespace Zend\Search\Lucene\Analysis\Analyzer;

    class Common_TextNum extends Common
    {
    }

The problem that arises for Zend Framework has to do with how we name abstract
classes and interfaces. Currently, the final segment of such classes are
expected to end with _Abstract and _Interface, respectively. This will not work
when we migrate to utilize namespaces, for two reasons.

First, and most obviously, 'abstract' and 'interface' are reserved PHP keywords.
As such, in situations such as the following:

    namespace Zend\Controller\Request;

    class Abstract
    {
    }

    // or:

    namespace Zend\Controller\Dispatcher;

    interface Interface
    {
    }

we'll run into issues.

Second, and less obvious, is that perhaps the easiest solution breaks one of the
key principles of namespaces (which are designed to help encapsulate
components). This one's harder to explain, so let's look at examples. Consider a
component such as Zend_Controller_Request. The simplest solution would be to
name the abstract class or interface Zend\Controller\Request, and then have the
various concrete implementations under that namespace:

    namespace Zend\Controller;

    interface Request
    {
    }

    // and concrete ones:

    namespace Zend\Controller\Request;

    class Http
    {
    }

What's the problem here? The interface is not in the same namespace as the
concrete implementations.

Potential solutions and recommendation
======================================
So, how should Zend Framework "solve" these issues? A number of proposals and
recommendations have been floated around, both within ZF circles and in the
greater PHP community. 

Considerations include:

 * Avoiding the use of PHP reserved keywords (already noted).
 * Avoiding Hungarian Notation (i.e., having the name or a portion of the name
   describe its type -- which, to a degree, the current naming conventions
   already violate). (See http://en.wikipedia.org/wiki/Hungarian_Notation, the
   sections "Disadvantages of Systems Hungarian" and "Notable Opinions" for some
   of the arguments against using Hungarian Notation.)

Approaches that have been considered include:

 * Using 'I' to prefix interfaces. This derives from standards in other
   programming languages (.Net and python, in particular). This is just another
   form of Hungarian Notation, however.

 * Using "Interface" or "Abstract" as a class name suffix: RequestInterface,
   RequestAbstract. Again, however this is Hungarian Notation.

 * Using the term "Base" for abstract classes: BaseRequest, RequestBase, Base.
   This is just substituting the word Base for Abstract, however, and is really
   not much different than the above.

 * Use generic, descriptive names indicative of functionality or behavior. As
   examples from the SPL, "Countable", "Iterator", "ArrayObject".  
   
My recommendation is to use the latter, as it solves all considerations. It will
take more thought when naming, but will ensure that components can live in a
self-contained namespace, do not use reserved keywords, and avoid Hungarian
Notation.

Plan for implementation
=======================
I recommend that the Coding Standards documentation be updated to reflect this
approach. 

All new components going into 1.8 and onwards should adopt these standards. In
releases 1.9 and forward, we will begin migrating existing interfaces/abstract
classe. First, new classes/interfaces will be created that follow these
conventions and which extend the originals; later, any type-hinting based on the
original class/interface names will be updated to point to the new names; and
finally, in 2.0, we will remove the old interfaces/abstract classes entirely.

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 29 Jan 2010 16:42:27 +0100
From: H2Lsoft <[email-masked]>
Organization: H2Lsoft
To: [email-masked]
Subject: [zf-contributors] how can I unsuscribe ?

Hi,

Please, how can I unsuscribe ?

thanks

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Tue, 12 Jan 2010 14:38:52 +0100
Subject: Re: [zf-contributors] PHP error in framework docs search results.

On Tuesday 12 January 2010 14:14:00 Matthew Weier O'Phinney wrote:
>Regarding the undefined offset notices, I'll be discussing these with
>Alex, as they're indicative of potential issues in the Lucene component.

I had a bunch of failing tests last night for 1.9.7, some of which I nailed 
down as either local problems or platform/distro issues however I'm still 
getting a bunch of errors and failed tests in Zend_Search_Lucene.

There were 5 errors:

1) Zend_Search_Lucene_SearchTest::testSortingResult
Parameter 1 to array_multisort() expected to be a reference, value given

/data/php5/ZendFramework/library/Zend/Search/Lucene.php:1045
/data/php5/ZendFramework/library/Zend/Search/Lucene/Proxy.php:346

2) Zend_Search_Lucene_SearchTest::testLimitingResult
Parameter 1 to array_multisort() expected to be a reference, value given

/data/php5/ZendFramework/library/Zend/Search/Lucene.php:1045
/data/php5/ZendFramework/library/Zend/Search/Lucene/Proxy.php:346

3) Zend_Search_Lucene_Search23Test::testSortingResult
Parameter 1 to array_multisort() expected to be a reference, value given

/data/php5/ZendFramework/library/Zend/Search/Lucene.php:1045
/data/php5/ZendFramework/library/Zend/Search/Lucene/Proxy.php:346

4) Zend_Search_Lucene_Search23Test::testSortingResultByScore
Parameter 1 to array_multisort() expected to be a reference, value given

/data/php5/ZendFramework/library/Zend/Search/Lucene.php:1045
/data/php5/ZendFramework/library/Zend/Search/Lucene/Proxy.php:346

5) Zend_Search_Lucene_Search23Test::testLimitingResult
Parameter 1 to array_multisort() expected to be a reference, value given

/data/php5/ZendFramework/library/Zend/Search/Lucene.php:1045
/data/php5/ZendFramework/library/Zend/Search/Lucene/Proxy.php:346

--

There were 7 failures:

1) Zend_Search_Lucene_Search23Test::testPraseQuery
Failed asserting that <integer:4> matches expected <integer:3>.

2) Zend_Search_Lucene_Search23Test::testQueryParserKeywordsHandlingTerm
Failed asserting that <integer:9> matches expected <integer:3>.

3) Zend_Search_Lucene_Search23Test::testWildcardQuery
Failed asserting that <integer:9> matches expected <integer:3>.

4) Zend_Search_Lucene_Search23Test::testFuzzyQuery
Failed asserting that <integer:9> matches expected <integer:3>.

5) Zend_Search_Lucene_Search23Test::testInclusiveRangeQuery
Failed asserting that <integer:5> matches expected <integer:3>.

6) Zend_Search_Lucene_Search23Test::testNonInclusiveRangeQuery
Failed asserting that <integer:5> matches expected <integer:3>.

7) Zend_Search_Lucene_Search23Test::testDefaultSearchField
Failed asserting that <integer:5> matches expected <integer:3>.

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Mon, 27 Jul 2009 17:25:10 +0200
Subject: [zf-contributors] Contributor list

Hy all,

we have since several months a contributor list.
http://framework.zend.com/wiki/pages/viewpage.action?pageId=11036

Now for 1.9 it's time again to update this list.
Every contributor/maintainer/component lead is announced to update this list 
with his own informations within the proper component.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com 

nFrom nobody Wed Apr  7 08:46:17 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 23:06:59 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] use statements -- usage?

This problem does not happen to me very often, because usually are
more specific components in sub namespaces that. I'm for aliasing them
all with use statements, since it was decided they must have
meaningful names (such as use Zend\Filter\Int as IntFilter) which can
be understood without problems.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 11:15:27 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

On Mon, Mar 22, 2010 at 3:44 AM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> I'm trying to decide if "direct" (which suggests strategy) or
> "execute" makes more sense for the method name.

Imho direct() has continuity and consistency. I do not know if putting
such a method in an interface will force the user to use
func_get_args(), but I see no other choice.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 15 Sep 2009 08:07:31 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Announcement: Monthly Bug Hunt!

-- Carlton Gibson <[email-masked]> wrote
(on Tuesday, 15 September 2009, 09:01 AM +0100):
> 
> On 14 Sep 2009, at 18:10, P draic Brady wrote:
> 
> 
>     * If you already have commit access, commit the test and fix to the
>       repository, and either resolve the issue or ask somebody from Zend to
>       review and resolve.  Don't forget to merge your changes to the 1.9
>       release branch!
> 
> 
> Just a few questions:
> 
> 1) I'm a bit slow (as I've mentioned before) but, having committed changes back
> to trunk, how exactly does one merge back into the release branch? 

Assuming you've done a single commit, the easiest way is to checkout
both the trunk and branches/release-1.9 trees, and then merge between
them. Let's assume the following directory structure:

    zf/
        trunk/         (checkout of trunk)
        release-1.9/   (checkout of branches/release-1.9)

>From the zf/ directory, do this:

    % svn merge -c <revnum> trunk release-1.9

where <revnum> is the revision number from trunk you want to merge to
the 1.9 branch.

This will merge all changes introduced in that revision into the 1.9
branch. You then commit those:

    % svn ci release-1.9 -m 'ZF-XXXX merge rXYZ to 1.9 release branch'

substituting the appropriate issue ID and revision number, of course.

> 2) The issue tracker has "Resolve" and "Close". Which should we use? (There
> seem to be a lot of resolved issues that have never been closed.)

"Resolve". Issues will be marked as "Closed" when we do a release.

> 3) How much time do you Zend guys realistically have to review fixes? I like to
> have another human review all my code (especially in a _high profile_ project
> like this one :-) but if we're waiting ages for a review on a fix we're
> confident with should we just resolve it? (Should we just harass you? Is their
> a pool of willing reviewers? -- everyone is busy right?) 

During the bug hunt days, harrass us. :)

If you already have commit access, though, then only ask for review if
you're uncertain about the changes you're introducing. And don't limit
yourself to just Zend folks -- ask on #zftalk.dev, and you'll likely
find someone there willing and able to help review as well.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Mihai Bojin <[email-masked]>
Date: Wed, 20 Jan 2010 20:39:57 +0200
Cc: [email-masked]
To: Matthew Ratzloff <[email-masked]>
Subject: Re: [zf-contributors] Zend_Grid component proposal

--Apple-Mail-49-90272804
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The sorting should not be a problem, at least for DbSelect and =
DbTable_Select.
Arrrays should be handled rather easy using array_multisort, the only =
problem is Iterator which can't be actually sorted.

At the moment I have no idea how to handle that besides pulling all the =
data from the Iterator and sorting it, which would be the same as =
passing an array to the Grid.

So probably the Iterator will not have sortable columns.

Any of your ideas and suggestions are welcome !

On Jan 20, 2010, at 7:30 PM, Matthew Ratzloff wrote:

> Just an FYI, you are probably going to hit some limitations with the =
Zend_Paginator adapters that I've been meaning to fix (for, uh, awhile =
now).  When I integrated Ext JS at work, I needed some features like =
sorting that were missing.
>=20
> Since we're now transitioning to GWT and Spring, it's been hard =
finding the time or energy to push those changes back into Zend =
Framework.
>=20
> -Matt
>=20
> On Wed, Jan 20, 2010 at 5:55 AM, Mihai Bojin <[email-masked]> =
wrote:
> Hello Everyone,
>=20
> I submitted a proposal for review and right now I'm waiting for any =
suggestions, advice, opinions and so on :)
>=20
> You can check out the proposal here:
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin
>=20
> Any feedback will be greatly appreciated !
>=20
>=20
> Looking forward to hearing from the community,
>=20
> Mihai Bojin
> Web Developer
> [email-masked]
> [email-masked]
> +4.0721.231.134
>=20

--Apple-Mail-49-90272804
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The =
sorting should not be a problem, at least for DbSelect and =
DbTable_Select.<div>Arrrays should be handled rather easy using =
array_multisort, the only problem is Iterator which can't be actually =
sorted.</div><div><br></div><div>At the moment I have no idea how to =
handle that besides pulling all the data from the Iterator and sorting =
it, which would be the same as passing an array to the =
Grid.</div><div><br></div><div>So probably the Iterator will not have =
sortable columns.</div><div><br></div><div>Any of your ideas and =
suggestions&nbsp;are welcome =
!</div><div><div><br></div><div><br><div><div>On Jan 20, 2010, at 7:30 =
PM, Matthew Ratzloff wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Just an =
FYI, you are probably going to hit some limitations with the =
Zend_Paginator adapters that I've been meaning to fix (for, uh, awhile =
now). &nbsp;When I integrated Ext JS at work, I needed some features =
like sorting that were missing.<div>
<br></div><div>Since we're now transitioning to GWT and Spring, it's =
been hard finding the time or energy to push those changes back into =
Zend Framework.</div><div><br></div><div>-Matt<br><br><div =
class=3D"gmail_quote">
On Wed, Jan 20, 2010 at 5:55 AM, Mihai Bojin <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello Everyone,<br>
<br>
I submitted a proposal for review and right now I'm waiting for any =
suggestions, advice, opinions and so on :)<br>
<br>
You can check out the proposal here:<br>
<a =
href=3D"http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bo=
jin" =
target=3D"_blank">http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+=
-+Mihai+Bojin</a><br>
<br>
Any feedback will be greatly appreciated !<br>
<br>
<br>
Looking forward to hearing from the community,<br>
<br>
Mihai Bojin<br>
Web Developer<br>
<font color=3D"#888888"><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
+4.0721.231.134</font></blockquote></div><br></div>
</blockquote></div><br></div></div></body></html>=

--Apple-Mail-49-90272804--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 18 Nov 2009 09:02:23 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] New Sections for Zend Framework 2.0 Roadmap

--0016e6d77df5a4fc890478a0a9e5
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 17, 2009 at 6:37 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> Hey, all --
>
> There have been several new sections posted to the 2.0 roadmap that I
> want to bring to your attention:
>
>  * Plugins:
>   http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures
>

I commented on this page about plugin creation. There are no guidelines for
the construction process? I think automated Dependency Injection is the way
to go.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d77df5a4fc890478a0a9e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Nov 17, 2009 at 6:37 PM, Matthew Weier O=
&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">matt=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;=
 padding-left: 1ex;">
Hey, all --<br>
<br>
There have been several new sections posted to the 2.0 roadmap that I<br>
want to bring to your attention:<br>
<br>
=A0* Plugins:<br>
 =A0 <a href=3D"http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Archit=
ectures" target=3D"_blank">http://framework.zend.com/wiki/display/ZFDEV2/Pl=
ugin+Architectures</a><br></blockquote><div>=A0<br clear=3D"all"></div></di=
v>I commented on this page about plugin creation. There are no guidelines f=
or the construction process? I think automated Dependency Injection is the =
way to go.<br>
<br>-- <br>Giorgio Sironi<br>Piccolo Principe &amp; Web Engineer<br><a href=
=3D"http://giorgiosironi.blogspot.com">http://giorgiosironi.blogspot.com</a=
><br><a href=3D"http://twitter.com/giorgiosironi">http://twitter.com/giorgi=
osironi</a><br>

--0016e6d77df5a4fc890478a0a9e5--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 10:21:52 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Plugin implementations

Greetings, all --

Per the roadmap, one change we're planning on making is making plugin
usage consistent across components: plugins will implement __invoke(),
which makes them inherently callable.

In our refactoring branch, I've done this now with Zend_Filter. However,
it required a ton of refactoring on the unit tests (had to either call
__invoke() directly, or $filter($value)), and it got me to thinking:

Would it make sense to keep the original interfaces (filter, isValid,
render, etc.), but also implement __invoke() -- having it proxy to the
appropriate interface method?

As an example:

    interface Filter
    {
        public function filter($value);
        public function __invoke($value);
    }

    class Digits implements Filter
    {
        public function filter($value)
        {
            // ... logic...
        }

        public function __invoke($value)
        {
            return $this->filter($value);
        }
    }

The benefits:

 * Fewer changes necessary to existing unit tests
 * interface method names may be more descriptive of intent

Problems:

 * Using __invoke() introduces overhead -- 2 method calls instead of one
 * Redundancy (two methods doing the same thing)
 * A few extra tests to write (to ensure __invoke works as expecte)

After discussion with Ralph and Alex, I'm leaning towards having
__invoke() as an _additional_ method, instead of replacing existing
methods.

Any thoughts or comments?

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= <[email-masked]>
Date: Sun, 15 Nov 2009 20:21:22 +0100
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

The ideas and discussions for ZF 2.0 have been great so far, and I'm =
really looking forward to the actual release!

There's a non-technical issue that ZF 2.0 should try to tackle. This =
issue is getting beginners up to speed quickly, and to get people more =
involved in the community.

First off, developers should get the tools and knowledge to get started =
with developing right away. The Quickstart is doing great with this, but =
it could probably use a dedicated chapter for setting up a development =
environment. That is, Zend Server and PDT/ZSfE or Netbeans, with full =
debugging support etc.

What comes next is probably where ZF is currently lacking most. =
Currently the documentation we have are the quickstart, followed by the =
reference guide. For me - someone who's been using ZF since around v0.2 =
- that's perfectly fine, but the step is too big for a beginner. =
Basically two things need to be made clear to someone who just finished =
the quickstart: how does the ZF community work (where can I get help, =
how can I help, etc.), and where do I go from here? Paddy has been doing =
some amazing work on the latter question with his Survive The Deep End =
book, that's freely available online =
(http://www.survivethedeepend.com/). Why not make this a permanent link =
on the ZF homepage, between quickstart and reference guide?
The former ("where can I get help/how can I help") could be made more =
clear to make links to the mailing lists and #zftalk and #zftalk.dev =
more visible on the ZF frontpage.=20

Expanding on the community point a bit, it might be a good thing to keep =
the level of experience of developers in mind on the wiki and the =
mailing list. Paddy and Kevin touched this topic in their discussion in =
this thread, and I've read the term "too compsci-y" somewhere in that =
discussion too. To be perfectly honest, I'm completely fine with =
discussions and proposals that expect some compsci experience from the =
reader. That said, it might be a good thing to get people without a =
compsci degree in on the discussions as well, which is probably actually =
quite a large group of people in the PHP world. For example, the =
Zend_Controller 2.0 proposal mentions an FSM. For people that do not =
know what an FSM is, a reference to an introductory article on FSMs =
might be interesting. In a discussion I had with a friend we couldn't =
agree on how this could be achieved best, without dumbing things down =
too much. I'd be interested to hear your opinions on this.

Here's my $0.02 for 2.0 for now. Bring on ideas and discussion! :)

- Jurri=EBn

On Nov 11, 2009, at 19:38 , Matthew Weier O'Phinney wrote:

> Hey, all --
>=20
> There have been a ton of questions about the ZF 2.0 roadmap, and my
> answer has been consistently, "I'm working on it; I'll have something =
to
> publish soon."
>=20
> "Soon" is now:
>=20
>    =
http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>=20
> I'd like you, as contributors, to look over it, and start discussing =
the
> various ramifications; we can do that either in comments to the pages =
or
> on this list.
>=20
> The roadmap is primarily a conceptual one right now, though a
> proof-of-concept has been created for the proposed MVC. I'd like to =
stay
> fairly high-level for now, and then start getting a flow of proposals
> into the system for specific migration-related tasks.
>=20
> Thanks everyone who has provided me input over the past many months, =
and
> let's get started on the next generation of ZF!
>=20
> --=20
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Mon, 6 Apr 2009 11:02:59 -0700
From: "Wil Sinclair" <[email-masked]>
To: "Robin Skoglund" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [zf-contributors] 1.8 PR feature list and *acknowledgements*

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B6E1.EBC6894A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I believe Zend_Navigation is in if the minor changes that we have
recommended are made. Matthew can tell you more. It is a really sweet
component, BTW. J

=20

,Wil

=20

From: Robin Skoglund [mailto:[email-masked]]=20
Sent: Monday, April 06, 2009 11:02 AM
To: Wil Sinclair
Cc: [email-masked]
Subject: Re: [zf-contributors] 1.8 PR feature list and
*acknowledgements*

=20

On Mon, Apr 6, 2009 at 19:55, Wil Sinclair <[email-masked]> wrote:

NOTE: For this release, we'd like to try something new in the feature
list- actually acknowledging the significant contributions that y' all
have made. J The format would be like this:

=20

* Zend_Application, contributed by Matthew Weier O'Phinney and Ben
Scholzen

=20

,Wil

Hi, I haven't gotten any answer on whether Zend_Navigation will be
included in the PR, but here goes:

* Zend_Navigation, contributed by Robin Skoglund

        robinsk

------_=_NextPart_001_01C9B6E1.EBC6894A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I believe Zend_Navigation is in if the minor changes that =
we
have recommended are made. Matthew can tell you more. It is a really =
sweet
component, BTW. </span><span =
style=3D'font-size:11.0pt;font-family:Wingdings;
color:#1F497D'>J</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>,Wil<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Robin =
Skoglund
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, April 06, 2009 11:02 AM<br>
<b>To:</b> Wil Sinclair<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [zf-contributors] 1.8 PR feature list and
*acknowledgements*<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>On Mon, Apr 6, 2009 at 19:55, Wil Sinclair &lt;<a
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<o:p></o:p></p>

<div>

<div>

<p>NOTE: For this release, we&#8217;d like to try something new in the =
feature list-
actually acknowledging the significant contributions that y&#8217; all =
have made. <span
style=3D'font-family:Wingdings'>J</span> The format would be like =
this:<o:p></o:p></p>

<p>&nbsp;<o:p></o:p></p>

<p>* Zend_Application, contributed by Matthew Weier O'Phinney and Ben =
Scholzen<o:p></o:p></p>

<p>&nbsp;<o:p></o:p></p>

<p><span style=3D'color:#888888'>,Wil<o:p></o:p></span></p>

</div>

</div>

</div>

<p>Hi, I haven't gotten any answer on whether Zend_Navigation will be =
included
in the PR, but here goes:<o:p></o:p></p>

<p>* Zend_Navigation, contributed by Robin Skoglund<o:p></o:p></p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; robinsk<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9B6E1.EBC6894A--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: =?iso-8859-1?Q?Lukas_K=F6ll?= <[email-masked]>
Date: Mon, 15 Mar 2010 23:09:39 +0100
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

Hi Ralf,
this is my first "get-in-touch" with the zf-contributor list so please =
feel free to draw my attention to any mistakes i make.

For Zend_Acl_Role I would have thought that Zend_Acl_Role should be the =
new Interface, while for the default implementation there should be =
something like Zend_Acl_Role_Default/Text. As I have never needed to =
implement custom acl-roles myself I also don't know which possible use =
cases a custom implementation of a Zend_Acl_Role Interface might have. I =
also think that an interface named Zend_Acl_Role is much more =
reader-friendly than Zend_Acl_Role_Interface.=20

Zend_Captcha_Adapter might from my point of view stay just as-is =
(because, actually, everything that implements Zend_Captcha_Adapter CAN =
ACT AS an adapter), Zend_Pdf_ElementFactory_Interface should in my =
opinion also be renamed to Zend_Pdf_ElementFactory and move the default =
implementation to something like Zend_Pdf_ElementFactory_Default (maybe =
someone can come up with something better then "Default" ?) - again, =
reading "instanceof Zend_Pdf_ElementFactory" feels at least to me much =
more natural than "instanceof Zend_Pdf_ElementFactory_Interface"

Zend_Validate would by the way be a good example for adding adjectives. =
My proposal: Zend_Validateable or Zend_Validate_Validateable

best regards

Lukas K=F6ll

Am 15.03.2010 um 22:34 schrieb Ralf Eggert:

> Hi Matthew,
>=20
> Could you feed this discussion with some real world examples? For
> example "Foobarable" and "Foobarist" sound a little weird to me.
>=20
> Please name some interfaces with their current name and the future
> variations for the options 1 to 8. Maybe this could help a little more
> in the discussion. For example how should Zend_Acl_Role_Interface oder
> Zend_Captcha_Adapter or Zend_Pdf_ElementFactory_Interface be renamed?
>=20
> Thanks and best regards,
>=20
> Ralf
>=20

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 26 Jan 2010 09:31:09 +0100
From: till <[email-masked]>
To: Diego Henrique Oliveira <[email-masked]>
Cc: Ralph Schindler <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] changes in component Zend_Auth_Adapter_DbTable

Hey Diego,

On Tue, Jan 26, 2010 at 2:21 AM, Diego Henrique Oliveira
<[email-masked]> wrote:
> I agree with you about breaking the table users in several tables is the
> best solution. However the application I'm working on is just a part of
> another larger application, which is developed by another company, so I
> can't just break the database tables.
>
> The bank in question is MySQL and the bottleneck that I was having is the
> return of unnecessary data. Maybe I could be wrong and seeing the need fo=
r
> performance where it does not exist (hypothesis not discarded).

I think the question is -- how did you determine this is a bottleneck.
Or did you just think it could be one? :-)

I don't want to lecture you (so excuse me when I come across like
that), but the general idea when it comes to working around
bottlenecks is to always measure (e.g. how long does it take to render
my homepage), then to identify potential bottlenecks  in the code,
implement improvements and then to measure again. Repeat, etc..

And that's what a lot of people in this thread are hinting on.

Regardless of the above, +1 to submitting this patch. Even though it
may not yield outrageously obvious performance improvements it's kinda
MIND BOGGLING how this piece of code didn't have this before.

It's actually also pretty hilarious. And I don't follow the general
notion that people always complain that feature X will complicate the
API. It's not even a BC break, it's a new feature. Take it or leave
it. :-) It doesn't make code slower.

I'd rather be able to filter in the database because a smaller set has
a lot of other implications -- aside from query speed. There's also
less to carry around with during the request. It's domain-specific and
adds more flexibility for the developer.

Till

>
> My point in posting here was just to ask the opinion of everyone, who
> obviously has more experience than me.
>
> Regards.
>
>
>
> ________________________________
> From: Ralph Schindler <[email-masked]>
> To: Diego Henrique Oliveira <[email-masked]>
> Cc: [email-masked]
> Sent: Mon, January 25, 2010 6:58:43 PM
> Subject: Re: [zf-contributors] changes in component
> Zend_Auth_Adapter_DbTable
>
> I am not sure I see a lot of value here.=A0 What kind of bottleneck are y=
ou
> seeing?=A0 Considering this function should only be run once during the
> lifespan of a user's session, I am not sure why it would be that big of a=
n
> issue.
>
> Returning 20 vs. 4 columns generally has no consequence on the result at
> all, what vendor DB are you using where this is a concern?
>
> Furthermore, perhaps you should break out authentication information from
> the user table itself and instead use a join with the select object? Just=
 a
> thought.
>
> -ralph
>
>
>
> Diego Henrique Oliveira wrote:
>> In the adapter DbTable, the generated query to the database is a 'select
>> *', and as it was being a bottleneck in my application (users table with
>> many fields), i made these changes in the component
>> Zend_Auth_Adapter_DbTable.
>>
>>
>> class Zend_Auth_Adapter_DbTable
>> {
>>=A0 =A0 =A0 =A0 protected $_returnedFields;
>>=A0 =A0 =A0 =A0 public function setReturnedFields( array $fields )
>>=A0 =A0 {
>>=A0 =A0 =A0 =A0 $this->_returnedFields =3D $fields;
>>=A0 =A0 }
>>=A0 =A0 =A0 =A0 public function getReturnedFields()
>>=A0 =A0 {
>>=A0 =A0 =A0 =A0 if (is_null($this->_returnedFields))
>>=A0 =A0 =A0 =A0 {
>>=A0 =A0 =A0 =A0 =A0 =A0 return array('*');
>>=A0 =A0 =A0 =A0 }
>>=A0 =A0 =A0 =A0 return $this->_returnedFields;
>>=A0 =A0 }
>>=A0 =A0 =A0 =A0 /**
>>=A0 =A0 =A0 * _authenticateCreateSelect() - This method creates a Zend_Db=
_Select
>> object that
>>=A0 =A0 =A0 * is completely configured to be queried against the database=
.
>>=A0 =A0 =A0 *
>>=A0 =A0 =A0 * @return Zend_Db_Select
>>=A0 =A0 =A0 */
>>=A0 =A0 protected function _authenticateCreateSelect()
>>=A0 =A0 {
>>=A0 =A0 =A0 =A0 // build credential expression
>>=A0 =A0 =A0 =A0 if (empty($this->_credentialTreatment) ||
>> (strpos($this->_credentialTreatment, '?') =3D=3D=3D false)) {
>>=A0 =A0 =A0 =A0 =A0 =A0 $this->_credentialTreatment =3D '?';
>>=A0 =A0 =A0 =A0 }
>>
>>=A0 =A0 =A0 =A0 $credentialExpression =3D new Zend_Db_Expr(
>>=A0 =A0 =A0 =A0 =A0 =A0 '(CASE WHEN ' .
>>=A0 =A0 =A0 =A0 =A0 =A0 $this->_zendDb->quoteInto(
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 $this->_zendDb->quoteIdentifier($this->_c=
redentialColumn,
>> true)
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . ' =3D ' . $this->_credentialTreatment, =
$this->_credential
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 )
>>=A0 =A0 =A0 =A0 =A0 =A0 . ' THEN 1 ELSE 0 END) AS '
>>=A0 =A0 =A0 =A0 =A0 =A0 . $this->_zendDb->quoteIdentifier(
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 $this->_zendDb->foldCase('zend_auth_crede=
ntial_match')
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 )
>>=A0 =A0 =A0 =A0 =A0 =A0 );
>>
>>=A0 =A0 =A0 =A0 // get select
>>=A0 =A0 =A0 =A0 $fields=A0 =3D $this->getReturnedFields();
>>=A0 =A0 =A0 =A0 array_push( $fields, $credentialExpression );
>>=A0 =A0 =A0 =A0 $dbSelect =3D clone $this->getDbSelect();
>>=A0 =A0 =A0 =A0 $dbSelect->from($this->_tableName, $fields)
>>
>> ->where($this->_zendDb->quoteIdentifier($this->_identityColumn, true) . =
' =3D
>> ?', $this->_identity);
>>
>>=A0 =A0 =A0 =A0 return $dbSelect;
>>=A0 =A0 }
>>=A0 =A0 }
>>
>>
>>
>> What you guys think about these changes? And should I submit them to the
>> project?
>>
>>
>> Cheers
>>
>> Diego
>> http://diegoholiveira.com
>>
>
>

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Mihai Bojin <[email-masked]>
Date: Wed, 20 Jan 2010 15:55:16 +0200
To: [email-masked]
Subject: [zf-contributors] Zend_Grid component proposal

Hello Everyone,

I submitted a proposal for review and right now I'm waiting for any =
suggestions, advice, opinions and so on :)

You can check out the proposal here:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin

Any feedback will be greatly appreciated !

Looking forward to hearing from the community,

Mihai Bojin
Web Developer
[email-masked]
[email-masked]
+4.0721.231.134=

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 14:32:57 -0500
From: Ralph Schindler <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

> Honestly, choosing "f" as an alias just seems like a bad idea from the
> outset -- does it refer to "filter", or "form", or "file"? If you go

Totally agree.

> with a more explicit alias:
> 
>     use Zend\Filter;
> 
>     $filter = new Filter\Int;
> 
> the intent is already there.
> 
> I can see your point being more present if you import a single class
> from a namespace:
> 
>     use Zend\Filter\Int;
>     $filter = new Int();
> 
> *This* example more properly shows the issues, to my thinking. But even
> then, better aliasing solves the problem:
> 
>     use Zend\Filter\Int as IntFilter;
>     $filter = new IntFilter;
> 

It could be argued the other way as well:

use Zend\Filter\IntFilter as Int;

$filter = new Int();

The question is, do we rely completely on a classes placement in a 
namespace as its full intent and meaning? Or do we at least give it an 
identity of its own?

IntFilter is still pretty short & concise as a class name, and it's 
purpose is further defined by the Zend\Filter namespace in which it resides.

Did we move away from class Abstract {} and interface Interface {} 
inside of a namespace simply because they were technically impossible, 
or was it because on their own, a class named Abstract inside a 
namespace and an interface named Interface made little sense?

-ralph

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 28 Aug 2009 11:40:39 -0300
From: Guilherme Blanco <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in 
	Zend_Entity

Ben,

I already answered you on IRC yesterday, but here is the public once
for history purposes.

You rely on EntityManager to build your QueryBuilder.
That means that actually createNativeQueryBuilder is actually a
Factory method to generate DBMS specific generation.

We follow most of the specs and we speak a lot on IRC about how to
solve recurrent issues.
>From Doctrine side, the version 2.0 and Zend_Entity implements JPAv2
mostly... so we don't differ too much.
Problem is that JPA is specific for RDBMS, and this means that a lot
of tweaks are necessary to support DDBMS.

We found out at the end that we'll first launch Doctrine 2.0 as an ORM
tool and once we reach a good stage, we'll think in how to support
other types.
There're main places that requires changes. One example is the DQL to
SQL generation... Against DDBMS, it can't be used SQL, so we'll have
to move the SqlWalker extended from TreeWalker (which navigates
through the AST generated by LL(k) parser) to be Platform dependant.
This means that if we want to choose Tamino (Document-oriented XML DB)
for example, we'll have to generate the XQL (a kind of XPath) to query
the DB.

Also, if you want to restrict the structure of a DDBMS to always fit
your Zend_Entity, this means you're loosing the most powerful thing it
supports (schema-less definitions).

Another point to highlight: DDBMS do not support relations natively.
Except MongoDB, which is the only DDBMS that supports it, you'll have
to rely on a lazy load of relations all the time to load related data.
This changes quite a lot the structure of your Collection and Entity.
We get prepared to afford this type of need, but you may need to think
correctly based on your structure.

Doctrine team is even considering to go into the direction of
EclipseLink, which supports it by supporting similar projects. That's
one of the reasons we organized our repository in Common, DBAL and
ORM. If we can't afford the changes needed to support DDBMS, we may
need to create a ODM repository.
Trust me, you like challenges like we all loves. But build a unique
solution to support RDBMS, DDBMS, OODBMS are not easy.

Matthew,

We'll release Doctrine 2.0 in September 1st. =3D)
It'll be a preview alpha. We want people to start testing our new
codebase and provide us some feedback. We still have lots of
development to do, I just finished the base of CLI tasks, while
Jonathan finished the Optimistic Locking strategy.
On schedule we have many other interesting things to come. Recently
I've been speaking a lot with Steve Ebersole from Hibernate. We're
planning to support HiLo Id Generator soon.

Most of the concepts we're bringing to Doctrine are quite new to PHP
world, mainly to lack of some tools of language until now. PHP 5.3
opened a new world of possibilities and we're just taking advantage of
it.
Native support to Metadata mapping through Annotations is a rather
unique thing in PHP, only seen similar in Unit Test tools.
Let's see how people accept these new ideas, we're open to hear any
feedback from userland.

Cheers,

On Fri, Aug 28, 2009 at 8:22 AM, Matthew Weier
O'Phinney<[email-masked]> wrote:
> -- Benjamin Eberlei <[email-masked]> wrote
> (on Thursday, 27 August 2009, 10:06 PM +0200):
>> i am currently scratching my head on howto abstract the query API for di=
fferent
>> storages and often think about CouchDb which has a fundamently different=
 Query
>> concept than a RDBMS.
>>
>> For clarification to the not so familiar, it the EntityManager is the so=
le
>> public API to the user of Zend_Entity and its facilities. It manages the=
 life-
>> cycle of domain objects.
>>
>> Currently, it has the following API for queries:
>>
>> EntityManager::load($entityClass, $id);
>> EntityManager::createNamedQuery($name);
>> EntityManager::createNativeQuery($input, $resultSetMapping);
>> EntityManager::createNativeQueryBuilder($entityClass=3Dnull);
>> EntityManager::createQuery($zql); // not implemented yet
>> EntityManager::createQueryBuilder(); // not implemented yet
>>
>> This is very large and still very RDBMS specific interface. To break tha=
t up
>> I was thinking to go the following way, only have three methods:
>>
>> EntityManager::load($entityClass, $id);
>> EntityManager::createNamedQuery($name);
>> EntityManager::createNativeQuery($input, $resultSetMapping);
>>
>> And all the other Query related stuff is implemented and used explicitly=
 by
>> calling for example:
>>
>> $sqlQueryBuilder =3D new Zend_Db_Mapper_SqlQueryBuilder($entityManager);
>> $queryBuilder =3D new Zend_Db_Mapper_QueryBuilder($entityManager);
>> $zqlQuery =3D new Zend_Db_Mapper_ZqlQuery($entityManager);
>>
>> This way the API can be hinted explicitly in IDEs (since its often quite
>> complex) and storage specific features can be implemented.
>
> This seems like a very good approach to me. It keeps the primary query
> types front and center, but offers the flexibility to create your own
> without needing to inform Zend_Entity of them. I particularly like this
> because it introduces the idea of a "criteria" object -- which can then
> be as abstract as you want it, or specific to your particular data
> storage implementation.
>
>> Now you ask yourself, how is this storage independent? It is via the
>> "createNamedQuery()" method. This method internally uses the plugin
>> loader to instantiate queries via the command pattern. In a storage
>> independent database, all operations have to be build as named query
>> and executed such. =C2=A0For each storage a corresponding implementation
>> has to exist.
>
> This seems like it would be very compatible with CouchDB views,
> actually.
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/

--=20
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [email-masked]
URL: http://blog.bisna.com
S=C3=A3o Paulo - SP/Brazil

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 11 Dec 2009 09:14:49 -0800
From: Kevin McArthur <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Security policy posted

Good work Matthew. Glad to see the framework moving forward with this stuff!

A rating system would be good.

K

Matthew Weier O'Phinney wrote:
> I just sent the following announcement to the fw-general list:
>
>     Greetings!
>
>     The Zend Framework team has posted a security policy for the framework.
>     This include:
>
>     * How and when to report
>     * Pages detailing each reported security advisory
>     * An RSS2 feed for tracking security advisories
>
>     You can read up for more details on the policy at:
>
>         http://framework.zend.com/security
>
>     We welcome your input on the policy, and thank you in advance for
>     helping us make and keep ZF and ZF users secure.
>
> Currently, the zf-security alias goes to the various members of the ZF
> team at Zend. We will be inviting several community members to help
> monitor it as well in the coming weeks; if you are interested, please
> contact one of us, and indicate how and why you would be of assistance
> in this role. 
>
> Additionally, we're still trying to hammer down some details of our
> policy -- Ralph, for instance, brought up the idea that we may want to
> have our own security ratings for advisories, and have good definitions
> for each rating. We welcome any feedback you may offer.
>
> Thanks!
>
>   

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 8 Apr 2009 08:30:08 +0300
From: Vadim Gabriel <[email-masked]>
To: "Ben Scholzen 'DASPRiD'" <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] New Component proposal

--001636c5adf4b33ba90467046c4d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hey,

Thanks, For the help with the password thing, I will email Matthew.

About the component, I have no problem in writing a unified API, My full
time job is building Ecommerce stores, So i have quite a log of code already
written that utilize all sort of payment providers, I could probably write
down the ones i have worked with and completely sure that i will be able to
include them in the unifed API component. The thing is i don't know where to
start really, Where do i open a proposal? What do i need to write down in
there?

For the unified thing, I was thinking on creating a seperate class for every
payment provider, Like Zend_Payment_Paypal, Zend_Payment_2Checkout etc,
Would that work? or does it have to be just one class and using a
constructor method to initialize the required payment provider class? Such
as

$paypal = new Zend_Payment('paypal');
$2checkout = new Zend_Payment('2checkout');

I can do either, Which ever sounds better is fine with me.

Thanks again for the help.

Vince.

On Tue, Apr 7, 2009 at 11:57 PM, Ben Scholzen 'DASPRiD' <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You may probably ask Matthew or Wil about the password thingy.
>
> Then, to your proposal:
> There were some proposals for payment components, but mostly the just
> included single payment methods, and did not cover multiple ones. We
> discussed that a few times, and what we need is a component which offers
> (if possible) a unified API for all payment providers. When you are
> willing to do so, feel free to get on with your proposal, I will follow
> it with interest.
>
> Regards,
> Ben
> ...................................
> :  ___   _   ___ ___ ___ _ ___    :
> : |   \ /_\ / __| _ \ _ (_)   \   :
> : | |) / _ \\__ \  _/   / | |) |  :
> : |___/_/:\_\___/_| |_|_\_|___/   :
> :........:........................:
> : Web    : http://www.dasprids.de :
> : E-mail : [email-masked]       :
> : Jabber : [email-masked]     :
> : ICQ    : 105677955              :
> :........:........................:
>
>
> Vadim Gabriel schrieb:
> > Hey,
> >
> > I have never added a new proposal and searched the wiki about how to
> > make those. I found this "Image" that displays the work flow of adding a
> > new component, From opening a new proposal in the wiki upto getting it
> > approved by the Zend Team.
> > I have a few problems tough.
> >
> > First i have lost my password, And now i can't access JIRA. I already
> > signed the CLA, And would have reset my password, I just couldn't find
> > the lost password feature anywhere. Do i need to ask someone to reset it
> > for me?
> > Second, Where and how do i start a new Wiki page about the component i
> > would like to contribute. Do i need to add anything special like special
> > information about it, Besides the usual description and technical
> > specifications?
> > Third, My component that i would like to share is Zend_Payments_Paypal
> > class that allows to use paypal. This is the only thing i made so far by
> > myself for Zend Framework but since i am working a lot with Ecommerce i
> > will probably be writting more payment transfer options such as Google
> > checkout, Moneybookers, 2checkout and more. I would like to know if this
> > is something that might interest people and actually make it's way to
> > the library rather then the archive?
> >
> > Thanks, Vince.
> >
> > --
> > Vincent Gabriel.
> > Lead Developer, Senior Support.
> > Zend Certified Engineer.
> > Zend Framework Certified Engineer.
> >
> >
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAknbvj4ACgkQ0HfT5Ws789AIsQCffrVw9VETkPXTCgn/i9yD9XHh
> FwoAnRZ2/VyJngOvolSD2Vg7ww7OLgLe
> =Qkwd
> -----END PGP SIGNATURE-----
>

-- 
Vincent Gabriel.
Lead Developer, Senior Support.
Zend Certified Engineer.
Zend Framework Certified Engineer.

--001636c5adf4b33ba90467046c4d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey,<br><br>Thanks, For the help with the password thing, =
I will email Matthew.<br><br>About the component, I have no problem in writ=
ing a unified API, My full time job is building Ecommerce stores, So i have=
 quite a log of code already written that utilize all sort of payment provi=
ders, I could probably write down the ones i have worked with and completel=
y sure that i will be able to include them in the unifed API component. The=
 thing is i don&#39;t know where to start really, Where do i open a proposa=
l? What do i need to write down in there?<br>
<br>For the unified thing, I was thinking on creating a seperate class for =
every payment provider, Like Zend_Payment_Paypal, Zend_Payment_2Checkout et=
c, Would that work? or does it have to be just one class and using a constr=
uctor method to initialize the required payment provider class? Such as <br=
<br>$paypal =3D new Zend_Payment(&#39;paypal&#39;);<br>$2checkout =3D new Z=
end_Payment(&#39;2checkout&#39;);<br><br>I can do either, Which ever sounds=
 better is fine with me.<br><br>Thanks again for the help.<br><br>Vince.<br=
<br><div class=3D"gmail_quote">On Tue, Apr 7, 2009 at 11:57 PM, Ben Scholze=
n &#39;DASPRiD&#39; <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
e">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt=
 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
You may probably ask Matthew or Wil about the password thingy.<br>
<br>
Then, to your proposal:<br>
There were some proposals for payment components, but mostly the just<br>
included single payment methods, and did not cover multiple ones. We<br>
discussed that a few times, and what we need is a component which offers<br=
(if possible) a unified API for all payment providers. When you are<br>
willing to do so, feel free to get on with your proposal, I will follow<br>
it with interest.<br>
<br>
Regards,<br>
Ben<br>
...................................<br>
: =A0___ =A0 _ =A0 ___ ___ ___ _ ___ =A0 =A0:<br>
: | =A0 \ /_\ / __| _ \ _ (_) =A0 \ =A0 :<br>
: | |) / _ \\__ \ =A0_/ =A0 / | |) | =A0:<br>
: |___/_/:\_\___/_| |_|_\_|___/ =A0 :<br>
:........:........................:<br>
: Web =A0 =A0: <a href=3D"http://www.dasprids.de" target=3D"_blank">http://=
www.dasprids.de</a> :<br>
: E-mail : <a href=3D"mailto:[email-masked]">[email-masked]</a> =A0 =A0=
 =A0 :<br>
: Jabber : <a href=3D"mailto:[email-masked]">[email-masked]</a> =A0=
 =A0 :<br>
: ICQ =A0 =A0: 105677955 =A0 =A0 =A0 =A0 =A0 =A0 =A0:<br>
:........:........................:<br>
<br>
<br>
Vadim Gabriel schrieb:<br>
<div><div></div><div class=3D"h5">&gt; Hey,<br>
&gt;<br>
&gt; I have never added a new proposal and searched the wiki about how to<b=
r>
&gt; make those. I found this &quot;Image&quot; that displays the work flow=
 of adding a<br>
&gt; new component, From opening a new proposal in the wiki upto getting it=
<br>
&gt; approved by the Zend Team.<br>
&gt; I have a few problems tough.<br>
&gt;<br>
&gt; First i have lost my password, And now i can&#39;t access JIRA. I alre=
ady<br>
&gt; signed the CLA, And would have reset my password, I just couldn&#39;t =
find<br>
&gt; the lost password feature anywhere. Do i need to ask someone to reset =
it<br>
&gt; for me?<br>
&gt; Second, Where and how do i start a new Wiki page about the component i=
<br>
&gt; would like to contribute. Do i need to add anything special like speci=
al<br>
&gt; information about it, Besides the usual description and technical<br>
&gt; specifications?<br>
&gt; Third, My component that i would like to share is Zend_Payments_Paypal=
<br>
&gt; class that allows to use paypal. This is the only thing i made so far =
by<br>
&gt; myself for Zend Framework but since i am working a lot with Ecommerce =
i<br>
&gt; will probably be writting more payment transfer options such as Google=
<br>
&gt; checkout, Moneybookers, 2checkout and more. I would like to know if th=
is<br>
&gt; is something that might interest people and actually make it&#39;s way=
 to<br>
&gt; the library rather then the archive?<br>
&gt;<br>
&gt; Thanks, Vince.<br>
&gt;<br>
&gt; --<br>
&gt; Vincent Gabriel.<br>
&gt; Lead Developer, Senior Support.<br>
&gt; Zend Certified Engineer.<br>
&gt; Zend Framework Certified Engineer.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href=3D"http://enigmail.mozdev.org" =
target=3D"_blank">http://enigmail.mozdev.org</a><br>
<br>
iEYEARECAAYFAknbvj4ACgkQ0HfT5Ws789AIsQCffrVw9VETkPXTCgn/i9yD9XHh<br>
FwoAnRZ2/VyJngOvolSD2Vg7ww7OLgLe<br>
=3DQkwd<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Vincent Gabriel.<br>Lea=
d Developer, Senior Support.<br>Zend Certified Engineer.<br>Zend Framework =
Certified Engineer.<br><br><br><br><br>
</div>

--001636c5adf4b33ba90467046c4d--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: David Abdemoulaie <[email-masked]>
Date: Fri, 12 Mar 2010 16:42:56 -0600
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 10 Mar 2010

--Apple-Mail-5-216284510
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Mar 12, 2010, at 4:37 PM, A.J. Brown wrote:

> I'm not sure about the requirement for autoloading in _unit_ tests.  =
Autoloading adds another layer of code that's not directly related to =
the unit under test.  A bug in AutoLoading could directly affect the =
outcome of another unit test.  Imagine a situation where the wrong class =
is autoloaded in the middle of a test, but it just so happens to work =
out. =20

This is a good point. I think it's important to be able to look at a =
unit test and see exactly what's going on instead of relying on what the =
framework to take care of it (you hope).

--
David Abdemoulaie
http://hobodave.com=

--Apple-Mail-5-216284510
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 12, 2010, at 4:37 PM, A.J. Brown wrote:</div><br><blockquote type="cite">I'm not sure about the requirement for autoloading in _unit_ tests.&nbsp; Autoloading adds another layer of code that's not directly related to the unit under test.&nbsp; A bug in AutoLoading could directly affect the outcome of another unit test.&nbsp; Imagine a situation where the wrong class is autoloaded in the middle of a test, but it just so happens to work out.&nbsp;&nbsp;<br></blockquote></div><br><div>This is a good point. I think it's important to be able to look at a unit test and see&nbsp;<i>exactly</i>&nbsp;what's going on instead of relying on what the framework to take care of it (you hope).</div><div><br></div><div>--</div><div>David Abdemoulaie</div><div><a href="http://hobodave.com">http://hobodave.com</a></div></body></html>
--Apple-Mail-5-216284510--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 25 Jan 2010 10:20:09 +0100
From: Laurent Melmoux <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
CC: [email-masked]
Subject: Re: [zf-contributors] Zend_Date & build-in class Da

Hi,

+1 to have  Zend_Date making use of  DateTime for ZF 2.0.
Especially  that php 5.3. is now addressing Internationalization :=20
http://devzone.zend.com/article/4799 :)
Then Zend_Locale_*  could make use of it too.

Laurent

Benjamin Eberlei a =C3=A9crit :
> I compare object oriented APIs around mktime, strtotime and date. Both
> Zend_Date and DateTime are more or less wrappers around working with
> integers or floats that represent time.
>
> It makes no difference if Zend_Date uses mktime or DateTime internally
> or mktime. Its supposed to be an OOP interface around dates. 200 method=
s
> and 4000 LOC, are no real arguments either - DateTime has lots of code
> also and most of the methods on Zend_Date are just convenience methods
> that make a two-line code snippet to a one-liner. Any class that extend=
s
> DateTime could implement them aswell and still be faster.
>
> I do acknowledge the constraints of the original proposal, however stil=
l
> with lots of refactoring you will never get a Zend_Date implementation
> in PHP code that is nearly as fast as an implementation based completly
> on DateTime and its ascending classes.
>
> Also I know that ZF 1.x will always be based on 5.2.4, however the
> original
> question was based on what will be done for ZF 2.0, which obviously wil=
l
> require PHP 5.3.1 at least.
>
> Since many other frameworks or libraries will use DateTime (Doctrine 2 =
for
> example)
> I think it would be a major drawback for ZF not to build upon DateTime
> to push integration possiblities to the edge, as well as recognizing th=
at
> using a standard API probably helps adoption alot.
>
> greetings,
> Benjamin
>
>
> On Sat, 23 Jan 2010 11:58:16 +0100, "Thomas Weidner"
> <[email-masked]> wrote:
>  =20
>> You are comparing apples with oranges.
>> A discussion on such a basis is completly useless.
>>
>> Actually Zend_Date uses mktime. So when you want to compare one=20
>> implementation to the other you need to compare mktime to DateTime.
>>
>> And of course you already did a real comparison as you reworked
>>    =20
> Zend_Date.=20
>  =20
>> Did you?
>>
>> Just for information... the lack of performance is due to the reason h=
ow
>>    =20
> I=20
>  =20
>> was forced to implement the class. A class which is 4500 lines long an=
d
>> adds=20
>> about 200 methods will never be as performant as a extension which has
>>    =20
> has=20
>  =20
>> only 15 methods.
>>
>> When I am not forced to do the API within a few days as with 0.7 and a=
m=20
>> allowed to rework it as it should be done then even the existing mktim=
e=20
>> implementation would be multiple times faster.
>>
>> PS: Related to mktime DateTime performs also slower. The real benefit =
is
>>    =20
>
>  =20
>> only for calculations beside the 32bit unix timestamp.
>>
>> PPS: Again... as said in past... as long as we are limited to 5.2.4
>>    =20
> there=20
>  =20
>> will be no rework due to some major problems which has been solved in
>> later=20
>> releases.
>>
>> Greetings
>> Thomas Weidner, I18N Team Leader, Zend Framework
>> http://www.thomasweidner.com
>>
>> ----- Original Message -----=20
>> From: "Benjamin Eberlei" <[email-masked]>
>> To: <[email-masked]>
>> Sent: Saturday, January 23, 2010 1:36 AM
>> Subject: Re: [zf-contributors] Zend_Date & build-in class Da
>>
>>
>>    =20
>>> =3D?UTF-8?Q?teTime?=3D
>>>
>>>
>>> The only thing DateTime can't handle that Zend_Date can as of 5.3 is
>>>
>>> localized output
>>>
>>> and maybe some special features.
>>>
>>>
>>>
>>> >From the performance point of view, i have tested three use-cases
>>>      =20
> against
>  =20
>>> each
>>>
>>> other:
>>>
>>>
>>>
>>> 1. Printing the same instance 100 times
>>>
>>>
>>>
>>> $s =3D microtime(true);
>>>
>>> $d =3D new DateTime("now");
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>   $d->format('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> $date =3D new Zend_Date(1234567890, false);
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>    $date->toString('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> Gives:
>>>
>>> DateTime 0.0004s
>>>
>>> Zend_Date 0.0599s
>>>
>>>
>>>
>>> 2. Changing the date by Unix-Timestamp on each run for 100 times:
>>>
>>>
>>>
>>> $d =3D new DateTime("now");
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>   $d->setTimestamp($now + $i * 7200);
>>>
>>>   $d->format('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> $date =3D new Zend_Date(1234567890, false);
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>    $date->setTimestamp($now + $i * 7200);
>>>
>>>    $date->toString('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> Gives:
>>>
>>> DateTime 0.0010s
>>>
>>> Zend_Date 0.0591s
>>>
>>>
>>>
>>> 3. Changing Date on each call by a defined format (MySQL Database) fo=
r
>>> 100
>>>
>>> new instances.
>>>
>>>
>>>
>>> Now this is the most evil performance hit.
>>>
>>>
>>>
>>> $s =3D microtime(true);
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>   $d =3D DateTime::createFromFormat('Y-m-d H:i:s', '2009-04-01
>>>      =20
> 12:12:12');
>  =20
>>>   $d->format('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> for($i =3D 0; $i < 100; $i++) {
>>>
>>>    $date =3D new Zend_Date('2009-04-01 12:12:12', Zend_Date::ISO_8601=
);
>>>
>>>    $date->toString('d.m.Y, H:i');
>>>
>>> }
>>>
>>>
>>>
>>> DateTime: 0.0020s
>>>
>>> Zend_Date: 0.1982s
>>>
>>>
>>>
>>> DateTime is faster than Zend_Date by a magnitute of 60-100!!
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 22 Jan 2010 15:59:32 -0800 (PST), P=C3=A1draic Brady
>>>
>>> <[email-masked]> wrote:
>>>
>>>      =20
>>>> Personally I don't see DateTime as massively important to Zend_Date.
>>>>        =20
> It
>  =20
>>>> would be nice to have, but the class itself is pretty basic that I'm
>>>>        =20
> not
>  =20
>>>> sure what exactly it would add to Zend_Date other than offer a
>>>>        =20
>>> (measured?)
>>>
>>>      =20
>>>> performance boost and some import/export functionality for
>>>>        =20
>>> interoperability
>>>
>>>      =20
>>>> (would have been nicer to have a DateTime interface).
>>>>        =20
>>>>  P=C3=A1draic Brady
>>>>        =20
>>>> http://blog.astrumfutura.com
>>>>        =20
>>>> http://www.survivethedeepend.com
>>>>        =20
>>>> OpenID Europe Foundation Irish Representative
>>>>        =20
>>>> ________________________________
>>>>        =20
>>>> From: Marc Bennewitz <[email-masked]>
>>>>        =20
>>>> To: [email-masked]
>>>>        =20
>>>> Sent: Fri, January 22, 2010 10:16:02 PM
>>>>        =20
>>>> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>>>>        =20
>>>>  Hi all,
>>>>        =20
>>>> Does is matter that Zend_Date doesn't extends the build-in DateTime
>>>>        =20
>>>> class ?
>>>>        =20
>>>> -> The DateTime class is available since PHP
>>>>        =20
>>>> 5.2.0 and ZF require PHP 5.2.4.
>>>>        =20
>>>> It would be very nice because than Zend_Date would be compatible to
>>>>        =20
>>>> other php libraries using DateTime and within ZF tests like the
>>>>        =20
>>>> following can simplify:
>>>>        =20
>>>> if ($date instanceof Zend_Date_DateObject) {
>>>>        =20
>>>>     $timestamp =3D $date->getUnixTimestamp();
>>>>        =20
>>>> } elseif ($date instanceof DateTime) {
>>>>        =20
>>>>     $timestamp =3D $date->getTimestamp();
>>>>        =20
>>>> } else {
>>>>        =20
>>>>     $timestamp =3D (float)$date;
>>>>        =20
>>>> }
>>>>        =20
>>>> Greetings,
>>>>        =20
>>>> Marc
>>>>        =20

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 10 Oct 2009 11:04:00 -0700
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Code Review

--0016368324b268181104759885d4
Content-Type: text/plain; charset=UTF-8

>
> (My personal experience with Crucible has not been great, but I have

hope that it can be configured to work better.)

Unfortunately, Crucible is the best of the bunch.  Using it with FishEye is
basically a requirement, as is throwing several gigs of RAM at it.  Once you
do that, it's not that bad.

-Matt

On Thu, Oct 8, 2009 at 12:19 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> -- Whitcraft, Jon <[email-masked]> wrote
> (on Thursday, 08 October 2009, 03:11 PM -0400):
> > I have been thinking about the problem that ZF ran into right after 1.9.3
> was
> > release a few weeks ago and then we had to rush a 1.9.3pl1 into release.
>  Would
> > using a tool such as Crucible from Atlassian help with this problem?
> >
> > What does everyone else think?
>
> In this case, it might not have helped.
>
> There were no tests for the original behavior, and it was not documented
> in the manual either -- it was only documented in passing within the API
> docs.
>
> We may use Crucible in the future (we actually have it setup already),
> but I want to explore a few other options as well.
>
> (My personal experience with Crucible has not been great, but I have
> hope that it can be configured to work better.)
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--0016368324b268181104759885d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0=
px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-=
left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex=
; ">
(My personal experience with Crucible has not been great, but I have</block=
quote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-ri=
ght: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; b=
order-left-color: rgb(204, 204, 204); border-left-style: solid; padding-lef=
t: 1ex; ">
hope that it can be configured to work better.)</blockquote><div><br></div>=
<div>Unfortunately, Crucible is the best of the bunch. =C2=A0Using it with =
FishEye is basically a requirement, as is throwing several gigs of RAM at i=
t. =C2=A0Once you do that, it&#39;s not that bad.</div>
<div><br></div><div>-Matt<br><br><div class=3D"gmail_quote">On Thu, Oct 8, =
2009 at 12:19 PM, Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex;">
-- Whitcraft, Jon &lt;[email-masked]&gt; wrote<br>
(on Thursday, 08 October 2009, 03:11 PM -0400):<br>
<div class=3D"im">&gt; I have been thinking about the problem that ZF ran i=
nto right after 1.9.3 was<br>
&gt; release a few weeks ago and then we had to rush a 1.9.3pl1 into releas=
e. =C2=A0Would<br>
&gt; using a tool such as Crucible from Atlassian help with this problem?<b=
r>
&gt;<br>
&gt; What does everyone else think?<br>
<br>
</div>In this case, it might not have helped.<br>
<br>
There were no tests for the original behavior, and it was not documented<br=
in the manual either -- it was only documented in passing within the API<br=
docs.<br>
<br>
We may use Crucible in the future (we actually have it setup already),<br>
but I want to explore a few other options as well.<br>
<br>
(My personal experience with Crucible has not been great, but I have<br>
hope that it can be configured to work better.)<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:m=
[email-masked]">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
</font></blockquote></div><br></div>

--0016368324b268181104759885d4--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 10 Oct 2009 19:18:01 -0400
From: "A.J. Brown" <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Code Review

Yes, yes, and yes.  After being trained in a using code review in a
team environment, I don't know how some teams survive without them!
It's the best way to encourage consistency, and is a very good
collaborative learning tool.  As long as they don't get too political,
that is.

On Sat, Oct 10, 2009 at 2:04 PM, Matthew Ratzloff
<[email-masked]> wrote:
>> (My personal experience with Crucible has not been great, but I have
>>
>> hope that it can be configured to work better.)
>
> Unfortunately, Crucible is the best of the bunch. =A0Using it with FishEy=
e is
> basically a requirement, as is throwing several gigs of RAM at it. =A0Onc=
e you
> do that, it's not that bad.
> -Matt
>
> On Thu, Oct 8, 2009 at 12:19 PM, Matthew Weier O'Phinney <[email-masked]=
m>
> wrote:
>>
>> -- Whitcraft, Jon <[email-masked]> wrote
>> (on Thursday, 08 October 2009, 03:11 PM -0400):
>> > I have been thinking about the problem that ZF ran into right after
>> > 1.9.3 was
>> > release a few weeks ago and then we had to rush a 1.9.3pl1 into releas=
e.
>> > =A0Would
>> > using a tool such as Crucible from Atlassian help with this problem?
>> >
>> > What does everyone else think?
>>
>> In this case, it might not have helped.
>>
>> There were no tests for the original behavior, and it was not documented
>> in the manual either -- it was only documented in passing within the API
>> docs.
>>
>> We may use Crucible in the future (we actually have it setup already),
>> but I want to explore a few other options as well.
>>
>> (My personal experience with Crucible has not been great, but I have
>> hope that it can be configured to work better.)
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
>> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>
>

--=20
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 5 Feb 2010 12:23:27 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Code freeze for 1.10.1 Sunday evening

Hey, all --

We're planning on rolling out 1.10.1 this coming Tuesday, 9 February
2010. Please have any bugfixes, translations, etc. in by Sunday evening
so that we can test and package on Monday.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 17 Oct 2009 06:15:49 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] JIRA Incubator Components Update

--0-787285619-1255785349=:59137
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Just requesting that we add in the missing Incubator components to JIRA if =
possible. At present we can't create issues for these.=0A=0AAssuming everyo=
ne has recovered from fixing 100 issues during the bug hunt! :P=0A=0APaddy=
=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survi=
vethedeepend.com=0AOpenID Europe Foundation Irish Representative
--0-787285619-1255785349=:59137
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Just requesting that we add in the missing Incubator component=
s to JIRA if possible. At present we can't create issues for these.<br><br>=
Assuming everyone has recovered from fixing 100 issues during the bug hunt!=
 :P<br><br>Paddy<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"=
><font style=3D"font-family: times new roman,new york,times,serif;" size=3D=
"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font=
><span style=3D"font-style: italic;"><font style=3D"font-family: times new =
roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blan=
k" href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><b=
r><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepen=
d.com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=
=3D"_blank"
 href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Repres=
entative</a><br></font></span></span><div><br></div></div></body></html>
--0-787285619-1255785349=:59137--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 13:46:04 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] test; please ignore

Testing to see if list server migration is complete; please ignore.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Tue, 24 Mar 2009 13:48:31 -0700
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] Release date for 1.8

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9ACC1.E499132E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all, I'm going to do something a little new for this release, but I
ask that you all do me a favor in return. I'm announcing the dates for
the release. The favor that I ask is that you do not discuss these dates
outside of this list. Yes, I know that the dates will likely get out
anyways- I'm just asking you not to immediately go out and tweet/blog
them. J Let's try to build some suspense with our users.

With no further do:

=20

Preview Release on 4/7: All features going in to ZF 1.8 must be
committed by EOD 4/5. We are currently working to get through all the
pending proposals by EOW, but feel free to ping me if you're concerned
about a specific proposal.

=20

Final Release on 4/28: Code freeze on 4/21. That's a hard-stop so have
everything ready to go by that date or be prepared to wait months for
the next minor release.

=20

These dates won't be a death-march, but I do put a lot of effort in to
making sure that we don't miss dates that other teams within Zend or at
our partners are depending on.

Feel free to mail me directly if you have any concerns.

=20

Thanks! It will be an exciting next month or so.

,Wil

------_=_NextPart_001_01C9ACC1.E499132E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Hi all, I&#8217;m going to do something a little =
new for
this release, but I ask that you all do me a favor in return. I&#8217;m =
announcing
the dates for the release. The favor that I ask is that you do not =
discuss these
dates outside of this list. Yes, I know that the dates will likely get =
out
anyways- I&#8217;m just asking you not to immediately go out and =
tweet/blog them.
<span style=3D'font-family:Wingdings'>J</span> Let&#8217;s try to build =
some
suspense with our users.<o:p></o:p></p>

<p class=3DMsoNormal>With no further do:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Preview Release on 4/7: All features going in to ZF =
1.8 must
be committed by EOD 4/5. We are currently working to get through all the
pending proposals by EOW, but feel free to ping me if you&#8217;re =
concerned
about a specific proposal.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Final Release on 4/28: Code freeze on 4/21. =
That&#8217;s a
hard-stop so have everything ready to go by that date or be prepared to =
wait
months for the next minor release.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>These dates won&#8217;t be a death-march, but I do =
put a lot
of effort in to making sure that we don&#8217;t miss dates that other =
teams
within Zend or at our partners are depending on.<o:p></o:p></p>

<p class=3DMsoNormal>Feel free to mail me directly if you have any =
concerns.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks! It will be an exciting next month or =
so.<o:p></o:p></p>

<p class=3DMsoNormal>,Wil<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9ACC1.E499132E--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 11:28:36 -0500
From: "A.J. Brown" <[email-masked]>
To: =?UTF-8?B?0KHQsNGI0LAg0KHRgtCw0LzQtdC90LrQvtCy0LjRmw==?=
	<[email-masked]>
Cc: Guilherme Blanco <[email-masked]>,
	Robin Skoglund <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Integration with Doctrine 2.0 is currently being discussed.  It's
generally agreed that we don't need yet another ORM.

On Thu, Nov 12, 2009 at 2:22 AM, =D0=A1=D0=B0=D1=88=D0=B0 =D0=A1=D1=82=D0=
=B0=D0=BC=D0=B5=D0=BD=D0=BA=D0=BE=D0=B2=D0=B8=D1=9B <[email-masked]> wr=
ote:
> Very nice!
> What about Zend_Model? Will we have some official component for M in MVC,=
 or
> we will stay on VC in zf 2.0?
> Will Zend_Tool get more powerful, generating models from db scheme, unit
> tests etc?
>
> Regards,
> Sa=C5=A1a Stamenkovi=C4=87
>
>
> On Wed, Nov 11, 2009 at 9:37 PM, Guilherme Blanco
> <[email-masked]> wrote:
>>
>> http://groups.google.com/group/php-standards/web/final-proposal
>>
>> On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[email-masked]> wrot=
e:
>> > On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney
>> > <[email-masked]> wrote:
>> >>
>> >> In looking at your above notes, I realize that there's another change
>> >> that needs to be noted in the docs: targetting the PHP Interop Group'=
s
>> >> specifications. The Exception usage is in line with our current
>> >> discussions, already. The package naming will work -- but the ideal i=
s
>> >> to ship package names as all lowercase. Any script for migration will
>> >> need to take that into account as well.
>> >
>> > Do you have a link for the PHP Interop Group specifications? I was
>> > about to make a comment in the wiki about the Exception usage, but I
>> > guess I should read up on the mentioned docs first.
>> >
>>
>>
>>
>> --
>> Guilherme Blanco - Web Developer
>> CBC - Certified Bindows Consultant
>> Cell Phone: +55 (16) 9215-8480
>> MSN: [email-masked]
>> URL: http://blog.bisna.com
>> S=C3=A3o Paulo - SP/Brazil
>
>

--=20
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Cc: [email-masked]
From: Carlton Gibson <[email-masked]>
To: "Matthew Weier O'Phinney" <[email-masked]>
Date: Mon, 27 Jul 2009 09:13:23 +0100
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
	ZendX Proposal

On 26 Jul 2009, at 22:58, Matthew Weier O'Phinney wrote:

>>
>> Finally, I think there needs to be a place (the contributors list  
>> maybe)
>> where people are welcome (encouraged) to come with questions about  
>> how to
>> proceed with an issue. Not enough people are subscribed to each  
>> issue in
>> the tracker to make this viable there. (Perhaps this is what the
>> contributors list is for but if so that needs to be better  
>> advertised.)
>
> This is exactly one purpose of the contributors list, and I encourage
> you to steer people here if they want to discuss issues from the
> tracker.

Okay, that's cool.

Can I just emphasise my thought that this aspect of the purpose of the  
contributors list needs to be made much clearer for  the newbie. IMHO  
it comes across as a place for "the hardcore" to discuss "big issues",  
rather than as also for "I'd like to help on this but I'm stuck/need  
some advice".

Regards,
Carlton

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Mon, 15 Mar 2010 22:49:47 +0100
Cc: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

Regarding abstract classes; I'm in favor of #8. Okay, it may make it a
little more difficult to think of meaningful names, but once the
author has thought of such name, people using the class can much more
easily judge by its name what it does. Think of Zend_View and
Zend_View_Abstract. Currently, it's totally unclear what the
difference between the two is (e.g. 'when am I to extend which?').
This could of course be easily solved by giving the latter a much more
descriptive names.

Regards,

Dolf Schimmel
Freeaqingme

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Wed, 30 Sep 2009 00:59:45 +0200
Subject: Re: [zf-contributors] Google Wave Invites

On Tuesday 29 September 2009 23:28:21 Alan Wagstaff wrote:
>I've just been watching the hour and a half(!) video on the Google Wave si=
te
>and whilst it looks very nice from a technical stand point, I'm not entire=
ly
>sure what I'd ever use it for.

I think for any collaborative project it's pretty useful. Add to that the=20
ability to extend it with robots and plugins, well really it's just whateve=
r=20
your imagination can cook up. There's already voice and video extensions, i=
'd=20
expect to see lots more of that sort of thing.

http://wave.google.com/help/wave/extensions.html

It's a piece of cake to drop an existing wave thread into a web page via so=
me=20
javascript, but the functionality is a bit limited right now. You can't cre=
ate=20
a wave via tje embedded javascript API, you can only really participate in =
an=20
existing wave. And at the moment that means being logged into your google w=
ave=20
sandbox account.

It will be interesting to see how things pan out tomorrow when wave.google.=
com=20
gets enabled. If necessary I might dust off my java books and create a robo=
t=20
or two (the only way to programatically create waves at the moment).

=2D-=20
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D
 =E2=98=98 Oscar Wilde

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 15 Mar 2010 22:14:31 +0100
From: Giorgio Sironi <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming 
	conventions

3) is really a good option if the chosen adjectives are meaningful.
The problem is the most valuable names are currently taken up from the
concrete classes or from the Facades, which may be subjected to
renaming to accomodate interface. All type hints and documentation of
dependencies references the interface names, so they should be given
precedence; the actual implementor is, in fact, an implementation
detail.
For instance some name refactorings may be:
Zend_Controller_Router_Interface => Zend_Controller_Router (no Facade
currently exists)
Zend_Filter => Zend_Filter_Chain, Zend_Filter_Interface => Zend_Filter
(Facade replaced, porting scripts could replace the occurrences)
Zend_View => Zend_View_NativePhp, Zend_View_Interface => Zend_View
Zend_Db_Adapter extracted as an interface (currently does not exist.)
5) and 7) are somewhat equivalent since abstract classes are
references only with the *extends* keyword and never in type hinting,
docblocks and such. As long as they are consistent they should not
create problems.
Both concrete classes and abstract ones should be referenced
*sparingly* respectively in factories/factory methods and extends
keywords. So in my opinion the focus should be in keeping natural and
simple the interface names.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 27 Feb 2010 14:56:23 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] ZF 2.0 development begins!

P=E1draic Brady wrote on 27.02.2010 14:11:
> Unless the tests are broken we could specify this going forward - littl=
e
> point re-editing old tests if they remain functional. Besides there may
> be some debate later on about how exactly we intend using Exceptions -
> the current class based exception usage ignores SPL for example (I've
> grown to like the standard types).

You should probably read the ZF 2.0 roadmap. We are going to have marker
interfaces for exceptions per class, which then get implemented by
concrete exceptions, which can extend SPL exceptions.

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Fri, 26 Feb 2010 00:45:49 +0100
Subject: Re: [zf-contributors] Git vs SVN. Was: ZF 2.0 development begins!

On Friday 26 February 2010 00:20:26 Dolf Schimmel wrote:
>> Tracking CLAs becomes more difficult. Currently with SVN, we only grant
>> access to those who have signed a CLA; if anybody can fork, we now need
>> some way to verify CLA status before pulling patches.
>
>After all there's always someone who's committing to the 'main'
>(master?) repository. You can always track who makes those 'main'
>commits? The person committing to the main repos should then keep
>track of
>everybody contributing to a certain commit has signed a CLA (as is
>done now when a patch is applied). There should however be a clear and
>uptodate list of everybody who signed a CLA (that's more than a
>selectbox in jira...).

I touched on this subject on the wiki page but it's worthwhile repeating he=
re.=20
With each CLA approval, a signing key can be issued and contributors can ma=
ke=20
use of the tag signing features of Git. Maintainers can then merge only sig=
ned=20
tags from pull requests and can sign their own commit pushes. A tag in Git =
can=20
be a marker at any commit history as well as a release tag.

There's the small matter of administrative overhead, but issuing signing ke=
ys=20
can be automated. In any case I would hope that the CLA process might recei=
ve=20
some attention anyway as it seems to be a common complaint that it's too sl=
ow;=20
and that key ZF project staff don't have sufficient access to the approved=
=20
agreements at various times.

=2D-=20
=E2=80=9CWhat can be asserted without proof can be dismissed without proof.=
=E2=80=9D
=2D Christopher Hitchens

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 09:31:16 -0700
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

--0016e6470e06e5a46f0482663972
Content-Type: text/plain; charset=UTF-8

View helpers are neither Strategy nor Command.  They are Template View or
View Helper.  In other words, they have their own pattern that is unrelated
to the goals of Strategy (multiple different ways of doing the same thing)
or Command (encapsulating user requests as undoable objects).

    http://martinfowler.com/eaaCatalog/templateView.html
    http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html

If you want a default method name, "execute" isn't owned by the command
pattern.  It's less confusing than "direct", in any event.

-Matt

On Sun, Mar 21, 2010 at 7:44 PM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> I'm trying to decide if "direct" (which suggests strategy) or
> "execute" makes more sense for the method name.

--0016e6470e06e5a46f0482663972
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

View helpers are neither Strategy nor Command. =C2=A0They are Template View=
 or View Helper. =C2=A0In other words, they have their own pattern that is =
unrelated to the goals of Strategy (multiple different ways of doing the sa=
me thing) or Command (encapsulating user requests as undoable objects).<div=
<br></div><div>=C2=A0=C2=A0 =C2=A0<a href=3D"http://martinfowler.com/eaaCat=
alog/templateView.html">http://martinfowler.com/eaaCatalog/templateView.htm=
l</a></div><div>=C2=A0=C2=A0 =C2=A0<a href=3D"http://java.sun.com/blueprint=
s/corej2eepatterns/Patterns/ViewHelper.html">http://java.sun.com/blueprints=
/corej2eepatterns/Patterns/ViewHelper.html</a></div>
<div><br></div><div>If you want a default method name, &quot;execute&quot; =
isn&#39;t owned by the command pattern. =C2=A0It&#39;s less confusing than =
&quot;direct&quot;, in any event.</div><div><br></div><div>-Matt<br><br><di=
v class=3D"gmail_quote">
On Sun, Mar 21, 2010 at 7:44 PM, Matthew Weier O&#39;Phinney <span dir=3D"l=
tr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex;">
I&#39;m trying to decide if &quot;direct&quot; (which suggests strategy) or=
<br>
&quot;execute&quot; makes more sense for the method name.</blockquote></div=
></div>

--0016e6470e06e5a46f0482663972--

nFrom nobody Wed Apr  7 08:46:18 2010
Date: Wed, 31 Mar 2010 18:02:30 +0300
From: Dmitry Dulepov <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>
Subject: Re: [zf-contributors] Plugin implementations
Content-Length: 356

Hello!

Matthew Weier O'Phinney wrote:
> Would it make sense to keep the original interfaces (filter, isValid,
> render, etc.), but also implement __invoke() -- having it proxy to the
> appropriate interface method?

+1. It is good for both speed and compatibility.

-- 
Dmitry Dulepov
Twitter: http://twitter.com/dmitryd/
Web: http://dmitry-dulepov.com/

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Sender: [email-masked]
From: "Sean P. O. MacCath-Moran" <[email-masked]>
Date: Tue, 15 Dec 2009 22:03:12 -0500
To: [email-masked], [email-masked]
Subject: Re: [zf-contributors] Fwd

--000e0cd761806dfacc047acfc0b1
Content-Type: text/plain; charset=ISO-8859-1

.... and he'll be summarily removed from this list, right?

On Tue, Dec 15, 2009 at 8:57 PM, H.N. <[email-masked]> wrote:

>  yhbnokdc - oqvffooxgafduw - prkjojirq
>  <snipped the mind numbing garbage>
> **
>

--000e0cd761806dfacc047acfc0b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

.... and he&#39;ll be summarily removed from this list, right?<br><br><div =
class=3D"gmail_quote">On Tue, Dec 15, 2009 at 8:57 PM, H.N. <span dir=3D"lt=
r">&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div bgcolor=3D"#FFFFFF">
<font color=3D"#000000" face=3D"Arial" size=3D"2">
<div align=3D"center"><font color=3D"#ffffff" size=3D"1">yhbnokdc - oqvffoo=
xgafduw - prkjojirq</font></div>
<div align=3D"center">=A0&lt;snipped the mind numbing garbage&gt;<br></div>
<div align=3D"center"><font color=3D"#d5d500" face=3D"Times New Roman" size=
=3D"7"><u></u></font></div></font></div></blockquote></div><br>

--000e0cd761806dfacc047acfc0b1--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 05 Feb 2010 09:56:19 +0100
From: Carlos Medina <[email-masked]>
Reply-To: [email-masked]
Organization: SimplyNetworks
To: Nigel Chapman <[email-masked]>
CC: Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

Nigel Chapman schrieb:
> Hi All,  (? -- not sure how active this list is.)
>
> Just a note to announce a new proposal:
>
> Zend_Array is a fluent wrapper for PHP's array functions.
>
> It lets you deal with arrays rather as you would in Ruby or JQuery,
> with chained operators and closures.
>
> Over the next few weeks, I'll be workign on the doc standards and test
> suite, and thinking if it needs more (or less!) core methods.
>
> Comments? Improvements?
>
> * http://chapman.id.au/zend-array/
>
> * http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapman
>
> I sometimes appear on #zftalk as kale77in.
>
> Thanks,
>
> Nigel.
>
>
>   
Hi Nigel,
i think this is a very usefull proposal. The question is: performance? 
have you tests about this.

Regards

Carlos

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Nico Edtinger <[email-masked]>
To: Matthew Ratzloff <[email-masked]>
Date: Wed, 23 Sep 2009 13:11:08 +0200
Cc: [email-masked]
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?

Matthew Ratzloff wrote:
> Breaking BC in a mini release is bad news.  I would strongly suggest  
> adding
> a new option in the config array (second parameter) to control  
> inflection,
> with the default the old style.  This way, in your config you can say:
>
> db.newInflector = true

Do we really need a new option? What I've read the problem is people  
writing 'PDO_MYSQL' or 'pdo_mysql'. It should suffice to convert the  
name if it's completely uppercase or lowercase and else leave as is.

nico

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 14:16:44 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] New Sections for Zend Framework 2.0 Roadmap

-- Kevin McArthur <[email-masked]> wrote
(on Tuesday, 17 November 2009, 10:34 AM -0800):
> Ok, my $0.02 (roll your eyes here)
> 
> Plugin stuff -- all sounds good... Maybe the "Interface" part of
> ConfigurableInterface is somewhat redundant.... or might be better
> as IConfigurable... (I assume this is about being worried that the
> PHP guys will add a same named interface in the future (ala the Date
> fiasco))

This is already in our coding standard, and was part of the original
framework interop meeting. There are comments regarding this on the main
roadmap page if you need the rationale.

> --
> 
> Zend-Form 2.0... I'm not a huge fan of the current (or this
> proposed) architecture. I'd rather see a component that takes PRG
> (Post-Redirect-Get) as the default mechanism and extrapolates
> interfaces from there... 

PRG is something that can be built around forms, but has nothing to do
with the main purpose of the form component, which is to encapsulate
form element metadata and validation, and to facilitate rendering. PRG
is something you'd handle in your controller. We should not be tightly
binding forms and controllers; they should remain loosely coupled (if at
all coupled).

> There should be strong integration with Zend_Session 2.0, and I'd like
> to see the Decorators and Translators moved to the view layer -- as
> they have little to do with the program logic and are purely
> presentation. 

Which, as I note in the proposal, is the plan. :)

> The Decorators could be integrated tightly while still being
> independent of the validation specification. Zend_Form doesn't really
> need to know if data is coming from an input type=text, a textarea, or
> a select list... its all strings at the end of the process. 

Which is a driving part of the redesign; sounds like we're in agreement.
:)

There may still be discrete element types, as this makes some strategies
for decoration easier, but the basics are that the form and form
elements are simply metadata containers, and you then attach filter and
validation chains, or pass them through decorator chains.

> I'd also recommend some sort of 'partial' for reusable forms decorator
> specs.

This can be achieved already via the ViewScript decorator, which simply
passes the "element" to a partial. This will be retained.

<snip>

> This is obviously a quick overview, but the idea is to more tightly
> tie Zend_Form in with the request cycle, assume PRG is the priority
> method for forms, and treat decoration in the view, not the model or
> controller.

As noted, I don't think PRG has anything to do with the forms, but
everything to do with controllers, and should be treated there. It's
already trivially easy to accomplish.

> The router changes look good as described...
> 
> 
> Kevin
> 
> 
> 
> Matthew Weier O'Phinney wrote:
> >Hey, all --
> >
> >There have been several new sections posted to the 2.0 roadmap that I
> >want to bring to your attention:
> >
> > * Plugins:
> >   http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures
> >
> > * Zend_Form:
> >   http://framework.zend.com/wiki/display/ZFDEV2/Zend_Form+2.0
> >
> > * Router:
> >   http://framework.zend.com/wiki/display/ZFDEV2/Zend_Controller_router+2.0
> >
> >Please review and comment when you have time.
> >
> >Thanks!
> >
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 22 Jan 2010 23:16:02 +0100
From: Marc Bennewitz <[email-masked]>
To: [email-masked]
Subject: [zf-contributors] Zend_Date & build-in class DateTime

This is a multi-part message in MIME format.
--------------070406050501020704070607
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Hi all,

Does is matter that Zend_Date doesn't extends the build-in DateTime class ?
-> The DateTime class is available since PHP 5.2.0 and ZF require PHP 5.2.4.

It would be very nice because than Zend_Date would be compatible to
other php libraries using DateTime and within ZF tests like the
following can simplify:

if ($date instanceof Zend_Date_DateObject) {
    $timestamp = $date->getUnixTimestamp();
} elseif ($date instanceof DateTime) {
    $timestamp = $date->getTimestamp();
} else {
    $timestamp = (float)$date;
}

Greetings,
Marc

--------------070406050501020704070607
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO-885=
9-15">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
Hi all,<br>
<br>
Does is matter that Zend_Date doesn't extends the build-in DateTime
class ?<br>
-&gt; The DateTime class is available since <acronym class=3D"acronym">PH=
P</acronym>
5.2.0 and ZF require <acronym class=3D"acronym">PHP</acronym> 5.2.4.<br>
<br>
It would be very nice because than Zend_Date would be compatible to
other php libraries using DateTime and within ZF tests like the
following can simplify:<br>
<br>
if ($date instanceof Zend_Date_DateObject) {<br>
=A0=A0=A0 $timestamp =3D $date-&gt;getUnixTimestamp();<br>
} elseif ($date instanceof DateTime) {<br>
=A0=A0=A0 $timestamp =3D $date-&gt;getTimestamp();<br>
} else {<br>
=A0=A0=A0 $timestamp =3D (float)$date;<br>
}<br>
<br>
Greetings,<br>
Marc<br>
</body>
</html>

--------------070406050501020704070607--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 27 Feb 2010 06:22:40 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

--0-2016075615-1267280560=:21249
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://www.survi=
vethedeepend.com=0AOpenID Europe Foundation Irish Representative=0A=0A=0A=
=0A=0A----- Forwarded Message ----=0AFrom: P=E1draic Brady <padraic.brady@y=
ahoo.com>=0ATo: Ben Scholzen 'DASPRiD' <[email-masked]>=0ASent: Sat, Febr=
uary 27, 2010 2:22:16 PM=0ASubject: Re: [zf-contributors] ZF 2.0 developmen=
t begins!=0A=0A=0AAnd you should probably...er...nevermind. I forgot I used=
 up all my shotgun rounds yesterday ;).=0A=0AI was thinking of Matthew's Ph=
ly POC which don't do this currently (if I remember correctly). I know its =
a POC, so not definitive.=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutu=
ra.com=0Ahttp://www.survivethedeepend.com=0AOpenID Europe Foundation Irish =
Representative=0A=0A=0A=0A=0A=0A________________________________=0AFrom: Be=
n Scholzen 'DASPRiD' <[email-masked]>=0ATo: [email-masked]=
m=0ASent: Sat, February 27, 2010 1:56:23 PM=0ASubject: Re: [zf-contributors=
] ZF 2.0 development begins!=0A=0A-----BEGIN PGP SIGNED MESSAGE-----=0AHash=
: SHA1=0A=0AP=E1draic Brady wrote on 27.02.2010 14:11:=0A> Unless the tests=
 are broken we could specify this going forward - little=0A> point re-editi=
ng old tests if they remain functional. Besides there may=0A> be some debat=
e later on about how exactly we intend using Exceptions -=0A> the current c=
lass based exception usage ignores SPL for example (I've=0A> grown to like =
the standard types).=0A=0AYou should probably read the ZF 2.0 roadmap. We a=
re going to have marker=0Ainterfaces for exceptions per class, which then g=
et implemented by=0Aconcrete exceptions, which can extend SPL exceptions.=
=0A-----BEGIN PGP SIGNATURE-----=0AVersion: GnuPG v1.4.9 (GNU/Linux)=0AComm=
ent: Using GnuPG with Mozilla - http://enigmail.mozdev.org=0A=0AiEUEARECAAY=
FAkuJJIcACgkQ0HfT5Ws789CoDACgtFzallMhFmgaK9yHE5O2y0qz=0Ar3kAl2Xev9wFQoDjKZ1=
juGTcg7w0zgQ=3D=0A=3D+T/3=0A-----END PGP SIGNATURE-----=0A
--0-2016075615-1267280560=:21249
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt"><br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);"><f=
ont style=3D"font-family: times new roman,new york,times,serif;" size=3D"3"=
><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></span></font><s=
pan style=3D"font-style: italic;"><font style=3D"font-family: times new rom=
an,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br><=
a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.c=
om">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"_=
blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish =
Representative</a><br></font></span></span><div><br></div><div style=3D"fon=
t-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div =
style=3D"font-family: times new
 roman,new york,times,serif; font-size: 12pt;"><font face=3D"Tahoma" size=
=3D"2">----- Forwarded Message ----<br><b><span style=3D"font-weight: bold;=
">From:</span></b> P=E1draic Brady &lt;[email-masked]&gt;<br><b><s=
pan style=3D"font-weight: bold;">To:</span></b> Ben Scholzen 'DASPRiD' &lt;=
[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">Sent:</span><=
/b> Sat, February 27, 2010 2:22:16 PM<br><b><span style=3D"font-weight: bol=
d;">Subject:</span></b> Re: [zf-contributors] ZF 2.0 development begins!<br=
></font><br>=0A<meta http-equiv=3D"x-dns-prefetch-control" content=3D"off">=
<div style=3D"font-family: times new roman,new york,times,serif; font-size:=
 12pt;">And you should probably...er...nevermind. I forgot I used up all my=
 shotgun rounds yesterday ;).<br><br>I was thinking of Matthew's Phly POC w=
hich don't do this currently (if I remember correctly). I know its a POC, s=
o not definitive.<br><div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191);=
"><font style=3D"font-family: times new roman,new york,times,serif;" size=
=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></span></f=
ont><span style=3D"font-style: italic;"><font style=3D"font-family: times n=
ew roman,new york,times,serif;" size=3D"3"><span><a target=3D"_blank" href=
=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a></span><b=
r><span><a target=3D"_blank" href=3D"http://www.survivethedeepend.com">http=
://www.survivethedeepend.com</a></span><br><a rel=3D"nofollow" target=3D"_b=
lank"
 href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Repres=
entative</a><br></font></span></span><div><br></div><div style=3D"font-fami=
ly: times new roman,new york,times,serif; font-size: 12pt;"><br><div style=
=3D"font-family: tahoma,new york,times,serif; font-size: 8pt;"><font face=
=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font-weight: bold;"=
>From:</span></b> Ben Scholzen 'DASPRiD' &lt;[email-masked]&gt;<br><b><sp=
an style=3D"font-weight: bold;">To:</span></b> [email-masked]=
om<br><b><span style=3D"font-weight: bold;">Sent:</span></b> Sat, February =
27, 2010 1:56:23 PM<br><b><span style=3D"font-weight: bold;">Subject:</span=
></b> Re: [zf-contributors] ZF 2.0 development begins!<br></font><br>=0A---=
--BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>P=E1draic Brady wrote =
on 27.02.2010 14:11:<br>&gt; Unless the tests are broken we could specify t=
his going forward - little<br>&gt; point re-editing old tests if they remai=
n functional. Besides there may<br>&gt; be some debate later on about how e=
xactly we intend using Exceptions -<br>&gt; the current class based excepti=
on usage ignores SPL for example (I've<br>&gt; grown to like the standard t=
ypes).<br><br>You should probably read the ZF 2.0 roadmap. We are going to =
have marker<br>interfaces for exceptions per class, which then get implemen=
ted by<br>concrete exceptions, which can extend SPL exceptions.<br>-----BEG=
IN PGP SIGNATURE-----<br>Version: GnuPG v1.4.9 (GNU/Linux)<br><span><span>C=
omment: Using GnuPG with Mozilla - <a target=3D"_blank"
 href=3D"http://enigmail.mozdev.org">http://enigmail.mozdev.org</a></span><=
/span><br><br>iEUEARECAAYFAkuJJIcACgkQ0HfT5Ws789CoDACgtFzallMhFmgaK9yHE5O2y=
0qz<br>r3kAl2Xev9wFQoDjKZ1juGTcg7w0zgQ=3D<br>=3D+T/3<br>-----END PGP SIGNAT=
URE-----<br></div></div>=0A</div><meta http-equiv=3D"x-dns-prefetch-control=
" content=3D"on"></div></div>=0A</div></body></html>
--0-2016075615-1267280560=:21249--

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 16:40:31 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 Status: 26 Feb 2010

-- Giorgio Sironi <[email-masked]> wrote
(on Friday, 26 February 2010, 08:04 PM +0100):
> On Fri, Feb 26, 2010 at 2:59 PM, Matthew Weier O'Phinney <[email-masked]>
> wrote:
> 
>      * To package individual components, we need some way to determine
>       dependencies. Currently, require_once statements can help with that,
>       but stripping them makes this harder. My solution is to add @uses
>       annotations at the class docblock level. This assists the API docs,
>       but also should make it possible to use automated scanners to
>       determine dependencies. 
> 
> 
> Correct me if I'm wrong, but can't use statements be used for this purpose? To
> refer to a class in an external namespace an use Zend\Xxx statement is
> necessary, and forbid fully qualified class names such as \Zend\Yyy should be
> enough and simpler to enforce than @uses annotations.

Yes -- and this will make that step that much easier. Consider this an
initial preparation for conversion to namespaces. :)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 16:37:34 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

-- Juozas <[email-masked]> wrote
(on Wednesday, 31 March 2010, 08:59 PM +0100):
> -1 from me too.
>=20
> Looking at the interface it's absolutely not clear what are those two
> methods intended for. Interfaces should not require looking at the
> actual implementation to get that some methods are just for the sake
> of making testing easier (?) and in all implementations just provide a
> proxy.

Actually, I'm not talking about the implementation being harder, but the
fact that conversion and migration takes a lot more effort, due to the
fact that more code needs to change in the unit tests. As an example, I
had the whole Filter tree migrated in just over an hour yesterday -- but
the tests took another 5-6 hours to complete, due to the number of
changes necessary to make them comply with the new signatures.

But if it makes the implementation better, then it's worth it. I'm just
questioning whether that's the case.

> Personally, I think that once you can do things in more than 1 way,
> it's confusing and misleading (not in all senses, but in a sense of
> method call). Now it *might* work if that proxy is provided by
> abstract class (just to make code more backwards compatible/any other
> reason), but still since we are talking about 2.0 here, I'd rather
> have only __invoke.
>=20
> Speaking of tests, I didn't completely get where the problem lies:
>=20
> $filter->filter($value);
>=20
> becomes:
>=20
> $filter($value);
>=20
> is this the refactoring you are mentioning?

Yes -- and then a bit more.

Often setUp() creates the filter:

    $this->_filter =3D new SomeFilter();

One problem that arises is that PHP is kind of stupid about calling
__invoke on object members. You'd think this would work:

    $this->_filter($value);

But it doesn't -- instead, PHP thinks you're calling the method
"_filter" on the current object, and then FATALs on you. So you have to
do this:

    $filter   =3D $this->_filter;
    $filtered =3D $filter($value);

Knowing this limitation, I can see other potential issues down the line
-- you can't simply call the object as if it were a function; you have
to think about whether you're operating on an object member or not, and
then change your methodology accordingly. I see that as a potential
drawback to using __invoke().

> On Wed, Mar 31, 2010 at 8:38 PM, Lukas K=F6ll <[email-masked]> wrote=
:
> > -1 from me, too - I'm totally agreeing with Renan.
> > Additionally I don't think design decisions should be based on how mu=
ch work it
> > is to write the corresponding unit tests. Don't get me wrong, of cour=
se the code
> > must be testable. But especially for framework code I think that a lo=
w overhead
> > should be preferred against easier testability - infact framework cod=
e is
> > written (or changed) far more seldom than executed.
> >
> > If, however you decide to use __invoke as proxy, I would recommend to=
 somehow
> > prevent the proxied methods (filter, validate) to be called from outs=
ide or at least mark them as deprecated
> > so client code _must_ use invoke and we could then remove the proxies=
 later on if
> > it should be decided that the tests are rewritten.
> >
> > best regards
> >
> > Lukas K=F6ll
> >
> >> -1
> >>
> >> Talking to my coworkers, a big piece of people take a little more ti=
me
> >> to understand something when there is more than one way to do what
> >> they want to do. I think that when we start a new project with
> >> unnecessary duplicated features it's not good. This usually happens
> >> after years, we should get this situations away. Obviously sometimes
> >> it's interesting we provide alternative ways to achieve a goal, but
> >> for those situations =A0(filter, validator...) it's not.
> >>
> >>>> The benefits:
> >>>>
> >>>> * Fewer changes necessary to existing unit tests
> >>
> >> time is the solution ;-)
> >>
> >>>> * interface method names may be more descriptive of intent
> >>
> >> they should pick a better name for their variables, like $filterFloa=
t,
> >> $filterAlpha
> >>
> >>>> Problems:
> >>>>
> >>>> * Using __invoke() introduces overhead -- 2 method calls instead o=
f one
> >>>> * Redundancy (two methods doing the same thing)
> >>
> >> that's my point! this extra way is not relevant, this one adds no ne=
w feature
> >>
> >>>> * A few extra tests to write (to ensure __invoke works as expecte)
> >>
> >> my 1 cent ;-)
> >>
> >> --
> >> Renan de Lima Barbosa
> >> gtalk/msn: [email-masked]
> >> skype: renandelima
> >> +55 61 8166-7755
> >> renandelima.com
> >>
> >>
> >>
> >> On 31 March 2010 11:38, Dennis Winter <[email-masked]=
om> wrote:
> >>> +1 on this! It's ok to have two methods for the same thing! And the=
 benefit
> >>> of clearer interfaces is overwhelming the disadvantages!
> >>> Just my 2 cents!
> >>>
> >>> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney <matthew@zen=
d.com>:
> >>>
> >>>> Greetings, all --
> >>>>
> >>>> Per the roadmap, one change we're planning on making is making plu=
gin
> >>>> usage consistent across components: plugins will implement __invok=
e(),
> >>>> which makes them inherently callable.
> >>>>
> >>>> In our refactoring branch, I've done this now with Zend_Filter. Ho=
wever,
> >>>> it required a ton of refactoring on the unit tests (had to either =
call
> >>>> __invoke() directly, or $filter($value)), and it got me to thinkin=
g:
> >>>>
> >>>> Would it make sense to keep the original interfaces (filter, isVal=
id,
> >>>> render, etc.), but also implement __invoke() -- having it proxy to=
 the
> >>>> appropriate interface method?
> >>>>
> >>>> As an example:
> >>>>
> >>>> =A0 interface Filter
> >>>> =A0 {
> >>>> =A0 =A0 =A0 public function filter($value);
> >>>> =A0 =A0 =A0 public function __invoke($value);
> >>>> =A0 }
> >>>>
> >>>> =A0 class Digits implements Filter
> >>>> =A0 {
> >>>> =A0 =A0 =A0 public function filter($value)
> >>>> =A0 =A0 =A0 {
> >>>> =A0 =A0 =A0 =A0 =A0 // ... logic...
> >>>> =A0 =A0 =A0 }
> >>>>
> >>>> =A0 =A0 =A0 public function __invoke($value)
> >>>> =A0 =A0 =A0 {
> >>>> =A0 =A0 =A0 =A0 =A0 return $this->filter($value);
> >>>> =A0 =A0 =A0 }
> >>>> =A0 }
> >>>>
> >>>> The benefits:
> >>>>
> >>>> * Fewer changes necessary to existing unit tests
> >>>> * interface method names may be more descriptive of intent
> >>>>
> >>>> Problems:
> >>>>
> >>>> * Using __invoke() introduces overhead -- 2 method calls instead o=
f one
> >>>> * Redundancy (two methods doing the same thing)
> >>>> * A few extra tests to write (to ensure __invoke works as expecte)
> >>>>
> >>>> After discussion with Ralph and Alex, I'm leaning towards having
> >>>> __invoke() as an _additional_ method, instead of replacing existin=
g
> >>>> methods.
> >>>>
> >>>> Any thoughts or comments?
> >>>>
> >>>> --
> >>>> Matthew Weier O'Phinney
> >>>> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> >>>> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> >>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >>>
> >
> >
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 30 Jul 2009 20:36:33 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.9.0 sanity check tarballs uploaded

Greetings!

Packaging is complete for release 1.9.0 of Zend Framework. Until the
release tomorrow, you can find packages at:

  * Full packages:
    http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramework-1.9.0.tar.gz
    http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramework-1.9.0.zip
  * Minimal packages:
    http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramework-1.9.0-minimal.tar.gz
    http://framework.zend.com/releases/preview/ZendFramework-1.9.0/ZendFramework-1.9.0-minimal.zip

We also have packages up for AMF, Gdata, and InfoCard, and I can provide
you those URLs if you need them.

We will be releasing to the general public tomorrow morning, EDT, and I
will be sending out announcements to the mailing lists and posting on
DevZone once we have.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:18 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 16:50:44 +0100
From: drm <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Hi Matthew,

Matthew Weier O'Phinney wrote:
> Um... not to be an ass here, but you state "I am speaking from my own
> experience, which is, of course, subjective," and then make an
> assumption that we agree. ;)
>   
It's not an assumption, it's a question :-) I'm sorry if that came
across rhetorical, that wasn't my intention.

> I've heard both sides of this argument: those who would prefer to be
> able to retrieve only those components they use, and those who feel the
> framework only makes sense when distributed in its entierty. I think
> both arguments have merit, and ideally I'd like to offer both
> strategies -- which can be accomplished via a PEAR channel.
>
> The problem is building infrastructure for packaging individual
> components -- something that gets more difficult with each new component
> added to the framework.
>   
I agree that it is, well, "a challenge" to say the least. I think it
could be reconsidered after documentation for it is drafted up.

> It's an interesting idea. The problem with having groupings in the
> documentation is that some packages may overlap, and also that there may
> be some confusion as to what section to look in: "is Zend_Form in the
> Core, Security, or MVC section?" An alphabetical list is simple to
> traverse and comprehend.
I agree, I don't think main sections in the documentation would be a
solution (I think that is what you mean, right?). Maybe more a kind of
"the structure of ZF" section, with how the different packages relate to
each other, and what their relations are (and of course what they are
good for in the first place in a few lines, referring to the package's
own page). I think a dependency graph would be a great start, just to
get in insight on how "intertwined" things are right now. I don't think
it would prove too complicated at a main level, really.

I hope I can find some time this week to give it a shot, just to get
(and give) an impression.

By the way: on what bases gets decided if something goes into the
minimal package right now?

Gerard

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 25 Feb 2010 17:08:39 -0300
From: Guilherme Blanco <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] ZF 2.0 development begins!

sfYaml is a good component to be reused. =3D)

We should all reuse components instead of keep reinventing the wheel everyd=
ay!

Cheers,

On Thu, Feb 25, 2010 at 4:38 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Ryan Albertson <[email-masked]> wrote
> (on Thursday, 25 February 2010, 02:20 PM -0500):
>> Another consideration of mine would be if Doctrine is used, would ZF use=
 yaml
>> like symfony does for the generation of schemas and model classes by mak=
ing
>> Zend_Tool work with yaml like the symfony CLI?
>
> One consideration I have for 2.0 is to do a YAML backend for
> Zend_Config, which would consume sfYaml. This would allow you to do what
> you're suggesting, while simultaneously using the same configuration
> file(s) with your ZF application.
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--=20
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [email-masked]
URL: http://blog.bisna.com
S=C3=A3o Paulo - SP/Brazil

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 18 Mar 2010 15:04:05 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Poll results on ZF2 coding standards

Hey, all --

I'd like to thank everyone for their input this week regarding the
various coding standards issues Ralph and myself brought up. 

Based on the discussions/votes on the mailing list, I've published the
decisions on the wiki:

    http://framework.zend.com/wiki/display/ZFDEV2/ZF+2.0+Coding+Standards+Addendums

This will require a fair bit of renaming as we start going through the
code base, but I think the results will be solid, and will hopefully
assist in making the code less ambiguous for those perusing it.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 22 Sep 2009 13:11:27 -0700
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?

--0016361e89ec1571290474303476
Content-Type: text/plain; charset=UTF-8

First, a little more clarity.

The original bug is here: http://framework.zend.com/issues/browse/ZF-5606

This code make ZendX_Db_Adapter_Firebird to become Zendx_Db_Adapter, which
> can't be found on Linux...

> Also problem for user's Db libraries.

You've got a situation here where ZendX code does not work properly with
Zend code.  This is most definitely a bug, and it is a very small change for
most authors.  Furthermore, the documentation has always showed user-land
code that works in the new implementation.

That said...

Breaking BC in a mini release is bad news.  I would strongly suggest adding
a new option in the config array (second parameter) to control inflection,
with the default the old style.  This way, in your config you can say:

db.newInflector = true

-Matt

On Tue, Sep 22, 2009 at 11:01 AM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> I'd like the opinion of the various contributors, if you could.
>
> There's been a lot of debate about the BC break regarding
> Zend_Db::factory(), and I'm even hearing rumblings about forks over it.
> Putting all personal issues aside, I'd like to hear your thoughts about
> how we should proceed.
>
> First, I need to give some background about the situation we find
> ourselves in, and not just from the code side.
>
> On the code side, the matter is spelled out in the release announcement:
>
>    http://dz.zend.com/a/10050
>
> On the non-code side, we have a number of issues going on.
>
> First, on my side, I did not realize a BC break had occurred until this
> morning -- and not from any official report in response to the sanity
> check packages, but from an innocent post on fw-general. At that time,
> we were already in progress deploying the packages and site updates.
> For better or worse, re-packaging and releasing takes ~6-8 hours. It's
> non-trivial, and this is why we do it on a schedule (what takes so long?
> primarily building the manuals, building the API docs, and creating the
> manual search indexes).
>
> Second, we have an added onus this week: our colo facility is being
> relocated at the end of the week, and we have a very small window for
> getting new packages released before we have to sync and do a site
> freeze.
>
> The options I can see are:
>
>  * Yank the current package, and rebuild.
>  * Create a patch-level package (1.9.3pl1), and deprecate 1.9.3.
>  * Do nothing, and continue on.
>
> I understand that many do not see original behavior as buggy, and relied
> on it. I also feel that the new solution is much better -- but if
> somebody can propose and implement a better one, I'm open to it.
>
> I'd like to make a decision in the next few hours; if new packages are
> needed, we need to make them ASAP.
>
> Please spread the word about this post and help in the process.
>
> Thanks!
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--0016361e89ec1571290474303476
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>First, a little more clarity.</div><div><br></div><div>The original bu=
g is here:=C2=A0<a href=3D"http://framework.zend.com/issues/browse/ZF-5606"=
>http://framework.zend.com/issues/browse/ZF-5606</a></div><div><br></div><d=
iv><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right=
: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; bord=
er-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: =
1ex; ">
This code make ZendX_Db_Adapter_Firebird to become Zendx_Db_Adapter, which =
can&#39;t be found on Linux...</blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-l=
eft: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex; ">
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px=
; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-wi=
dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex; ">
Also problem for user&#39;s Db libraries.</blockquote><div><br></div><div>Y=
ou&#39;ve got a situation here where ZendX code does not work properly with=
 Zend code. =C2=A0This is most definitely a bug, and it is a very small cha=
nge for most authors. =C2=A0Furthermore, the documentation has always showe=
d user-land code that works in the new implementation.</div>
<div><br></div><div>That said...</div><div><br></div><div>Breaking BC in a =
mini release is bad news. =C2=A0I would strongly suggest adding a new optio=
n in the config array (second parameter) to control inflection, with the de=
fault the old style. =C2=A0This way, in your config you can say:</div>
<div><br></div><div>db.newInflector =3D true</div><div><br></div><div>-Matt=
<br><br><div class=3D"gmail_quote">On Tue, Sep 22, 2009 at 11:01 AM, Matthe=
w Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:matthew@zend.=
com">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">I&#39;d like the opinion of the various con=
tributors, if you could.<br>
<br>
There&#39;s been a lot of debate about the BC break regarding<br>
Zend_Db::factory(), and I&#39;m even hearing rumblings about forks over it.=
<br>
Putting all personal issues aside, I&#39;d like to hear your thoughts about=
<br>
how we should proceed.<br>
<br>
First, I need to give some background about the situation we find<br>
ourselves in, and not just from the code side.<br>
<br>
On the code side, the matter is spelled out in the release announcement:<br=
<br>
 =C2=A0 =C2=A0<a href=3D"http://dz.zend.com/a/10050" target=3D"_blank">http=
://dz.zend.com/a/10050</a><br>
<br>
On the non-code side, we have a number of issues going on.<br>
<br>
First, on my side, I did not realize a BC break had occurred until this<br>
morning -- and not from any official report in response to the sanity<br>
check packages, but from an innocent post on fw-general. At that time,<br>
we were already in progress deploying the packages and site updates.<br>
For better or worse, re-packaging and releasing takes ~6-8 hours. It&#39;s<=
br>
non-trivial, and this is why we do it on a schedule (what takes so long?<br=
primarily building the manuals, building the API docs, and creating the<br>
manual search indexes).<br>
<br>
Second, we have an added onus this week: our colo facility is being<br>
relocated at the end of the week, and we have a very small window for<br>
getting new packages released before we have to sync and do a site<br>
freeze.<br>
<br>
The options I can see are:<br>
<br>
=C2=A0* Yank the current package, and rebuild.<br>
=C2=A0* Create a patch-level package (1.9.3pl1), and deprecate 1.9.3.<br>
=C2=A0* Do nothing, and continue on.<br>
<br>
I understand that many do not see original behavior as buggy, and relied<br=
on it. I also feel that the new solution is much better -- but if<br>
somebody can propose and implement a better one, I&#39;m open to it.<br>
<br>
I&#39;d like to make a decision in the next few hours; if new packages are<=
br>
needed, we need to make them ASAP.<br>
<br>
Please spread the word about this post and help in the process.<br>
<br>
Thanks!<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:m=
[email-masked]">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
</font></blockquote></div><br></div></div>

--0016361e89ec1571290474303476--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 5 Dec 2009 11:08:01 +0530
From: Sawan Ruparel <[email-masked]>
To: Juozas <[email-masked]>
Cc: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend Framework modularity and application 
	structure

--00504502b0a2a780ca0479f4a0d6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Juozas,

I am using zend framework version 1.7.

The application in which I am using is pretty large and has few modules lik=
e
pos sale, website, backoffice (having, vendors, sales rep, po, invoice,
accounts, receiving products, create inventory, many small modules to do
adjustments in inventory, store transfers, website, admin). Each module
listed has a lot of complex logic and of course so many features.

We have structured the project like below:

-POS (similar structure followed for each module, Vendor Login, Backoffice
and POS)
--application
---controller
---views
--bootstrap.php
--public
--index.php
---js
---css

Imp: We have a folder Called "Core" this has all the table classes +
business logic classes, so each module access this core in order to perform
what they have to.

This way, I can control entire application by making changes in core folder
only.

I am not sure if this 100% best way to do it, but I am loving it so far, an=
d
have more than 80 programmers working on it since a 1 year now, and
everything is going smooth.

I would love to share more about this with everyone using Zend Framework if
they are interested.

I hope above helps you!

Thanks!

Sawan
phone: +1 (251) 2SAWANR
"Nothing is particularly hard if you divide it into small jobs." - Henry
Ford

On Sat, Dec 5, 2009 at 9:28 AM, Juozas <[email-masked]> wrote:

> Hello everyone,
>
> as you know, Zend Framework 2.0 is having a major rewrite in some parts a=
nd
> a lot things can be arranged to make development easier/more flexible/etc=
.
>
> After discussing this with Matthew, I'm asking you to:
>
> *Write in short, how do you use Zend Framework*
> *
> *
> What interests us is how you work with modules (blog, products, news,
> users), how you divide your applications in to parts (admin, public,
> something else) and how other parts of code (acl, configuration, resource=
s)
> comes into play here.
>
> The reason why I'm asking this, is because I'm using Zend Framework for
> quote big applications and for me it's important to have ability to creat=
e
> application with self-contained modules and sub-applications. For example=
 I
> have e-commerce products having admin, public and supplier sub-applicatio=
ns,
> but everything is still nicely divided into modules (products, warehouse,
> orders, customers etc.) and App_Application and FrontController plugins d=
oes
> some work to make one application code to be divided in these parts.
>
> However, I know that some people use applications completely based on acl=
 -
> there is one site and only depending on what your permissions are, you se=
e
> data, can edit or delete if you want to. Here again somewhat different
> structure comes into play. Also quite popular thing to do is to have
> admin/default modules. Even though I completely don't understand this
> approach, some people like it and use everyday, hence it should also be
> possible to use.
>
> So please write what you think about such things, I will try to read them
> all, generalize into a comparison table and make it into a proposal of wh=
at
> functions from core are needed to support it (without any hacking, which =
I
> done quite a lot)
>
> --
> Juozas Kaziuk=C4=97nas ([email-masked])
> A=C5=A1 internete - JuoKaz (http://www.juokaz.com)
>

--00504502b0a2a780ca0479f4a0d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello=C2=A0<span class=3D"Apple-style-span" style=3D"font-family: arial, sa=
ns-serif; font-size: 13px; border-collapse: collapse; color: rgb(34, 34, 34=
); ">Juozas,</span><div><font class=3D"Apple-style-span" color=3D"#222222" =
face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=3D"border=
-collapse: collapse;"><br>
</span></font></div><div><span class=3D"Apple-style-span" style=3D"font-fam=
ily: arial, sans-serif; border-collapse: collapse; color: rgb(34, 34, 34); =
">I am using zend framework version 1.7.</span></div><div><span class=3D"Ap=
ple-style-span" style=3D"font-family: arial, sans-serif; border-collapse: c=
ollapse; color: rgb(34, 34, 34); "><br>
</span></div><div><span class=3D"Apple-style-span" style=3D"font-family: ar=
ial, sans-serif; border-collapse: collapse; color: rgb(34, 34, 34); ">The a=
pplication in which I am using is pretty large and has few modules like pos=
 sale, website, backoffice (having, vendors, sales rep, po, invoice, accoun=
ts, receiving products, create inventory, many small modules to do adjustme=
nts in inventory, store transfers, website, admin). Each module listed has =
a lot of complex logic and of course so many features.</span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; border-collapse: collapse; color: rgb(34, 34, 34); "><br></span></div><=
div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-seri=
f; border-collapse: collapse; color: rgb(34, 34, 34); ">We have structured =
the project like below:</span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; border-collapse: collapse; color: rgb(34, 34, 34); "><br></span></div><=
div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans-=
serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse;=
">-POS (similar structure followed for each module, Vendor Login, Backoffic=
e and POS)</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;">--application</span></font></div><div><font class=3D"Apple-style-span" c=
olor=3D"#222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span=
" style=3D"border-collapse: collapse;">---controller</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;">---views</span></font></div><div><font class=3D"Apple-style-span" color=
=3D"#222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" st=
yle=3D"border-collapse: collapse;">--bootstrap.php</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;">--public</span></font></div><div><font class=3D"Apple-style-span" color=
=3D"#222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" st=
yle=3D"border-collapse: collapse;">--index.php</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;">---js</span></font></div><div><font class=3D"Apple-style-span" color=3D"=
#222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=
=3D"border-collapse: collapse;">---css</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br></span></font></div><div><font class=3D"Apple-style-span" color=3D"#=
222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=
=3D"border-collapse: collapse;"><br>
</span></font></div><div><font class=3D"Apple-style-span" color=3D"#222222"=
 face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=3D"borde=
r-collapse: collapse;">Imp: We have a folder Called &quot;Core&quot; this h=
as all the table classes + business logic classes, so each module access th=
is core in order to perform what they have to.</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br></span></font></div><div><font class=3D"Apple-style-span" color=3D"#=
222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=
=3D"border-collapse: collapse;">This way, I can control entire application =
by making changes in core folder only.</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br></span></font></div><div><font class=3D"Apple-style-span" color=3D"#=
222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=
=3D"border-collapse: collapse;">I am not sure if this 100% best way to do i=
t, but I am loving it so far, and have more than 80 programmers working on =
it since a 1 year now, and everything is going smooth.</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br></span></font></div><div><font class=3D"Apple-style-span" color=3D"#=
222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=
=3D"border-collapse: collapse;">I would love to share more about this with =
everyone using Zend Framework if they are interested.</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br></span></font></div><div><font class=3D"Apple-style-span" color=3D"#=
222222" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=
=3D"border-collapse: collapse;">I hope above helps you!</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#222222" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br></span></font></div><div>Thanks!<br><br>Sawan<br>phone: +1 (251) 2SA=
WANR<br>
&quot;Nothing is particularly hard if you divide it into small jobs.&quot; =
- Henry Ford=20
<br><br><div class=3D"gmail_quote">On Sat, Dec 5, 2009 at 9:28 AM, Juozas <=
span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello everyone,<div><br></div><div>as you know, Zend Framework 2.0 is havin=
g a major rewrite in some parts and a lot things can be arranged to make de=
velopment easier/more flexible/etc.</div><div><br></div><div>After discussi=
ng this with Matthew, I&#39;m asking you to:</div>

<div><br></div><div><b>Write in short, how do you use Zend Framework</b></d=
iv><div><b><br></b></div><div>What=C2=A0interests us is how you work with m=
odules (blog, products, news, users), how you divide your applications in t=
o parts (admin, public, something else)=C2=A0and how other parts of code (a=
cl, configuration, resources) comes into play here.=C2=A0</div>

<div><br></div><div>The reason why I&#39;m asking this, is because I&#39;m =
using Zend Framework for quote big applications and for me it&#39;s importa=
nt to have ability to create application with self-contained modules and su=
b-applications. For example I have e-commerce products having admin, public=
 and supplier sub-applications, but everything is still nicely divided into=
 modules (products, warehouse, orders, customers etc.) and App_Application =
and FrontController plugins does some work to make one application code to =
be divided in these parts.=C2=A0</div>

<div><br></div><div>However, I know that some people use applications compl=
etely based on acl - there is one site and only depending on what your perm=
issions are, you see data, can edit or delete if you want to. Here again so=
mewhat different structure comes into play.=C2=A0Also quite popular thing t=
o do is to have admin/default modules. Even though I completely don&#39;t u=
nderstand this approach, some people like it and use everyday, hence it sho=
uld also be possible to use.=C2=A0</div>

<div><br></div><div>So please write what you think about such things, I wil=
l try to read them all, generalize into a comparison table and make it into=
 a proposal of what functions from core are needed to support it (without a=
ny hacking, which I done quite a lot)</div>

<div><br clear=3D"all">--<br>Juozas Kaziuk=C4=97nas (<a href=3D"mailto:juoz=
[email-masked]" target=3D"_blank">[email-masked]</a>)<br>A=C5=A1 internet=
e - JuoKaz (<a href=3D"http://www.juokaz.com" target=3D"_blank">http://www.=
juokaz.com</a>)<br>

</div>
</blockquote></div><br></div>

--00504502b0a2a780ca0479f4a0d6--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 15:55:56 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method
	signatures

-- Ralph Schindler <[email-masked]> wrote
(on Tuesday, 16 March 2010, 02:26 PM -0500):
> Response inline..
> 
> > > <?php
> > > // this class has a use statement
> > > 
> > > namespace Foo;
> > > use Qux\Garply as garp;
> > > 
> > > class Bar
> > > {
> > > // this method accepts an instance of Qux\Garply\Bar
> > > public static function baz(garp\Bar $bar) {}
> > > }
> >
> > And this one too, though you could "use" whole Qux\Garply\Bar as
> > QGBar as well :)
> 
> This is actually pretty close to my point.
> 
> It's clear to people consuming Zend Framework classes that Bar
> inside the method signature means Foo\Bar.  The question comes in
> when people are consuming a class that has outside dependencies
> (like the example above).

I see no issue with the example above -- the class in the typehint is
namespaced, and there's a clear alias defined at the top of the file...

> How is a developer suppose to know what the QGBar alias is short
> for? 

Umm... because there's an alias defined.

> Moreover, if we are to use alias in method signatures, what
> kind of naming convention should be in play?

I think this is the only real relevant point. The aliases should be
clear -- in most cases, if aliasing a namespace, use the namespace (as
it is likely the component name); if importing a single class, use the
classname, or give the classname context based on the component
namespace it lives in.

> Additionally, do we restrict it to importing full namespaces? Or
> would we allow importing of single classes?  

You should import what you need, plain and simple. 

Some potential guidelines:

 * If the class is used only once, it may make as much or more sense to
   simply use the fully qualified name -- with the caveat that if it's
   stupidly long, create a meaningful, short alias.

 * When importing a class, you may need to suffix with the component
   and/or subcomponent namespace:

     use \Zend\Filter\Int as IntFilter;
     use \Zend\Db\Adapter\Mysql as MysqlDbAdapter;

 * When importing a namespace, simply use the final segment of the
   namespace, unless it may need context from the component:

     use \Zend\Filter;
     use \Zend\Db\Adapter as DbAdapter;

     $filter  = new Filter\Int();
     $adapter = new DbAdapter\Mysql();

   In the above example, I chose "DbAdapter" as the alias so that
   there's not confusion with other adapters or plugins being used.

> Do we allow importing an aliased class into a File and use that inside
> a method signature?

As long as a meaningful alias has been used, and it clearly doesn't
conflict with classes in the namespace, I don't see why not. That said,
I'd recommend aliasing namespaces over classes in most cases.

> Imagine this:
> 
> <?php
> namespace Zend\Some\NS;
> use \ArrayObject as Container;
> 
> class Foo
> {
>    public function doSomething(Container $c);

I'd call that an ambiguous and unnecessary alias, to be honest. It's
renaming for the sake of renaming, which will cause confusion.

> }
> ?>
> 
> This is totally possible, and you could argue that its a superb use
> of namespaces.  Some might argue that it borders on runkit
> functionality (the ability to alias names bit). How is a developer
> suppose to know simply by looking at the method signature that he
> just needs to supply an ArrayObject?

See my note above -- I think that sort of renaming shouldn't happen, and
should be discouraged. It causes ambiguity and confusion.

> Do we simply rely on tools to tell us what Container really means?
> 
> I totally agree with using "namespace resolved names" for method
> signatures, but I am skeptical on whether using "use resolved names"
> is going to produce easy to use APIs.
> 
> 
> 
> > > One thing to notice is that if method signatures contain a fully
> > > qualified name (those starting with a \) for type hints, you don't need
> > > to know anything about what namespaces or aliases are in play;
> > > everything you need to know is right in front of you. However, on the
> > 
> > I have faith that Framework developers actually can remember
> > inside which class and namespace they are :)
> 
> 
> By "Framework developers" do you mean people writing ZF code? or
> people consuming ZF code?  I actually don't care about the burden
> put on people writing code for ZF, b/c you only need to write it
> once.  It's the burden put on the consumers of the ZF library of
> code that I feel is more important.

Then it becomes a documentation issue for the ZF and PHP communities,
educating users as to how namespaces work. :)

> > > Should library/framework specific code be more expressive using fully
> > > qualified names in method signatures and consequently in docblocks? Or
> > > is using unqualified names just as easy to understand and/or
> > > more readable?
> > 
> > Docblocks present interesting challenge, if they are used for
> > typing purposes. I guess there some solution might be needed, but
> > maybe smart tools can solve it...
> 
> I am guessing that docblock class names should probably be using the
> same namespace and use rule resolution that classes use.

That would be my preference. 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 22 Jan 2010 04:40:12 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Doctrine 1 Integration Ideas

--0-937401727-1264164012=:61427
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Replies inline.=0A=0A>Hello everyone,=0A>=0A>there hasn't been much news on=
 this front lately, me was kinda busy with=0A>work and such.=0A>=0A>Yesterd=
ay I reviewed all the stuff i found on ZF and Doctrine 1=0A>integration and=
 came to=0A>the conclusion that while single modular generation is supporte=
d by=0A>Doctrine 1.2's new=0A>PEAR style model generation you still have to=
 hack lots around.=0A>=0A>Therefore my idea is, two-fold:=0A>=0A>I. Single =
ZF Module (Default)=0A>=0A>Support Single-Default-Module Scenario more easi=
ly by providing a=0A>config-option=0A>that automatically sets all the model=
-generation options correctly. This=0A>would=0A>be something along the line=
s of:=0A>=0A>$import->setOptions(array(=0A>    'pearStyle' =3D> true,=0A>  =
  'baseClassesDirectory' =3D> null,=0A>    'baseClassPrefix' =3D> 'Base_',=
=0A>    'classPrefix' =3D> 'Model_',=0A>    'classPrefixFiles' =3D> true=0A=
>));=0A>=0A>This allows for models of the Style "Model_User", "Model_Foo",=
=0A>"Model_Bar".=0A>=0A>HOWEVER: Can someone explain to me how that relates=
 to the class name that=0A>you can=0A>specifiy in the YAML config file?=0A=
=0AAs in a schema config? Schema would just use Model_User/Model_Foo in thi=
s case. Not sure if that's what you meant though. The main settings above o=
f interest are classPrefix and classPrefixFiles. classPrefix would simply p=
repend the Module name for module autoloading, though I think classPrefixFi=
les would be false to omit the Module name from the actual files, so we jus=
t have, for example, /application/models/User.php and /application/models/F=
oo.php.=0A=0AMain thing I'd be interested in is of this option would suppor=
t the more complex scenario of having a named default module, e.g. /applica=
tion/modules/default (giving Default_Model_User at /application/modules/def=
ault/models/User.php). I use a named default all the time, though of course=
 the ZF CLI tool isn't exactly cooperative with that ;).=0A=0A>No upgrade m=
echanism from single module to multiple module will be=0A>provided.=0A>=0A>=
II. Doctrine + Multiple ZF MOdules:=0A>=0A>Circumvent Doctrine_Core::loadMo=
dels() completely by introducing a new=0A>auto-loading=0A>mechanism and sli=
ghtly modifying the Doctrine_Import_Schema class.=0A=0AI'd circumvent it an=
yway, isn't there anyway to leverage off our already built in resource auto=
loading? That's already set up to handle all module contingencies for model=
s, forms, etc. assigned to directories with those names.=0A=0A>This style w=
ould do no magic, it would require you to use class names of=0A>the kind:=
=0A>=0A><ModuleName>_Model_<ModelName>=0A>=0A>Doctrine would auto-load all =
the classes of the kind in all=0A><moduleName>/models through=0A>a Module R=
esource Loader.=0A=0ASpoke too soon - yeah, that's the way it probably shou=
ld work by default. It's a current convention and if someone want's to star=
t changing it around, they can do their thing with the local include_path b=
y themselves.=0A=0A>For the CLI tasks in Zend Tool there would be a dection=
 of all models by=0A>the mechanism.=0A>=0A>1. Get Front Controller module/c=
ontroller directory=0A>2. Iteratore over them and find all models directori=
es.=0A>3. Recursively scan all models directories for=0A><ModuleName>_Model=
_<ModelName> classes.=0A>=0A>For the YAML to Model Generation task the mech=
anism would be.=0A>=0A>1. Detect Module name by checking the first result o=
f explode("_",=0A>$className)=0A>2. If the first is "Model", grab default m=
odule from Front-Controller,=0A>otherwise Check that second result is "Mode=
l"=0A>3. Write record, base-record and optionally table classes into the mo=
dules=0A>model directory.=0A=0ABear in mind that any module name can be the=
 default. Not sure if that makes any different if picked up as a distinct m=
odules anyway.=0A=0A>This requires a Doctrine + Zend Modular Application to=
 follow strict class=0A>naming standards,=0A>but makes the implementation v=
ery robust in terms of both frameworks and=0A>avoids any=0A>additional magi=
c (Looking at the Doctrine 1 code, there is already too=0A>much magic!)=0A>=
=0A>Any ideas?=0A>=0A>My plan is to get this into 1.11, I'll colaborate wit=
h Matthew Lurz also=0A>to get the=0A>Doctrine application resource ready fo=
r this then.=0A>=0A>Also my plan is that this integration will require Doct=
rine 1.2=0A=0ADoctrine 1.2 is fine. Little point supporting an older versio=
n whose use in new applications should be declining.=0A=0Agreetings,=0ABenj=
amin=0A
--0-937401727-1264164012=:61427
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">Replies inline.<br><br>&gt;Hello everyone,<br>&gt;<br>&gt;ther=
e hasn't been much news on this front lately, me was kinda busy with<br>&gt=
;work and such.<br>&gt;<br>&gt;Yesterday I reviewed all the stuff i found o=
n ZF and Doctrine 1<br>&gt;integration and came to<br>&gt;the conclusion th=
at while single modular generation is supported by<br>&gt;Doctrine 1.2's ne=
w<br>&gt;PEAR style model generation you still have to hack lots around.<br=
>&gt;<br>&gt;Therefore my idea is, two-fold:<br>&gt;<br>&gt;I. Single ZF Mo=
dule (Default)<br>&gt;<br>&gt;Support Single-Default-Module Scenario more e=
asily by providing a<br>&gt;config-option<br>&gt;that automatically sets al=
l the model-generation options correctly. This<br>&gt;would<br>&gt;be somet=
hing along the lines
 of:<br>&gt;<br>&gt;$import-&gt;setOptions(array(<br>&gt;&nbsp;&nbsp;&nbsp;=
 'pearStyle' =3D&gt; true,<br>&gt;&nbsp;&nbsp;&nbsp; 'baseClassesDirectory'=
 =3D&gt; null,<br>&gt;&nbsp;&nbsp;&nbsp; 'baseClassPrefix' =3D&gt; 'Base_',=
<br>&gt;&nbsp;&nbsp;&nbsp; 'classPrefix' =3D&gt; 'Model_',<br>&gt;&nbsp;&nb=
sp;&nbsp; 'classPrefixFiles' =3D&gt; true<br>&gt;));<br>&gt;<br>&gt;This al=
lows for models of the Style "Model_User", "Model_Foo",<br>&gt;"Model_Bar".=
<br>&gt;<br>&gt;HOWEVER: Can someone explain to me how that relates to the =
class name that<br>&gt;you can<br>&gt;specifiy in the YAML config file?<br>=
<br>As in a schema config? Schema would just use Model_User/Model_Foo in th=
is case. Not sure if that's what you meant though. The main settings above =
of interest are classPrefix and classPrefixFiles. classPrefix would simply =
prepend the Module name for module autoloading, though I think classPrefixF=
iles would be false to omit the Module name from the actual files, so we ju=
st
 have, for example, /application/models/User.php and /application/models/Fo=
o.php.<br><br>Main thing I'd be interested in is of this option would suppo=
rt the more complex scenario of having a named default module, e.g. /applic=
ation/modules/default (giving Default_Model_User at /application/modules/de=
fault/models/User.php). I use a named default all the time, though of cours=
e the ZF CLI tool isn't exactly cooperative with that ;).<br><br>&gt;No upg=
rade mechanism from single module to multiple module will be<br>&gt;provide=
d.<br>&gt;<br>&gt;II. Doctrine + Multiple ZF MOdules:<br>&gt;<br>&gt;Circum=
vent Doctrine_Core::loadModels() completely by introducing a new<br>&gt;aut=
o-loading<br>&gt;mechanism and slightly modifying the Doctrine_Import_Schem=
a class.<br><br>I'd circumvent it anyway, isn't there anyway to leverage of=
f our already built in resource autoloading? That's already set up to handl=
e all module contingencies for models, forms, etc. assigned to
 directories with those names.<br><br>&gt;This style would do no magic, it =
would require you to use class names of<br>&gt;the kind:<br>&gt;<br>&gt;&lt=
;ModuleName&gt;_Model_&lt;ModelName&gt;<br>&gt;<br>&gt;Doctrine would auto-=
load all the classes of the kind in all<br>&gt;&lt;moduleName&gt;/models th=
rough<br>&gt;a Module Resource Loader.<br><br>Spoke too soon - yeah, that's=
 the way it probably should work by default. It's a current convention and =
if someone want's to start changing it around, they can do their thing with=
 the local include_path by themselves.<br><br>&gt;For the CLI tasks in Zend=
 Tool there would be a dection of all models by<br>&gt;the mechanism.<br>&g=
t;<br>&gt;1. Get Front Controller module/controller directory<br>&gt;2. Ite=
ratore over them and find all models directories.<br>&gt;3. Recursively sca=
n all models directories for<br>&gt;&lt;ModuleName&gt;_Model_&lt;ModelName&=
gt; classes.<br>&gt;<br>&gt;For the YAML to Model Generation task
 the mechanism would be.<br>&gt;<br>&gt;1. Detect Module name by checking t=
he first result of explode("_",<br>&gt;$className)<br>&gt;2. If the first i=
s "Model", grab default module from Front-Controller,<br>&gt;otherwise Chec=
k that second result is "Model"<br>&gt;3. Write record, base-record and opt=
ionally table classes into the modules<br>&gt;model directory.<br><br>Bear =
in mind that any module name can be the default. Not sure if that makes any=
 different if picked up as a distinct modules anyway.<br><br>&gt;This requi=
res a Doctrine + Zend Modular Application to follow strict class<br>&gt;nam=
ing standards,<br>&gt;but makes the implementation very robust in terms of =
both frameworks and<br>&gt;avoids any<br>&gt;additional magic (Looking at t=
he Doctrine 1 code, there is already too<br>&gt;much magic!)<br>&gt;<br>&gt=
;Any ideas?<br>&gt;<br>&gt;My plan is to get this into 1.11, I'll colaborat=
e with Matthew Lurz also<br>&gt;to get the<br>&gt;Doctrine
 application resource ready for this then.<br>&gt;<br>&gt;Also my plan is t=
hat this integration will require Doctrine 1.2<br><br>Doctrine 1.2 is fine.=
 Little point supporting an older version whose use in new applications sho=
uld be declining.<br><div style=3D"font-family: times new roman,new york,ti=
mes,serif; font-size: 12pt;"><div style=3D"font-family: tahoma,new york,tim=
es,serif; font-size: 8pt;">greetings,<br>Benjamin<br></div></div>=0A<!-- cg=
2.c902.mail.ac4.yahoo.com compressed/chunked Sun Jan 17 05:08:35 PST 2010 -=
->=0A</div></body></html>
--0-937401727-1264164012=:61427--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 8 Dec 2009 21:56:05 +0100
From: Dolf Schimmel <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Incubator Issue Tracker: Adding component for 
	each incubator component

Hi,

It makes no sense for bystanders to be able to file issues for
components that are still in incubator. Components in incubator are
buggy and incomplete by definition, and it would be nothing but
bullying the developer(s) when one started to file issues that stuff
doesn't work yet. I'm currently busy on Zend_Image, and I would hate
it if people started telling me that the chaining of actions doesn't
work yet e.g. (since I'm planning on doing that tonight).

However, Jira functions perfectly as a (bloated) todo-list, and when
collaborating it is easy to see how far the other developer(s) are. As
said, David and I are busy on developing Zend_Image, he basically does
all the ImageMagick stuff, I do most of the GD stuff. We added issues
for both adapters, and assigned them respectively. Whenever one of us
is done with an action, we close the relevant  issue (which by
definition is of type 'task') so the other developer is able to see
how far we are. Also, if I notice a bug in the ImageMagick adapter,
and I don't feel like solving it myself, I can just add an issue,
assign it to David, and blame him that the bug is still there if he
doesn't fix it in an hour or so (:wink:).

All in all, the issue tracker _can_ be used effectively for components
in incubator, but should only be used on request of the
Componentlead(s) (imho).

Dolf Schimmel
Freeaqingme

p.s. For those wondering, if Matthew is not going to be too hard on
us, Zend_Image will be in ZF1.10

On Tue, Dec 8, 2009 at 3:32 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Marcus St=C3=B6hr <[email-masked]> wrote
> (on Tuesday, 08 December 2009, 01:15 PM +0100):
>> at the moment, there are several components sitting in the incubator
>> for development. Wouldn't it be convinient to have a category for each
>> component in the issue tracker, e.g. for Zend_Oauth?
>
> We've debated this before. My main reservation is that once the
> component moves to trunk, there's no longer a way to see what issues
> were resolved within incubator when looking at a component's issue list.
>
> However, a few folks _do_ have incubator project components and are
> using it to track tasks -- can some of you perhaps comment?
>
> --
> Matthew Weier O'Phinney
> Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [email-masked]
> Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://framework.zend.=
com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Benjamin Eberlei <[email-masked]>
To: [email-masked]
Date: Mon, 13 Apr 2009 14:55:02 +0200
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

Super, i like that with the interface name + abstract suffix, although in my 
opinion an abstract prefix is much more readable since its in the english 
languages natural flow.

so, since you mention it. how will namespace resolving be done with 
autoloading? i.e. what will the directory structure / namespace /class 
structure look like?

On Monday 13 April 2009 14:49:06 Matthew Weier O'Phinney wrote:
> I'm going to break a couple of rules here: I'm replying to my own email,
> as well as top-posting. Bear with me...
>
> Robin S. raised an interesting point that Matt R. picked up and agreed
> with:
>
>     I also notice that namespaces are written in Uppercase\Notation --
>     Zend\Controller\Request. Will this be the standard? Another
>     alternative is zend\controller\Request, which clearly distinguishes
>     what's the namespace and what's the class/interface.
>
> Additionally, it seems the primary push-back is with abstract class
> naming, particularly when there are also interfaces defined in the same
> namespace.
>
> After reading these responses, I reached out to some friends in the PEAR
> community, some of whom I've spoken with before about these issues. "Why
> PEAR?" some may ask. ZF standards are based on PEAR standards. One goal
> since the beginning of the ZF project has been to promote
> interoperability with established standards. PEAR CS are the "gold
> standard" in the PHP community, and whether you like or agree with them
> or not, they are used widely.
>
> The PEAR Group has been debating new standards to adopt for PEAR2 for
> some time now. PEAR2 is targeting a minimum required version of PHP 5.3,
> so they are addressing the very same issues we're discussing. They have
> also basically reached consensus, though they have not formally adopted
> the new standards yet. When it comes to namespaces and class naming, it
> is the ZF team's opinion that we need to be as close to PEAR standards
> as possible.
>
> The relevant documents are here:
>
>     http://wiki.php.net/pear/rfc/pear2_class_naming
>     http://wiki.php.net/pear/rfc/pear2_naming_standards
>
> In a nutshell, here's what they define:
>
>  * Namespaces are lowercase: zend\codegenerator\php
>  * Class names are MixedCase: zend\codegenerator\php\File
>  * Namespaces may contain underscores, but they do not translate to the
>    directory separator
>  * Class names may contain underscores, and they *do* translate to the
>    directory separator
>  * Interfaces should be named descriptively, and not contain the word
>    "Interface" or the sigil "I".
>  * It is preferred that Abstract classes are also named descriptively,
>    but *may* contain the *suffix* Abstract.
>
> There are some good arguments for each point in the linked RFCs.
>
> I think that adopting these standards addresses most concerns the ZF
> team has, as well as many if not most concerns posted in this thread.
>
> -- Matthew Weier O'Phinney <[email-masked]> wrote
>
> (on Friday, 10 April 2009, 02:24 PM -0400):
> > Greetings, all --
> >
> > Below is a proposal I am making to modify the Zend Framework Coding
> > Standards conventions for the naming of Interfaces and Abstract classes.
> >
> > This decision is basically already made, but I'd appreciate any feedback
> > that you may have on the matter.
> >
> > Thanks!
> >
> > The problem
> > ===========
> > PHP 5.3 introduces namespaces to the PHP language. While this won't have
> > an impact much on userland code, it will have an impact on library and
> > framework code, as it provides a useful paradigm for organizing
> > components as well as simplifying syntax. Instead of having to say things
> > like:
> >
> >     $analyzer = new
> > Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> >
> > we can instead do something like this:
> >
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >     $analyzer = new Common_TextNum();
> >
> > or even:
> >
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> >     class Common_TextNum extends Common
> >     {
> >     }
> >
> > The problem that arises for Zend Framework has to do with how we name
> > abstract classes and interfaces. Currently, the final segment of such
> > classes are expected to end with _Abstract and _Interface, respectively.
> > This will not work when we migrate to utilize namespaces, for two
> > reasons.
> >
> > First, and most obviously, 'abstract' and 'interface' are reserved PHP
> > keywords. As such, in situations such as the following:
> >
> >     namespace Zend\Controller\Request;
> >
> >     class Abstract
> >     {
> >     }
> >
> >     // or:
> >
> >     namespace Zend\Controller\Dispatcher;
> >
> >     interface Interface
> >     {
> >     }
> >
> > we'll run into issues.
> >
> > Second, and less obvious, is that perhaps the easiest solution breaks one
> > of the key principles of namespaces (which are designed to help
> > encapsulate components). This one's harder to explain, so let's look at
> > examples. Consider a component such as Zend_Controller_Request. The
> > simplest solution would be to name the abstract class or interface
> > Zend\Controller\Request, and then have the various concrete
> > implementations under that namespace:
> >
> >     namespace Zend\Controller;
> >
> >     interface Request
> >     {
> >     }
> >
> >     // and concrete ones:
> >
> >     namespace Zend\Controller\Request;
> >
> >     class Http
> >     {
> >     }
> >
> > What's the problem here? The interface is not in the same namespace as
> > the concrete implementations.
> >
> > Potential solutions and recommendation
> > ======================================
> > So, how should Zend Framework "solve" these issues? A number of proposals
> > and recommendations have been floated around, both within ZF circles and
> > in the greater PHP community.
> >
> > Considerations include:
> >
> >  * Avoiding the use of PHP reserved keywords (already noted).
> >  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
> > name describe its type -- which, to a degree, the current naming
> > conventions already violate). (See
> > http://en.wikipedia.org/wiki/Hungarian_Notation, the sections
> > "Disadvantages of Systems Hungarian" and "Notable Opinions" for some of
> > the arguments against using Hungarian Notation.)
> >
> > Approaches that have been considered include:
> >
> >  * Using 'I' to prefix interfaces. This derives from standards in other
> >    programming languages (.Net and python, in particular). This is just
> > another form of Hungarian Notation, however.
> >
> >  * Using "Interface" or "Abstract" as a class name suffix:
> > RequestInterface, RequestAbstract. Again, however this is Hungarian
> > Notation.
> >
> >  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
> > Base. This is just substituting the word Base for Abstract, however, and
> > is really not much different than the above.
> >
> >  * Use generic, descriptive names indicative of functionality or
> > behavior. As examples from the SPL, "Countable", "Iterator",
> > "ArrayObject".
> >
> > My recommendation is to use the latter, as it solves all considerations.
> > It will take more thought when naming, but will ensure that components
> > can live in a self-contained namespace, do not use reserved keywords, and
> > avoid Hungarian Notation.
> >
> > Plan for implementation
> > =======================
> > I recommend that the Coding Standards documentation be updated to reflect
> > this approach.
> >
> > All new components going into 1.8 and onwards should adopt these
> > standards. In releases 1.9 and forward, we will begin migrating existing
> > interfaces/abstract classe. First, new classes/interfaces will be created
> > that follow these conventions and which extend the originals; later, any
> > type-hinting based on the original class/interface names will be updated
> > to point to the new names; and finally, in 2.0, we will remove the old
> > interfaces/abstract classes entirely.
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | [email-masked]
> > Zend Framework          | http://framework.zend.com/

-- 
Benjamin Eberlei
http://www.beberlei.de

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Oct 2009 20:09:08 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 1.9.4 Sanity Check tarballs now available

Sanity check tarballs of ZF 1.9.4 are now available here:

    Full:
        http://framework.zend.com/releases/preview/ZendFramework-1.9.4/ZendFramework-1.9.4.zip
        http://framework.zend.com/releases/preview/ZendFramework-1.9.4/ZendFramework-1.9.4.tar.gz

    Minimal:
        http://framework.zend.com/releases/preview/ZendFramework-1.9.4/ZendFramework-1.9.4-minimal.zip
        http://framework.zend.com/releases/preview/ZendFramework-1.9.4/ZendFramework-1.9.4-minimal.tar.gz

We also have tarballs for all documentation and API docs, GData, AMF,
and InfoCard available should you want to test those; ping me for URLs
if you do.

We plan to release sometime mid- to late afternoon tomorrow, Tuesday, 
13 October 2009.

Please test on existing applications if you can, and let myself or
somebody else on the ZF team know ASAP if you notice any regressions.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 26 Oct 2009 12:26:01 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: =?iso-8859-1?Q?P=E1draic?= Brady <[email-masked]>,
	[email-masked]
Mail-Followup-To: =?iso-8859-1?Q?P=E1draic?= Brady <[email-masked]>, 
	[email-masked]
Subject: Re: [zf-contributors] JIRA Incubator Components Update

-- P=C3=A1draic Brady <[email-masked]> wrote
(on Tuesday, 20 October 2009, 06:59 AM -0700):
> The list I have is:
>=20
> Zend_Feed_Pubsubhubbub
> Zend_Cache_Manager

These have been added, as have items from the below list which are
currently in active development.

> Can I stop now? No? ;)
>=20
> Zend_Cache_Backend_Blackhole
> Zend_Amf
> Zend_Auth_Adapter_Cas
> Zend_Config_Writer
> Zend_Controller_Action_Helper_MultiPageForm
> Zend_Db_Mapper
> Zend_Entity
> Zend_Environment
> Zend_Form_Decorator_File
> Zend_Http_Client_Adapter_Curl
> Zend_Image
> Zend_Json_Server
> Zend_Markup
> Zend_Mime_Message
> Zend_Service_[LiveDocx|RememberTheMilk|TinyUrlCom|Gravatar|Tumblr|JdemC=
z]
> Zend_ShortUrl
> Zend_Validate_[CreditCard|EmailAddress|InArray|Isbn]
> Zend_View_Helper_Currency
>=20
> There are also a few files in the Zend directory but no matching name
> directory, e.g. Zend_Calendar.
>=20
> Not sure how fine-grained you want to get though, or even if all of the=
se
> qualify. I'm not familiar with all of their activity/age. Also a few
> directories in the repository which are basically empty.
>=20
> Hope everyone's having a grand time at Zendcon while the rest of us ana=
lyse the
> Incubator :P.
> =20
> P draic Brady
>=20
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>=20
>=20
> =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=
> From: Matthew Weier O'Phinney <[email-masked]>
> To: [email-masked]
> Sent: Mon, October 19, 2009 5:01:02 AM
> Subject: Re: [zf-contributors] JIRA Incubator Components Update
>=20
> -- P draic Brady <[email-masked]> wrote
> (on Saturday, 17 October 2009, 06:15 AM -0700):
> > Just requesting that we add in the missing Incubator components to JI=
RA if
> > possible. At present we can't create issues for these.
>=20
> Can you refresh my memory as to which incubator components need to be
> added? I'll try and do so Tuesday, once I have a list.
>=20
> > Assuming everyone has recovered from fixing 100 issues during the bug=
 hunt!
> :P
>=20
> Indeed! Awesome job, everyone! The final count for the official hunt wa=
s
> 95, and you can view the list here:
>=20
>     http://framework.zend.com/issues/secure/IssueNavigator.jspa?mode=3D=
hide&
> requestId=3D11156
>=20
> I'll be announcing the winner on Tuesday -- but many thanks now to
> everyone who participated!
>=20
> --
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 10 Aug 2009 13:37:41 +0200
From: till <[email-masked]>
To: Daniel Lo <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] API/Interface changes?

On Mon, Aug 10, 2009 at 3:39 AM, Daniel Lo<[email-masked]> wrote:
> Hello,
>
> Someone recently brought to my attention that fsockopen's dependency on
> get_ini('default_socket_timeout') was really inconvenient in a web applic=
ation
> because it is 60 seconds by default. ( http://www.php.net/manual/en/ini.l=
ist.php
> )
>
> I thought about it, and I agreed that this was probably unreasonable and =
should
> allowed to be set in some manner via a configuration setting.
>
> However, implementing this change has become fairly difficult because of =
the
> "depth" of the final class that needs to be modified.
>
> Zend_Queue is a class that returns a Zend_Queue + an adapter attached
> on. =A0The adapter in this question is Activemq. =A0However, Activemq use=
s Stomp (a
> simple protocol for messaging), but the Stomp uses another class for
> actually doing the connection IO.
>
> So in affect, a configuration change passed to
>
> Zend_Queue($options['timeout']) -> Activemq -> Stomp wrapper -> Stomp IO.
>
> In eagle hindsight, I should have made the "connection" options an associ=
ative
> array for several of the constructor calls instead of using open($scheme,=
 $host,
> $port...). =A0Does anyone have any suggestions for fixing this that don't=
 involve an
> API change, which I understand is verbotten between minor revisions.

func_get_args() -- or do something like that. It's probably slow though.

You could also attach more options as optional paramters -- not a BC
break either.

Or you could do:

function foo($var)
{
   if ($var instanceof Zend_Config) {

   } elseif (is_int($var)) {

   } elseif (something else) {

   } else {

   }
}

> The best that comes to my mind is to use a class variable
>
> class Zend_Queue_Stomp_Client_Connection {
> =A0 =A0static protected $timeout =3D 10;
> =A0 =A0static public function getTimeout() {
> =A0 =A0 =A0 =A0return $this->timeout;
> =A0 =A0}
>
> =A0 =A0static public function setTimeout() { ... }
> }

IMHO, that's not a bad idea as well. I mean, generally it sort of
depends how useful 10 vs 60 is. Configuration is not a bad idea, but
it might also help to add a page to the manual so people just set the
ini setting "correctly" (or more appropriately).

Till

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Date: Tue, 14 Jul 2009 15:58:59 +0100
Subject: [zf-contributors] Zend_Db_Adapter_Sqlsrv ready for review

Hi all,

Juozas and myself worked on an adapter for the MS SQL Server Driver  
for PHP during the euro-win-php competition. As this is a useful  
component for anyone working on Windows with SQL Server, we've created  
a proposal which is now ready for review:

http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Adapter_Sqlsrv+-+Juozas+Kaziukenas+and+Rob+Allen

There's also working source code at https://zfmssql.svn.codeplex.com/svn/

We'd appreciate any and all comments on it :)

Regards,

Rob...

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Vincent de Lau" <[email-masked]>
To: <[email-masked]>
Date: Sun, 22 Nov 2009 17:55:00 +0100
Subject: RE: [zf-contributors] Zend Framework 2.0 Roadmap

Shoot, just remembered one of my observations. Always happens right after
hitting submit...

Something I am wondering about, is how to integrate Zend_Server into the
MVC. I could imagine that in the front controller, requests are not always
dispatched to action controllers but could also be 'dispatched' to a
Zend_Server. Maybe selecting a different dispatch process to use based on
the (routed) request? This would also allow different dispatch/controller
methods to be introduced.

Related to this are request based levels of configuration. Acknowledging the
overhead we introduced into our MVC stack, we had to create a separate entry
point for AJAX calls. Using rewrite rules, we are now forwarding request
that contain the string 'ajax' to a seperate 'index.php' (called ajax.php)
that will only do a minimal bootstrap. I suppose Zend_Application might help
here, together with improving our plug-in.

One of the main issues is the loading of the routes, which is one of the
things we removed from the AJAX bootstrap so that we will always use the
default route. I've seen some mentioning of improving the routing process
might solve this issue. The other things that we have to do for AJAX calls
are disabling layout and debug/profiling output (although they are being
bootstrapped). Similar thing are being done for our webservices, which at
the moment use the standard MVC architecture.

Food for thought I hope...

Vincent de Lau
 [email-masked]

> -----Original Message-----
> From: Vincent de Lau [mailto:[email-masked]]
> Sent: Sunday, November 22, 2009 5:33 PM
> To: [email-masked]
> Subject: RE: [zf-contributors] Zend Framework 2.0 Roadmap
> 
> Hi all,
> 
> Although I'm not very involved in actual ZF development, I'd like to
> let my
> voice heard in the hope that it might inspire the people designing the
> new
> components. I'm working as lead developer at an Internet publisher,
> where we
> mainly develop comparison sites. I'll first describe how we are using
> Zend
> Framework, then I'll point out some things that we ran into and finally
> I'll
> have some general observations.
> 
> First some history: In the past, several developers before me developed
> their own libraries and 'frameworks'. They where however flawed,
> inconsistent and 'using classes' instead of doing object oriented
> programming. A year and a half ago, I proposed to either rebuild the
> existing framework from the ground up or start using a pre-existing
> framework. The final choice was made to start using Zend Framework. The
> reasons why we chose Zend is because it provided a good object oriented
> base, while not tying us down. Using an open source solution over an
> in-house solution also meant that documentation and support being
> available,
> while ensuring that there will always be people working on improving
> the
> framework.
> 
> Our first projects used ZF basically how it came out of the box. Off
> course
> we had to write some glue (mainly bootstrap) to put everything
> together. In
> the old framework, the 'controllers' where very fat, and our first ZF
> application was to. Also, almost everything in the site (menu's, texts,
> secondary content) was hard coded. Before starting out on our next big
> project, I decided that it was necessary to make more stuff easily
> configurable by non technical people and let the framework solve some
> of our
> problems to make our site more consistent.
> 
> We have developed a system where:
> - page meta information including routing and layout is stored in a
> database
> - pages can contain multiple components which they can also inherit
> from the
> layout
> - site structure (page hierarchy) is stored in the database
> - ACL information is stored in the database and linked to pages and
> page
> components
> - Non critical options are stored in the database (options not related
> with
> database access, error handling, logging and caching)
> 
> Our bootstrap takes care of setting up a database connection, error
> handling, logging (two stage, first to mail, later to database),
> profiling,
> caching (APC), Zend_Session (DB storage), Zend_Mail (encoding, default
> transport), Zend_View (XHTML, encoding), Zend_Layout and finally
> dispatching
> the request. We also created a small ORM that is also initialized in
> the
> bootstrap.
> 
> For our database driven stuff to work, we've created a plug-in that
> handles
> route loading from the database (cached), loading the ACL (cached),
> applying
> the ACL, injecting database parameters into the request, selecting the
> appropriate layout, setting the meta information on the layout (title,
> description, keywords) and dispatching additional components for
> inclusion
> in the layout.
> 
> This last task is controversial, because it uses
> Zend_View_Helper_Action.
> Components are considered to be individual actions on an action
> controller.
> The request parameters usually come from the database although they can
> use
> parameters from the original request. I've been looking for an
> alternative
> in the past, but the answer 'use view helpers' wasn't enough to solve
> all my
> issues.
> 
> 
> With Zend 2.0, I want to refactor large parts of what we have done. For
> instance, our site structure components where written before
> Zend_Navigation
> was complete. Our bootstrap process should be moved to use
> Zend_Application
> and we should cut down on the amount of singletons. These are pretty
> trivial
> tasks I suppose.
> 
> An area I'm not sure of yet is the Model or Domain part of the
> application.
> As said before, we used to have fat controllers that directly accessed
> the
> database. Currently we are using a custom ORM like solution that suits
> our
> needs; together with service type classes that either use the ORM or
> access
> the data source directly (we are also using web services). The ORM can
> handle both generic objects, provided a custom mapper class has been
> written, and ORM aware objects implementing an interface that allows
> the ORM
> layer to discover changed data and primary keys. I've been looking at
> Zend_Entity before building our custom solution, but the time didn't
> allow
> to wait for it to become ready. We will be looking at Doctrine, but
> might
> favour and improve our custom solution.
> 
> Another area of improvement I'm looking out for is a better way to
> control
> and standardize form HTML. For straight forward forms, the standard way
> forms are rendered is sufficient. However, designers and marketeers
> have the
> habit of having non standard requests. For some of our current forms,
> this
> required a lot a tweaking to get it right (before designers and
> marketeers
> change their mind off course...). A lot of the code I see is removing,
> reordering or otherwise trying to undo stuff that is added by (default)
> decorators. I suppose this is in part because our team hasn't got
> enough
> understanding how forms, form view helpers and decorators do their
> work.
> Honestly, I think that custom view helpers instead of the decorators
> might
> improve speed a lot.
> 
> Finally I'd also like to improve our page composition process. I'm not
> sure
> how Zend_Controller 2.0 will perform while executing multiple actions
> in a
> single request. I hope that it will improve or that we can more easily
> reuse
> the Dispatcher to perform a more lightweight secondary dispatch
> process. I
> think the main argument for the 'use view helpers' solution is that
> reentering the dispatch is expensive. My argument against using view
> helpers
> was that I'd need to implement some sort of dispatch process to be able
> to
> dynamically perform helpers and put the output at a designated point in
> the
> layout. For our situation I've decided that the gained flexibility is
> worth
> the performance hit. We also reduced a lot of this overhead by
> integrating
> caching for components. To put this whole story in better perspective:
> a non
> programmer can create a (simple) new page, add content, set meta
> information
> and put it in the navigation in minutes, where in the past it would
> cost a
> programmer half an hour to develop, integrate and test.
> 
> 
> Let's move on to the more general observations, not only based on my
> experience at work, but also with some personal projects I'm working
> on.
> 
> First of all, one of the things I love about ZF is the loose coupling.
> However, this loose coupling also has its downsides since it requires
> an
> initial set of glue code to make it all work. Zend_Tool reduces some of
> these requirements I suppose. I could imagine that it might be helpful
> to
> develop a example base application that contains a lot of the glue for
> a new
> developer to start with and customize as required. This might be in the
> scope of Zend_Tool, but could also be part of a separate initiative
> (Zendi,
> Zend Integrated) to complement Zend_Tool, quick start and tutorials.
> 
> Secondly... well actually I thought I had a list when starting this
> mail,
> but I either forgot or already mentioned them above...
> 
> 
> I hope that ZF 2.0 will mean a big improvement. I wouldn't mind if it
> broke
> major things if it results in a better, cleaner, leaner and more
> consistent
> framework. For me, ZF 2.0 will also be an opportunity to learn and
> improve.
> I hope that my mail provides some real world examples of how ZF is
> being
> used. I'll be available for questions and elaborations.
> 
> 
> Well, let's close off by thanking all contributors for their efforts
> and all
> readers for sticking with me. I'm a ZF fan and am sure ZF 2.0 will only
> increase my dedication.
> 
> Kind regards,
> 
> Vincent de Lau
>  [email-masked]
> 
> 
> 
> 
> 
> 

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 13:08:54 -0700
From: Matthew Ratzloff <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming 
	Conventions

--0016363b9922238b08046738efda
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

"This decision is basically already made..."
Before I weigh in, I'd first like to suggest that this is perhaps a poor
approach to this sort of thing.  It's like bringing in a job candidate and
saying, "He's basically already hired, but feel free to interview him."

That said, I have no real preference, but one consideration that I didn't
see in the latter solution was how to go about naming if there is both an
interface and an abstract class.  For example, Zend_View_Interface and
Zend_View_Abstract.  I'm guessing the abstract will probably change to
something like Zend_View_Engine or Zend_View_Adapter, but what about the
interface?

Also, how would you go about renaming classes in a situation where you have
a "root" class and an abstract class?  For example, Zend_Session extends
Zend_Session_Abstract.

-Matt

On Fri, Apr 10, 2009 at 11:24 AM, Matthew Weier O'Phinney
<[email-masked]>wrote:

> Greetings, all --
>
> Below is a proposal I am making to modify the Zend Framework Coding
> Standards conventions for the naming of Interfaces and Abstract classes.
>
> This decision is basically already made, but I'd appreciate any feedback
> that you may have on the matter.
>
> Thanks!
>
> The problem
> ===========
> PHP 5.3 introduces namespaces to the PHP language. While this won't have an
> impact much on userland code, it will have an impact on library and
> framework
> code, as it provides a useful paradigm for organizing components as well as
> simplifying syntax. Instead of having to say things like:
>
>    $analyzer = new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
>
> we can instead do something like this:
>
>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>
>    $analyzer = new Common_TextNum();
>
> or even:
>
>    namespace Zend\Search\Lucene\Analysis\Analyzer;
>
>    class Common_TextNum extends Common
>    {
>    }
>
> The problem that arises for Zend Framework has to do with how we name
> abstract
> classes and interfaces. Currently, the final segment of such classes are
> expected to end with _Abstract and _Interface, respectively. This will not
> work
> when we migrate to utilize namespaces, for two reasons.
>
> First, and most obviously, 'abstract' and 'interface' are reserved PHP
> keywords.
> As such, in situations such as the following:
>
>    namespace Zend\Controller\Request;
>
>    class Abstract
>    {
>    }
>
>    // or:
>
>    namespace Zend\Controller\Dispatcher;
>
>    interface Interface
>    {
>    }
>
> we'll run into issues.
>
> Second, and less obvious, is that perhaps the easiest solution breaks one
> of the
> key principles of namespaces (which are designed to help encapsulate
> components). This one's harder to explain, so let's look at examples.
> Consider a
> component such as Zend_Controller_Request. The simplest solution would be
> to
> name the abstract class or interface Zend\Controller\Request, and then have
> the
> various concrete implementations under that namespace:
>
>    namespace Zend\Controller;
>
>    interface Request
>    {
>    }
>
>    // and concrete ones:
>
>    namespace Zend\Controller\Request;
>
>    class Http
>    {
>    }
>
> What's the problem here? The interface is not in the same namespace as the
> concrete implementations.
>
> Potential solutions and recommendation
> ======================================
> So, how should Zend Framework "solve" these issues? A number of proposals
> and
> recommendations have been floated around, both within ZF circles and in the
> greater PHP community.
>
> Considerations include:
>
>  * Avoiding the use of PHP reserved keywords (already noted).
>  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
> name
>   describe its type -- which, to a degree, the current naming conventions
>   already violate). (See http://en.wikipedia.org/wiki/Hungarian_Notation,
> the
>   sections "Disadvantages of Systems Hungarian" and "Notable Opinions" for
> some
>   of the arguments against using Hungarian Notation.)
>
> Approaches that have been considered include:
>
>  * Using 'I' to prefix interfaces. This derives from standards in other
>   programming languages (.Net and python, in particular). This is just
> another
>   form of Hungarian Notation, however.
>
>  * Using "Interface" or "Abstract" as a class name suffix:
> RequestInterface,
>   RequestAbstract. Again, however this is Hungarian Notation.
>
>  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
> Base.
>   This is just substituting the word Base for Abstract, however, and is
> really
>   not much different than the above.
>
>  * Use generic, descriptive names indicative of functionality or behavior.
> As
>   examples from the SPL, "Countable", "Iterator", "ArrayObject".
>
> My recommendation is to use the latter, as it solves all considerations. It
> will
> take more thought when naming, but will ensure that components can live in
> a
> self-contained namespace, do not use reserved keywords, and avoid Hungarian
> Notation.
>
> Plan for implementation
> =======================
> I recommend that the Coding Standards documentation be updated to reflect
> this
> approach.
>
> All new components going into 1.8 and onwards should adopt these standards.
> In
> releases 1.9 and forward, we will begin migrating existing
> interfaces/abstract
> classe. First, new classes/interfaces will be created that follow these
> conventions and which extend the originals; later, any type-hinting based
> on the
> original class/interface names will be updated to point to the new names;
> and
> finally, in 2.0, we will remove the old interfaces/abstract classes
> entirely.
>
> --
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/
>

--0016363b9922238b08046738efda
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>&quot;This decision is basically already made...&quot;<div><br></div><=
div>Before I weigh in, I&#39;d=C2=A0first=C2=A0like to suggest that this is=
 perhaps a poor approach to this sort of thing. =C2=A0It&#39;s like bringin=
g in a job candidate and saying, &quot;He&#39;s basically already hired, bu=
t feel free to interview him.&quot;</div>
<div><br></div><div>That said, I have no real preference, but one considera=
tion that I didn&#39;t see in the latter solution was how to go about namin=
g if there is both an interface and an abstract class. =C2=A0For example, Z=
end_View_Interface and Zend_View_Abstract. =C2=A0I&#39;m guessing the abstr=
act will probably change to something like Zend_View_Engine or Zend_View_Ad=
apter, but what about the interface?</div>
<div><br></div><div>Also, how would you go about renaming classes in a situ=
ation where you have a &quot;root&quot; class and an abstract class? =C2=A0=
For example, Zend_Session extends Zend_Session_Abstract.</div><div><br></di=
v>
<div>-Matt<br><br><div class=3D"gmail_quote">On Fri, Apr 10, 2009 at 11:24 =
AM, Matthew Weier O&#39;Phinney <span dir=3D"ltr">&lt;<a href=3D"mailto:mat=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
Greetings, all --<br>
<br>
Below is a proposal I am making to modify the Zend Framework Coding<br>
Standards conventions for the naming of Interfaces and Abstract classes.<br=
<br>
This decision is basically already made, but I&#39;d appreciate any feedbac=
k<br>
that you may have on the matter.<br>
<br>
Thanks!<br>
<br>
The problem<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
PHP 5.3 introduces namespaces to the PHP language. While this won&#39;t hav=
e an<br>
impact much on userland code, it will have an impact on library and framewo=
rk<br>
code, as it provides a useful paradigm for organizing components as well as=
<br>
simplifying syntax. Instead of having to say things like:<br>
<br>
 =C2=A0 =C2=A0$analyzer =3D new Zend_Search_Lucene_Analysis_Analyzer_Common=
_TextNum();<br>
<br>
we can instead do something like this:<br>
<br>
 =C2=A0 =C2=A0namespace Zend\Search\Lucene\Analysis\Analyzer;<br>
<br>
 =C2=A0 =C2=A0$analyzer =3D new Common_TextNum();<br>
<br>
or even:<br>
<br>
 =C2=A0 =C2=A0namespace Zend\Search\Lucene\Analysis\Analyzer;<br>
<br>
 =C2=A0 =C2=A0class Common_TextNum extends Common<br>
 =C2=A0 =C2=A0{<br>
 =C2=A0 =C2=A0}<br>
<br>
The problem that arises for Zend Framework has to do with how we name abstr=
act<br>
classes and interfaces. Currently, the final segment of such classes are<br=
expected to end with _Abstract and _Interface, respectively. This will not =
work<br>
when we migrate to utilize namespaces, for two reasons.<br>
<br>
First, and most obviously, &#39;abstract&#39; and &#39;interface&#39; are r=
eserved PHP keywords.<br>
As such, in situations such as the following:<br>
<br>
 =C2=A0 =C2=A0namespace Zend\Controller\Request;<br>
<br>
 =C2=A0 =C2=A0class Abstract<br>
 =C2=A0 =C2=A0{<br>
 =C2=A0 =C2=A0}<br>
<br>
 =C2=A0 =C2=A0// or:<br>
<br>
 =C2=A0 =C2=A0namespace Zend\Controller\Dispatcher;<br>
<br>
 =C2=A0 =C2=A0interface Interface<br>
 =C2=A0 =C2=A0{<br>
 =C2=A0 =C2=A0}<br>
<br>
we&#39;ll run into issues.<br>
<br>
Second, and less obvious, is that perhaps the easiest solution breaks one o=
f the<br>
key principles of namespaces (which are designed to help encapsulate<br>
components). This one&#39;s harder to explain, so let&#39;s look at example=
s. Consider a<br>
component such as Zend_Controller_Request. The simplest solution would be t=
o<br>
name the abstract class or interface Zend\Controller\Request, and then have=
 the<br>
various concrete implementations under that namespace:<br>
<br>
 =C2=A0 =C2=A0namespace Zend\Controller;<br>
<br>
 =C2=A0 =C2=A0interface Request<br>
 =C2=A0 =C2=A0{<br>
 =C2=A0 =C2=A0}<br>
<br>
 =C2=A0 =C2=A0// and concrete ones:<br>
<br>
 =C2=A0 =C2=A0namespace Zend\Controller\Request;<br>
<br>
 =C2=A0 =C2=A0class Http<br>
 =C2=A0 =C2=A0{<br>
 =C2=A0 =C2=A0}<br>
<br>
What&#39;s the problem here? The interface is not in the same namespace as =
the<br>
concrete implementations.<br>
<br>
Potential solutions and recommendation<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
So, how should Zend Framework &quot;solve&quot; these issues? A number of p=
roposals and<br>
recommendations have been floated around, both within ZF circles and in the=
<br>
greater PHP community.<br>
<br>
Considerations include:<br>
<br>
=C2=A0* Avoiding the use of PHP reserved keywords (already noted).<br>
=C2=A0* Avoiding Hungarian Notation (i.e., having the name or a portion of =
the name<br>
 =C2=A0 describe its type -- which, to a degree, the current naming convent=
ions<br>
 =C2=A0 already violate). (See <a href=3D"http://en.wikipedia.org/wiki/Hung=
arian_Notation" target=3D"_blank">http://en.wikipedia.org/wiki/Hungarian_No=
tation</a>, the<br>
 =C2=A0 sections &quot;Disadvantages of Systems Hungarian&quot; and &quot;N=
otable Opinions&quot; for some<br>
 =C2=A0 of the arguments against using Hungarian Notation.)<br>
<br>
Approaches that have been considered include:<br>
<br>
=C2=A0* Using &#39;I&#39; to prefix interfaces. This derives from standards=
 in other<br>
 =C2=A0 programming languages (.Net and python, in particular). This is jus=
t another<br>
 =C2=A0 form of Hungarian Notation, however.<br>
<br>
=C2=A0* Using &quot;Interface&quot; or &quot;Abstract&quot; as a class name=
 suffix: RequestInterface,<br>
 =C2=A0 RequestAbstract. Again, however this is Hungarian Notation.<br>
<br>
=C2=A0* Using the term &quot;Base&quot; for abstract classes: BaseRequest, =
RequestBase, Base.<br>
 =C2=A0 This is just substituting the word Base for Abstract, however, and =
is really<br>
 =C2=A0 not much different than the above.<br>
<br>
=C2=A0* Use generic, descriptive names indicative of functionality or behav=
ior. As<br>
 =C2=A0 examples from the SPL, &quot;Countable&quot;, &quot;Iterator&quot;,=
 &quot;ArrayObject&quot;.<br>
<br>
My recommendation is to use the latter, as it solves all considerations. It=
 will<br>
take more thought when naming, but will ensure that components can live in =
a<br>
self-contained namespace, do not use reserved keywords, and avoid Hungarian=
<br>
Notation.<br>
<br>
Plan for implementation<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
I recommend that the Coding Standards documentation be updated to reflect t=
his<br>
approach.<br>
<br>
All new components going into 1.8 and onwards should adopt these standards.=
 In<br>
releases 1.9 and forward, we will begin migrating existing interfaces/abstr=
act<br>
classe. First, new classes/interfaces will be created that follow these<br>
conventions and which extend the originals; later, any type-hinting based o=
n the<br>
original class/interface names will be updated to point to the new names; a=
nd<br>
finally, in 2.0, we will remove the old interfaces/abstract classes entirel=
y.<br>
<font color=3D"#888888"><br>
--<br>
Matthew Weier O&#39;Phinney<br>
Software Architect =C2=A0 =C2=A0 =C2=A0| <a href=3D"mailto:[email-masked]=
">[email-masked]</a><br>
Zend Framework =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://framew=
ork.zend.com/" target=3D"_blank">http://framework.zend.com/</a><br>
</font></blockquote></div><br></div></div>

--0016363b9922238b08046738efda--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 07:57:23 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Poll: 2.0 and Namespace impact of class names

-- Ralph Schindler <[email-masked]> wrote
(on Tuesday, 16 March 2010, 01:31 AM -0500):
> On the Usage of Compound Names --

(My commentary below...)

> With namespaces, we have the opportunity to create aliases to
> specific namespace our code consumes.  For example, we can do
> something like this:
> 
> 
> <?php
> // in a script that consumes Zend Frameowrk
> use Zend\Filter as f;
> 
> $filter = new f\Something.php
> 
> ?>
> 
> 
> In the past, with fully prefixed names, it was easy to understand
> the context of a particular class since the namespace is carried
> with it. $filter = new Zend_Filter_Int(); is clearly an Integer
> filter, and the class name fully reflects that.
> 
> The question with namespaces is, should we use compound names to
> identify classes separate of the namespace itself.  This can be
> better demonstrated with the following code:
> 
> 
> <?php
> 
> use Zend\Filter as f;
> 
> $filter = new f\Int();
> 
> ?>
> 
> 
> -- VS --
> 
> 
> <?php
> 
> use Zend\Filter as f;
> 
> $filter = new f\IntFilter();
> 
> ?>

Honestly, choosing "f" as an alias just seems like a bad idea from the
outset -- does it refer to "filter", or "form", or "file"? If you go
with a more explicit alias:

    use Zend\Filter;

    $filter = new Filter\Int;

the intent is already there.

I can see your point being more present if you import a single class
from a namespace:

    use Zend\Filter\Int;
    $filter = new Int();

*This* example more properly shows the issues, to my thinking. But even
then, better aliasing solves the problem:

    use Zend\Filter\Int as IntFilter;
    $filter = new IntFilter;

This requires no changes to naming whatsoever, yet still solves the
problems you describe -- but instead of doing it at the library level,
it's at the end-user level.

Yes, there will be a few places where we need to re-think names, such as
Zend\CodeGenerator and Zend\Reflection, but I think in the bulk of
instances, it shouldn't be a problem.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Mon, 27 Jul 2009 10:24:51 +0200
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Servicesto
	ZendX Proposal

Just for information:
There is an existing contributor list available:
http://framework.zend.com/wiki/pages/viewpage.action?pageId=11036

But it's unmaintained for a long time as it's not refered at the main page.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

> -- Carlton Gibson <[email-masked]> wrote
> (on Sunday, 26 July 2009, 06:59 PM +0100):
>> On 26 Jul 2009, at 16:29, Matthew Weier O'Phinney wrote:
>>
>> > We need more community help in maintaining the framework. I have some
>> > ideas on how to achieve this, but I need *your* ideas as well, as
>> > contributors.
>>
>>  From my experience it's really hard to get started helping out, even if
>> you want to.
>>
>> I don't have (or haven't yet had) the time (or indeed perhaps skill :-)
>> to be taking on the lead on major components, but I have had some time to
>> work on something. What I found though was that it wasn't very clear
>> where or how to start.
>>
>> I think there needs to be a much clearer and easier to follow route into
>> helping out. (Something like the Post Office "Help Wanted" board in Paper
>> Mario would be great.)
>
> This is a really cool idea, and something we could probably get into
> place pretty quickly. It would, however, require both maintainers
> posting and requesting help, as well as somebody periodically going
> through the tracker and identifying components that are in need of new
> maintainers. I'll brainstorm some ideas around this.
>
>> The issue tracker works but it takes too much time to learn. (95% of
>> the time and energy I have had available has been spent on the issue
>> tracker rather than actually doing anything. Admittedly I'm slow, but
>> I doubt I'm alone.)
>
> The issue tracker has a wealth of information, and that both works in
> its favor and against it. I've got an offer of help from Atlassian to
> upgrade and optimize our install, and that may make things a better in
> this regard.
>
>> I also think the documentation needs to be moved to a wiki format. A lot
>> of the complaints on the mailing list concern the documentation -- so let
>> people fix it themselves. (Again, I've often thought about suggesting a
>> fix to the docs but am put off by the thought of having to take on the
>> issue tracker for the sake of a single sentence or paragraph.)
>
> We will *not* be moving to a wiki format. We actually use DocBook for
> its intended purpose: to make it easy to create documentation in a
> variety of formats. We create HTML documentation, obviously, but we also
> create a PDF version for the zend.com website, and several people have
> created CHM versions. Thomas and Mikael have convinced me to have PDF
> and CHM targets by default in our Makefile to ensure that these are easy
> for developers to produce on-demand.
>
> One way we can easily solicit feedback for improving documentation is to
> add comments to the manual. This is something we need to add to the
> website, and then we also need to add a process for periodically
> reviewing the comments and incorporating feedback into the manual. I'm
> hoping we can accomplish this for the 1.10 release.
>
>> Finally, I think there needs to be a place (the contributors list maybe)
>> where people are welcome (encouraged) to come with questions about how to
>> proceed with an issue. Not enough people are subscribed to each issue in
>> the tracker to make this viable there. (Perhaps this is what the
>> contributors list is for but if so that needs to be better advertised.)
>
> This is exactly one purpose of the contributors list, and I encourage
> you to steer people here if they want to discuss issues from the
> tracker.
>
>> Just ideas.
>
> And some very good ideas are contained in it! Thank you!
>
> -- 
> Matthew Weier O'Phinney
> Project Lead            | [email-masked]
> Zend Framework          | http://framework.zend.com/ 

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 29 Sep 2009 23:24:05 +0200
From: =?UTF-8?B?Sm/DsyDDgWTDoW0=?= <[email-masked]>
To: James Dempster <[email-masked]>
Cc: Graham Anderson <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Google Wave Invites

Send me too, please. ([email-masked])

Thanks,
=C3=81d=C3=A1m

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Mar 2010 11:04:13 +0100
From: Giorgio Sironi <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Poll: Namespace usage in ZF class method 
	signatures

On Tue, Mar 16, 2010 at 8:21 AM, Stanislav Malyshev <[email-masked]> wrote:
>> <?php
>>
>> namespace Foo;
>>
>> class Bar
>> {
>> // this method accepts an instance of itself
>> public static function baz(Bar $bar) {}
>> }
>
> I'm for this one. That's why we started all the thing with namespaces!

+1. Any other signature defeats the purpose of namespaces.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 12:37:17 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] New Sections for Zend Framework 2.0 Roadmap

Hey, all --

There have been several new sections posted to the 2.0 roadmap that I
want to bring to your attention:

 * Plugins:
   http://framework.zend.com/wiki/display/ZFDEV2/Plugin+Architectures 

 * Zend_Form:
   http://framework.zend.com/wiki/display/ZFDEV2/Zend_Form+2.0

 * Router:
   http://framework.zend.com/wiki/display/ZFDEV2/Zend_Controller_router+2.0

Please review and comment when you have time.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 23 Sep 2009 11:14:54 -0500
From: Ralph Schindler <[email-masked]>
To: Rob Allen <[email-masked]>
CC: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?

> Mildly surprised that noone noticed that ZendX db adapters didn't work 
> in 1.9.0 before the release of 1.9.0 though. Surely the tests failed?!

You actually don't have to use Zend_Db::factory() to create an adapter ;)

As for the Zend_Db testing harness, its complicated.  So much so that 
I've started a rewrite of the Zend_Db TestUtil, and also so much so that 
its hard for outside components (like ZendX) to utilize its infrastructure.

This will be addressed soon enough though.

-ralph

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 16:38:57 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

-- Matthew Ratzloff <[email-masked]> wrote
(on Friday, 10 April 2009, 01:08 PM -0700):
> "This decision is basically already made..."
>=20
> Before I weigh in, I'd=A0first=A0like to suggest that this is perhaps a=
 poor
> approach to this sort of thing. =A0It's like bringing in a job candidat=
e and
> saying, "He's basically already hired, but feel free to interview him."

Heh -- I actually did this intentionally in part to stimulate the
debate. Nothing like something inflammatory to get people to start
commenting. :)

> That said, I have no real preference, but one consideration that I didn=
't see
> in the latter solution was how to go about naming if there is both an i=
nterface
> and an abstract class. =A0For example, Zend_View_Interface and
> Zend_View_Abstract. =A0I'm guessing the abstract will probably change t=
o
> something like Zend_View_Engine or Zend_View_Adapter, but what about th=
e
> interface?

It will depend in large part on the implementation. In the case of
Zend_View, it will likely actually be the following:

  * Zend_View_Interface -> Zend\View\Engine (the interface references
    "getEngine()", which makes this appropriate

  * Zend_View_Abstract -> Zend\View\PhpCore (because this is the core
    functionality for a concrete PHP view implementation)

...and that leads to your next point, as we need to address Zend_View...

> Also, how would you go about renaming classes in a situation where you =
have a
> "root" class and an abstract class? =A0For example, Zend_Session extend=
s
> Zend_Session_Abstract.

Zend_View would likely become Zend\View\PhpEngine, as it's a view
engine that utilizes PHP. But the basic idea is that it now moves
underneath the Zend\View namespace -- and that's what will happen to
other components as well.

We'll have to discuss these on a case by case instance. As more are
moved over, we'll likely get some emerging idioms to draw upon.

> On Fri, Apr 10, 2009 at 11:24 AM, Matthew Weier O'Phinney <matthew@zend=
.com>
> wrote:
>=20
>     Greetings, all --
>=20
>     Below is a proposal I am making to modify the Zend Framework Coding
>     Standards conventions for the naming of Interfaces and Abstract cla=
sses.
>=20
>     This decision is basically already made, but I'd appreciate any fee=
dback
>     that you may have on the matter.
>=20
>     Thanks!
>=20
>     The problem
>     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>     PHP 5.3 introduces namespaces to the PHP language. While this won't=
 have an
>     impact much on userland code, it will have an impact on library and
>     framework
>     code, as it provides a useful paradigm for organizing components as=
 well as
>     simplifying syntax. Instead of having to say things like:
>=20
>     =A0 =A0$analyzer =3D new Zend_Search_Lucene_Analysis_Analyzer_Commo=
n_TextNum();
>=20
>     we can instead do something like this:
>=20
>     =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
>=20
>     =A0 =A0$analyzer =3D new Common_TextNum();
>=20
>     or even:
>=20
>     =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
>=20
>     =A0 =A0class Common_TextNum extends Common
>     =A0 =A0{
>     =A0 =A0}
>=20
>     The problem that arises for Zend Framework has to do with how we na=
me
>     abstract
>     classes and interfaces. Currently, the final segment of such classe=
s are
>     expected to end with _Abstract and _Interface, respectively. This w=
ill not
>     work
>     when we migrate to utilize namespaces, for two reasons.
>=20
>     First, and most obviously, 'abstract' and 'interface' are reserved =
PHP
>     keywords.
>     As such, in situations such as the following:
>=20
>     =A0 =A0namespace Zend\Controller\Request;
>=20
>     =A0 =A0class Abstract
>     =A0 =A0{
>     =A0 =A0}
>=20
>     =A0 =A0// or:
>=20
>     =A0 =A0namespace Zend\Controller\Dispatcher;
>=20
>     =A0 =A0interface Interface
>     =A0 =A0{
>     =A0 =A0}
>=20
>     we'll run into issues.
>=20
>     Second, and less obvious, is that perhaps the easiest solution brea=
ks one
>     of the
>     key principles of namespaces (which are designed to help encapsulat=
e
>     components). This one's harder to explain, so let's look at example=
s.
>     Consider a
>     component such as Zend_Controller_Request. The simplest solution wo=
uld be
>     to
>     name the abstract class or interface Zend\Controller\Request, and t=
hen have
>     the
>     various concrete implementations under that namespace:
>=20
>     =A0 =A0namespace Zend\Controller;
>=20
>     =A0 =A0interface Request
>     =A0 =A0{
>     =A0 =A0}
>=20
>     =A0 =A0// and concrete ones:
>=20
>     =A0 =A0namespace Zend\Controller\Request;
>=20
>     =A0 =A0class Http
>     =A0 =A0{
>     =A0 =A0}
>=20
>     What's the problem here? The interface is not in the same namespace=
 as the
>     concrete implementations.
>=20
>     Potential solutions and recommendation
>     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>     So, how should Zend Framework "solve" these issues? A number of pro=
posals
>     and
>     recommendations have been floated around, both within ZF circles an=
d in the
>     greater PHP community.
>=20
>     Considerations include:
>=20
>     =A0* Avoiding the use of PHP reserved keywords (already noted).
>     =A0* Avoiding Hungarian Notation (i.e., having the name or a portio=
n of the
>     name
>     =A0 describe its type -- which, to a degree, the current naming con=
ventions
>     =A0 already violate). (See http://en.wikipedia.org/wiki/Hungarian_N=
otation,
>     the
>     =A0 sections "Disadvantages of Systems Hungarian" and "Notable Opin=
ions" for
>     some
>     =A0 of the arguments against using Hungarian Notation.)
>=20
>     Approaches that have been considered include:
>=20
>     =A0* Using 'I' to prefix interfaces. This derives from standards in=
 other
>     =A0 programming languages (.Net and python, in particular). This is=
 just
>     another
>     =A0 form of Hungarian Notation, however.
>=20
>     =A0* Using "Interface" or "Abstract" as a class name suffix:
>     RequestInterface,
>     =A0 RequestAbstract. Again, however this is Hungarian Notation.
>=20
>     =A0* Using the term "Base" for abstract classes: BaseRequest, Reque=
stBase,
>     Base.
>     =A0 This is just substituting the word Base for Abstract, however, =
and is
>     really
>     =A0 not much different than the above.
>=20
>     =A0* Use generic, descriptive names indicative of functionality or =
behavior.
>     As
>     =A0 examples from the SPL, "Countable", "Iterator", "ArrayObject".
>=20
>     My recommendation is to use the latter, as it solves all considerat=
ions. It
>     will
>     take more thought when naming, but will ensure that components can =
live in
>     a
>     self-contained namespace, do not use reserved keywords, and avoid H=
ungarian
>     Notation.
>=20
>     Plan for implementation
>     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>     I recommend that the Coding Standards documentation be updated to r=
eflect
>     this
>     approach.
>=20
>     All new components going into 1.8 and onwards should adopt these st=
andards.
>     In
>     releases 1.9 and forward, we will begin migrating existing interfac=
es/
>     abstract
>     classe. First, new classes/interfaces will be created that follow t=
hese
>     conventions and which extend the originals; later, any type-hinting=
 based
>     on the
>     original class/interface names will be updated to point to the new =
names;
>     and
>     finally, in 2.0, we will remove the old interfaces/abstract classes
>     entirely.
>=20
>     --
>     Matthew Weier O'Phinney
>     Software Architect =A0 =A0 =A0| [email-masked]
>     Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>=20
>=20

--=20
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 05 Jul 2009 14:48:38 +0200
From: Ralf Eggert <[email-masked]>
To: "Whitcraft, Jon" <[email-masked]>
CC: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: [zf-contributors] Re: [fw-mvc] Two Proposals Ready for Review

Hi,

just want to step in here:

Whitcraft, Jon schrieb am 02.07.2009 14:40:
> Please comment on these proposals so we can get the ball rolling for 1.9 or 1.10

Are there any plans for a 1.10 release yet? I thought 1.9 will be the
last minor release before 2.0?

Thanks and best regards,

Ralf

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 22 Mar 2010 17:38:17 +0000
From: David Caunt <[email-masked]>
To: Sascha-Oliver Prolic <[email-masked]>
Cc: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend View Helpers in 2.0: Command Pattern?

--00151747b10496aae404826729e5
Content-Type: text/plain; charset=UTF-8

+1 - I looked at both patterns and feel that View Helpers are neither

On 22 March 2010 17:17, Sascha-Oliver Prolic <[email-masked]>wrote:

> Hi all,
>
> As view helpers are neither strategy nor command, I prefer the use of
> the "__invoke" method, instead of "execute" or "direct". This will
> also give a much smoother interface.
>
> --
> Sascha-Oliver Prolic
> Intelligent Web Services Ltd.
>

-- 
Save Water...Drink Ouzo !

--00151747b10496aae404826729e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 - I looked at both patterns and feel that View Helpers are neither<br><b=
r><div class=3D"gmail_quote">On 22 March 2010 17:17, Sascha-Oliver Prolic <=
span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">saschap=
[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Hi all,<br>
<br>
As view helpers are neither strategy nor command, I prefer the use of<br>
the &quot;__invoke&quot; method, instead of &quot;execute&quot; or &quot;di=
rect&quot;. This will<br>
also give a much smoother interface.<br>
<font color=3D"#888888"><br>
--<br>
Sascha-Oliver Prolic<br>
Intelligent Web Services Ltd.<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Save Water...Dri=
nk Ouzo !<br>

--00151747b10496aae404826729e5--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 19:13:39 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] [[email-masked]: Re: [zf-contributors]
	Proposal to update Abstract/Interface Naming Conventions]

-- Matthew Weier O'Phinney <[email-masked]> wrote
(on Friday, 10 April 2009, 04:39 PM -0400):
> Forwarding from Ben, who intended to copy the list...
> 
> ----- Forwarded message from Benjamin Eberlei <[email-masked]> -----
> 
> From: Benjamin Eberlei <[email-masked]>
> To: Matthew Weier O'Phinney <[email-masked]>
> Date: Fri, 10 Apr 2009 18:58:02 +0000
> Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
> 	Conventions
> 
> 
> moving to this new namespace implementation and breaking all old ones is a
> serious BC,
> so why do we only allow slight changes for everything else? I thought we
> would just go to "change the serious technical debt, but as BC as
> possible", changing the name of an interface is the exact difference of
> that.

It is, but we're going to need to do it once we move to namespaces
anyways -- because our CS were written before namespaces were even
proposed for inclusion in PHP.

This is also why I propose the gradual changes over a series of
versions. This allows us to provide migration instructions that users
can gradually implement, making their code more future-proof. If the
new versions of the interfaces and abstract classes extend the
originals, there is no BC break until we finally drop the old classes --
which, as I mentioned, will not happen until 2.0.

> additionally, the generic name one seems strange in my eyes. How would you
> do that for
> the example of request, response, dispatcher? Validation interface? 

First off, the request and response objects need interfaces, and then
potentially abstract implementations. Either way, this is easy:

  * Zend\Controller\Request\RequestEnvironment, RequestObject
    (interface, abstract)
  * Zend\Controller\Response\ResponsePayload, ResponseObject
    (interface, abstract)
  * Zend\Controller\Dispatcher\DispatchMapper (interface)
  * Zend\Validate\Validatible, Validator (interface, abstract)

The names take a little creativity, but they also make it clearer in
your code what you're doing:

    namespace Zend\Controller\Request;

    class HttpEnvironment implements RequestEnvironment
    {
    }

    // or
    namespace Zend\Validate;

    class Alpha extends Validator
    {
    }

> i don't seem to find good ones. ResponseObject, RequestObject,
> Validatable are ok, but from the typehints its very hard to suggest
> that these are interfaces in contrast to concrete implementation.

Typehints should typically be to interfaces anyways...

> furthermore, why break with the ways of java, python, and .net? this is
> what many programmers are used to.

Because Java and .Net are strongly typed languages, and PHP isn't.
Because just because a convention worked for one language doesn't mean
it's appropriate for another. Because PHP is not Java, is not Python, is
not .NET.

There have been a TON of debates amongst ZF contributors about naming,
and making the names meaningful. I would expect that this proposal would
probably be very welcome to those individuals. (Matt R., I'm looking at
you...)

> As a last point, having implementation and interface in different
> packages is actually the single most important issue about having an
> interface anyways and a huge benefit for object oriented design.  this
> separates the concerns and reduces dependencies, so I would love to
> see this in a 2.0 version.

There's a difference between using an interface in userland code, and
using one within a framework or library. In your userland code, you
*will* have the interface in a different package:

    namespace Foo\Controller\Request;
    import Zend\Controller\Request as ZfRequest;

    CustomHttpRequest extends ZfRequest\HttpEnvironment
    {
    }

*Within* the framework, it's better for them to be in the same
namespace, to allow selectively packaging components for distribution or
deployment.

> That is what i am greatly missing in ZF, that for example the
> controller is implemented with several very large abstract classes
> only and the dependencies are so hard-wired that its impossible to
> exchange just one part of the controller to add specific functionality
> without having to change considerable other parts also.

This has nothing to do with naming conventions, and is a topic we
already plan to address for (or before) 2.0. (Please search for
"Zend_Controller 2.0" on the wiki for some of the plans.)

> On Fri, 10 Apr 2009 14:24:34 -0400, Matthew Weier O'Phinney
> <[email-masked]> wrote:
> > Greetings, all --
> > 
> > Below is a proposal I am making to modify the Zend Framework Coding
> > Standards conventions for the naming of Interfaces and Abstract classes.
> > 
> > This decision is basically already made, but I'd appreciate any feedback
> > that you may have on the matter.
> > 
> > Thanks!
> > 
> > The problem
> > ===========
> > PHP 5.3 introduces namespaces to the PHP language. While this won't have
> > an
> > impact much on userland code, it will have an impact on library and
> > framework
> > code, as it provides a useful paradigm for organizing components as well
> > as
> > simplifying syntax. Instead of having to say things like:
> > 
> >     $analyzer = new
> Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
> > 
> > we can instead do something like this:
> > 
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > 
> >     $analyzer = new Common_TextNum();
> > 
> > or even:
> > 
> >     namespace Zend\Search\Lucene\Analysis\Analyzer;
> > 
> >     class Common_TextNum extends Common
> >     {
> >     }
> > 
> > The problem that arises for Zend Framework has to do with how we name
> > abstract
> > classes and interfaces. Currently, the final segment of such classes are
> > expected to end with _Abstract and _Interface, respectively. This will
> not
> > work
> > when we migrate to utilize namespaces, for two reasons.
> > 
> > First, and most obviously, 'abstract' and 'interface' are reserved PHP
> > keywords.
> > As such, in situations such as the following:
> > 
> >     namespace Zend\Controller\Request;
> > 
> >     class Abstract
> >     {
> >     }
> > 
> >     // or:
> > 
> >     namespace Zend\Controller\Dispatcher;
> > 
> >     interface Interface
> >     {
> >     }
> > 
> > we'll run into issues.
> > 
> > Second, and less obvious, is that perhaps the easiest solution breaks one
> > of the
> > key principles of namespaces (which are designed to help encapsulate
> > components). This one's harder to explain, so let's look at examples.
> > Consider a
> > component such as Zend_Controller_Request. The simplest solution would be
> > to
> > name the abstract class or interface Zend\Controller\Request, and then
> > have the
> > various concrete implementations under that namespace:
> > 
> >     namespace Zend\Controller;
> > 
> >     interface Request
> >     {
> >     }
> > 
> >     // and concrete ones:
> > 
> >     namespace Zend\Controller\Request;
> > 
> >     class Http
> >     {
> >     }
> > 
> > What's the problem here? The interface is not in the same namespace as
> the
> > concrete implementations.
> > 
> > Potential solutions and recommendation
> > ======================================
> > So, how should Zend Framework "solve" these issues? A number of proposals
> > and
> > recommendations have been floated around, both within ZF circles and in
> > the
> > greater PHP community.
> > 
> > Considerations include:
> > 
> >  * Avoiding the use of PHP reserved keywords (already noted).
> >  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
> > name
> >    describe its type -- which, to a degree, the current naming
> conventions
> >    already violate). (See
> http://en.wikipedia.org/wiki/Hungarian_Notation,
> > the
> >    sections "Disadvantages of Systems Hungarian" and "Notable Opinions"
> > for some
> >    of the arguments against using Hungarian Notation.)
> > 
> > Approaches that have been considered include:
> > 
> >  * Using 'I' to prefix interfaces. This derives from standards in other
> >    programming languages (.Net and python, in particular). This is just
> > another
> >    form of Hungarian Notation, however.
> > 
> >  * Using "Interface" or "Abstract" as a class name suffix:
> > RequestInterface,
> >    RequestAbstract. Again, however this is Hungarian Notation.
> > 
> >  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
> > Base.
> >    This is just substituting the word Base for Abstract, however, and is
> > really
> >    not much different than the above.
> > 
> >  * Use generic, descriptive names indicative of functionality or
> behavior.
> > As
> >    examples from the SPL, "Countable", "Iterator", "ArrayObject".
> > 
> > My recommendation is to use the latter, as it solves all considerations.
> > It will
> > take more thought when naming, but will ensure that components can live
> in
> > a
> > self-contained namespace, do not use reserved keywords, and avoid
> > Hungarian
> > Notation.
> > 
> > Plan for implementation
> > =======================
> > I recommend that the Coding Standards documentation be updated to reflect
> > this
> > approach.
> > 
> > All new components going into 1.8 and onwards should adopt these
> > standards. In
> > releases 1.9 and forward, we will begin migrating existing
> > interfaces/abstract
> > classe. First, new classes/interfaces will be created that follow these
> > conventions and which extend the originals; later, any type-hinting based
> > on the
> > original class/interface names will be updated to point to the new names;
> > and
> > finally, in 2.0, we will remove the old interfaces/abstract classes
> > entirely.
> > 
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | [email-masked]
> > Zend Framework          | http://framework.zend.com/
> 
> 
> ----- End forwarded message -----
> 
> -- 
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/
> 

-- 
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 12 Apr 2009 18:49:25 +0200
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
OpenPGP: id=6B3BF3D0;
	url=http://pgp.dasprids.de/[email-masked]%20(0x6B3BF3D0)%20pub.asc
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

Well, at least the Zend_Tag_IItem had to go, because it simply sounded
arkward ;)
...................................
:  ___   _   ___ ___ ___ _ ___    :
: |   \ /_\ / __| _ \ _ (_)   \   :
: | |) / _ \\__ \  _/   / | |) |  :
: |___/_/:\_\___/_| |_|_\_|___/   :
:........:........................:
: Web    : http://www.dasprids.de :
: E-mail : [email-masked]       :
: Jabber : [email-masked]     :
: ICQ    : 105677955              :
:........:........................:

Benjamin Eberlei schrieb:
> why do something that is not even accepted yet?
> 
> but in your case CloudDecorator and TagDecorator seem to be better than *Core 
> for me
> 
> On Sunday 12 April 2009 18:05:33 Ben Scholzen 'DASPRiD' wrote:
>> Hey Matthew,
>>
>> I'm currently reworking Zend_Tag to fit those new naming. I renamed
>> Zend_Tag_IItem to Zend_Tag_Taggable, which sounds good. But now for the
>> following two abstract classes:
>>
>> Zend_Tag_Cloud_Decorator_Cloud
>> Zend_Tag_Cloud_Decorator_Tag
>>
>> How would you name them? I had the following in mind, but I'm not sure:
>>
>> Zend_Tag_Cloud_Decorator_CloudCore
>> Zend_Tag_Cloud_Decorator_TagCore
>>
>> As those just substitute "Abstract" with "Core" then. Any thoughts on that?
>>
>> Ben
>> ...................................
>>
>> :  ___   _   ___ ___ ___ _ ___    :
>> : |   \ /_\ / __| _ \ _ (_)   \   :
>> : | |) / _ \\__ \  _/   / | |) |  :
>> : |
>> : |___/_/:\_\___/_| |_|_\_|___/   :
>> :
>> :........:........................:
>> : Web    : http://www.dasprids.de :
>> : E-mail : [email-masked]       :
>> : Jabber : [email-masked]     :
>> : ICQ    : 105677955              :
>> :........:........................:
>>
>> Matthew Weier O'Phinney schrieb:
>>> Greetings, all --
>>>
>>> Below is a proposal I am making to modify the Zend Framework Coding
>>> Standards conventions for the naming of Interfaces and Abstract classes.
>>>
>>> This decision is basically already made, but I'd appreciate any feedback
>>> that you may have on the matter.
>>>
>>> Thanks!
>>>
>>> The problem
>>> ===========
>>> PHP 5.3 introduces namespaces to the PHP language. While this won't have
>>> an impact much on userland code, it will have an impact on library and
>>> framework code, as it provides a useful paradigm for organizing
>>> components as well as simplifying syntax. Instead of having to say things
>>> like:
>>>
>>>     $analyzer = new
>>> Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
>>>
>>> we can instead do something like this:
>>>
>>>     namespace Zend\Search\Lucene\Analysis\Analyzer;
>>>
>>>     $analyzer = new Common_TextNum();
>>>
>>> or even:
>>>
>>>     namespace Zend\Search\Lucene\Analysis\Analyzer;
>>>
>>>     class Common_TextNum extends Common
>>>     {
>>>     }
>>>
>>> The problem that arises for Zend Framework has to do with how we name
>>> abstract classes and interfaces. Currently, the final segment of such
>>> classes are expected to end with _Abstract and _Interface, respectively.
>>> This will not work when we migrate to utilize namespaces, for two
>>> reasons.
>>>
>>> First, and most obviously, 'abstract' and 'interface' are reserved PHP
>>> keywords. As such, in situations such as the following:
>>>
>>>     namespace Zend\Controller\Request;
>>>
>>>     class Abstract
>>>     {
>>>     }
>>>
>>>     // or:
>>>
>>>     namespace Zend\Controller\Dispatcher;
>>>
>>>     interface Interface
>>>     {
>>>     }
>>>
>>> we'll run into issues.
>>>
>>> Second, and less obvious, is that perhaps the easiest solution breaks one
>>> of the key principles of namespaces (which are designed to help
>>> encapsulate components). This one's harder to explain, so let's look at
>>> examples. Consider a component such as Zend_Controller_Request. The
>>> simplest solution would be to name the abstract class or interface
>>> Zend\Controller\Request, and then have the various concrete
>>> implementations under that namespace:
>>>
>>>     namespace Zend\Controller;
>>>
>>>     interface Request
>>>     {
>>>     }
>>>
>>>     // and concrete ones:
>>>
>>>     namespace Zend\Controller\Request;
>>>
>>>     class Http
>>>     {
>>>     }
>>>
>>> What's the problem here? The interface is not in the same namespace as
>>> the concrete implementations.
>>>
>>> Potential solutions and recommendation
>>> ======================================
>>> So, how should Zend Framework "solve" these issues? A number of proposals
>>> and recommendations have been floated around, both within ZF circles and
>>> in the greater PHP community.
>>>
>>> Considerations include:
>>>
>>>  * Avoiding the use of PHP reserved keywords (already noted).
>>>  * Avoiding Hungarian Notation (i.e., having the name or a portion of the
>>> name describe its type -- which, to a degree, the current naming
>>> conventions already violate). (See
>>> http://en.wikipedia.org/wiki/Hungarian_Notation, the sections
>>> "Disadvantages of Systems Hungarian" and "Notable Opinions" for some of
>>> the arguments against using Hungarian Notation.)
>>>
>>> Approaches that have been considered include:
>>>
>>>  * Using 'I' to prefix interfaces. This derives from standards in other
>>>    programming languages (.Net and python, in particular). This is just
>>> another form of Hungarian Notation, however.
>>>
>>>  * Using "Interface" or "Abstract" as a class name suffix:
>>> RequestInterface, RequestAbstract. Again, however this is Hungarian
>>> Notation.
>>>
>>>  * Using the term "Base" for abstract classes: BaseRequest, RequestBase,
>>> Base. This is just substituting the word Base for Abstract, however, and
>>> is really not much different than the above.
>>>
>>>  * Use generic, descriptive names indicative of functionality or
>>> behavior. As examples from the SPL, "Countable", "Iterator",
>>> "ArrayObject".
>>>
>>> My recommendation is to use the latter, as it solves all considerations.
>>> It will take more thought when naming, but will ensure that components
>>> can live in a self-contained namespace, do not use reserved keywords, and
>>> avoid Hungarian Notation.
>>>
>>> Plan for implementation
>>> =======================
>>> I recommend that the Coding Standards documentation be updated to reflect
>>> this approach.
>>>
>>> All new components going into 1.8 and onwards should adopt these
>>> standards. In releases 1.9 and forward, we will begin migrating existing
>>> interfaces/abstract classe. First, new classes/interfaces will be created
>>> that follow these conventions and which extend the originals; later, any
>>> type-hinting based on the original class/interface names will be updated
>>> to point to the new names; and finally, in 2.0, we will remove the old
>>> interfaces/abstract classes entirely.
> 

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 11:36:54 -0700
From: Tommy Smith <[email-masked]>
To: Kevin McArthur <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--00c09f923134cf607c047830d36e
Content-Type: text/plain; charset=ISO-8859-1

Great Points Kevin - more like $.04 :-)

I am mostly worried about the changes to the exception interfacing. I am
reviewing everything now but will give a few cents too.

Thanks,
Tommy Smith

On Thu, Nov 12, 2009 at 11:32 AM, Kevin McArthur <[email-masked]> wrote:

> I guess I'll chime in, and stir the pot a bit. All IMHO of course....
>
> The good:
>
> Namespaces, Creation of components for general-purpose cross-functional
> actions, Usage of new language features within plugin architectures,
> Autoload-only.
>
> The Bad:
>
> 1 ) Unified constructor. *All* constructors will (optionally) accept an
> array of options or Zend_Config object as the first argument.
>
> I take exception to this because, well, it's just going to kill performance
> -- and it doesn't follow industry standard techniques for this type of
> thing. This shouldn't be a rule as a ton of classes have no reason to be
> configurable, or make a lot more sense to take real parameters, rather than
> instantiating a new object. Instead, I recommend a *Configurable interface
> * which _may_ mark classes as configurable as needed.
>
> 2 ) Exception interfacing
>
> Why mess with it? All the SPL exceptions descend from Exception and can be
> caught/thrown as any normal exception can be. Exceptions should continue to
> contain the Exception class inheritance hierarchy.
>
> From the markup:
>
>   try {      throw new InvalidArgumentException();
> } catch (\Foo\Bar\Exception $e) {  }
> Can just be:
>
>   try {      throw new InvalidArgumentException();  } catch (Exception $e
> ) {  }
> Without the marker interface. I must be missing something?
>
> 3) Design By Contract
>
> I'm actually a big fan of contract programming, but, a framework must be
> fast -- and optimized. Contract programming is great as part of business
> process management, but it has serious runtime performance implications --
> and worse, increases contribution overhead. Makes testing, acceptance
> testing easier, sure. But this could be realllllly limiting.
>
> 4) Getting rid of singletons.
>
> Why does it make more sense to access the front controller via a registry?
> Surely this can't meet the 80/20 rule? Keep the singletons, they make it
> easier to pick up the framework.
>
> The Ugly:
>
> The proposed changes to the core api (and to a large extent the framework
> additions since 1.0) really add complexity to the framework to the benefit
> of testing and other 'advanced' use. These changes do little, if anything to
> advance three goals I see as core requirements for 2.0:
>
> a) Can a skilled PHP developer read and understand Zend Framework
> application code without more than an hour's primer on ZFW? Could they trace
> execution of the framework logically without a debugger? Jumps like GOTO's,
> fancy routers, registries, helpers, plugins, and DI models all work against
> this goal. Keep it simple.
>
> b) Can a skilled PHP developer contribute a change to the framework easily
> without being involved in the ZFW core politics, contribution processes,
> proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for
> this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to
> reduce the contribution overhead and encourage community participation?
>
> c) Can a ZFW developer create products and services that leverage ZFW in an
> ecosystem of components? Is there a financial incentive for this? Currently,
> there's very little going on in terms of commercialized redistributable
> components -- How will ZFW 2.0 create, and integrate itself into a
> marketplace for ZFW apps, components, and tools? Official ZFW app/component
> store? ZFW cloud services?
>
> The Atrocious:
>
> Still nothing about an upgrading / security patches system. Still no
> components for detecting if an application is vulnerable, notifying system
> admins, or shutting down an installed base of vulnerable apps dependent on
> the framework. If the problems of the other major framework and cms vendors
> continue to be ignored, there will almost certainly be some sort of incident
> that will tarnish the frameworks reputation for security. At some point the
> framework is going to have to take version management more seriously than
> publishing patches to the website (a good first step, but miles away from
> where it needs to be).
>
> --
>
> I'd also add that there's probably an opportunity to look at phar-ization
> within the 2.0 line. Will the new loader support phar'd components, and how
> will that look? Zend_Tool? Configurable site images?
>
> I'm sure theres more, but thats my $0.02 for now
>
> Kevin McArthur
>
>
> Matthew Weier O'Phinney wrote:
>
> Hey, all --
>
> There have been a ton of questions about the ZF 2.0 roadmap, and my
> answer has been consistently, "I'm working on it; I'll have something to
> publish soon."
>
> "Soon" is now:
>
>     http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>
> I'd like you, as contributors, to look over it, and start discussing the
> various ramifications; we can do that either in comments to the pages or
> on this list.
>
> The roadmap is primarily a conceptual one right now, though a
> proof-of-concept has been created for the proposed MVC. I'd like to stay
> fairly high-level for now, and then start getting a flow of proposals
> into the system for specific migration-related tasks.
>
> Thanks everyone who has provided me input over the past many months, and
> let's get started on the next generation of ZF!
>
>
>
>
>

--00c09f923134cf607c047830d36e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Great Points Kevin - more like $.04 :-)</div>
<div>=A0</div>
<div>I am mostly worried about the changes to the exception interfacing. I =
am reviewing everything now but will give a few cents too.</div>
<div>=A0</div>
<div>Thanks,</div>
<div>Tommy Smith</div>
<div><br><br>=A0</div>
<div class=3D"gmail_quote">On Thu, Nov 12, 2009 at 11:32 AM, Kevin McArthur=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">kevin@stormtid=
e.ca</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div bgcolor=3D"#ffffff" text=3D"#000000">I guess I&#39;ll chime in, and st=
ir the pot a bit. All IMHO of course....<br><br>The good:<br><br>Namespaces=
, Creation of components for general-purpose cross-functional actions, Usag=
e of new language features within plugin architectures, Autoload-only.<br>
<br>The Bad:<br><br>1 ) Unified constructor. <b>All</b> constructors will (=
optionally) accept an array of options or Zend_Config object as the first a=
rgument.<br><br>I take exception to this because, well, it&#39;s just going=
 to kill performance -- and it doesn&#39;t follow industry standard techniq=
ues for this type of thing. This shouldn&#39;t be a rule as a ton of classe=
s have no reason to be configurable, or make a lot more sense to take real =
parameters, rather than instantiating a new object. Instead, I recommend a =
<b>Configurable interface</b> which _may_ mark classes as configurable as n=
eeded. <br>
<br>2 ) Exception interfacing<br><br>Why mess with it? All the SPL exceptio=
ns descend from Exception and can be caught/thrown as any normal exception =
can be. Exceptions should continue to contain the Exception class inheritan=
ce hierarchy. <br>
<br>From the markup: <br><br>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"352" heigh=
t=3D"89">
<tbody>
<tr>
<td>try=A0{=A0</td></tr>
<tr>
<td>=A0=A0=A0=A0throw=A0<span>new</span><span>=A0InvalidArgumentException()=
;=A0</span></td></tr>
<tr>
<td>}=A0catch=A0(\Foo\Bar\Exception=A0<span>$e</span><span>)=A0{=A0</span><=
/td></tr>
<tr>
<td>}=A0</td></tr></tbody></table><br>Can just be:<br><br>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<td>try=A0{=A0</td></tr>
<tr>
<td>=A0=A0=A0=A0throw=A0<span>new</span><span>=A0InvalidArgumentException()=
;=A0</span></td></tr>
<tr>
<td>}=A0catch=A0(Exception=A0<span>$e</span><span>)=A0{=A0</span></td></tr>
<tr>
<td>}=A0</td></tr></tbody></table><br>Without the marker interface. I must =
be missing something?<br><br>3) Design By Contract<br><br>I&#39;m actually =
a big fan of contract programming, but, a framework must be fast -- and opt=
imized. Contract programming is great as part of business process managemen=
t, but it has serious runtime performance implications -- and worse, increa=
ses contribution overhead. Makes testing, acceptance testing easier, sure. =
But this could be realllllly limiting.<br>
<br>4) Getting rid of singletons.<br><br>Why does it make more sense to acc=
ess the front controller via a registry? Surely this can&#39;t meet the 80/=
20 rule? Keep the singletons, they make it easier to pick up the framework.=
<br>
<br>The Ugly:<br><br>The proposed changes to the core api (and to a large e=
xtent the framework additions since 1.0) really add complexity to the frame=
work to the benefit of testing and other &#39;advanced&#39; use. These chan=
ges do little, if anything to advance three goals I see as core requirement=
s for 2.0:<br>
<br>a) Can a skilled PHP developer read and understand Zend Framework appli=
cation code without more than an hour&#39;s primer on ZFW? Could they trace=
 execution of the framework logically without a debugger? Jumps like GOTO&#=
39;s, fancy routers, registries, helpers, plugins, and DI models all work a=
gainst this goal. Keep it simple.<br>
<br>b) Can a skilled PHP developer contribute a change to the framework eas=
ily without being involved in the ZFW core politics, contribution processes=
, proposal processes, test writing, doc writing, etc. Currently, ZFW sucks =
for this, but didn&#39;t until after the 1.0 line was out. What will ZFW 2.=
0 do to reduce the contribution overhead and encourage community participat=
ion?<br>
<br>c) Can a ZFW developer create products and services that leverage ZFW i=
n an ecosystem of components? Is there a financial incentive for this? Curr=
ently, there&#39;s very little going on in terms of commercialized redistri=
butable components -- How will ZFW 2.0 create, and integrate itself into a =
marketplace for ZFW apps, components, and tools? Official ZFW app/component=
 store? ZFW cloud services?<br>
<br>The Atrocious:<br><br>Still nothing about an upgrading / security patch=
es system. Still no components for detecting if an application is vulnerabl=
e, notifying system admins, or shutting down an installed base of vulnerabl=
e apps dependent on the framework. If the problems of the other major frame=
work and cms vendors continue to be ignored, there will almost certainly be=
 some sort of incident that will tarnish the frameworks reputation for secu=
rity. At some point the framework is going to have to take version manageme=
nt more seriously than publishing patches to the website (a good first step=
, but miles away from where it needs to be).<br>
<br>--<br><br>I&#39;d also add that there&#39;s probably an opportunity to =
look at phar-ization within the 2.0 line. Will the new loader support phar&=
#39;d components, and how will that look? Zend_Tool? Configurable site imag=
es?<br>
<br>I&#39;m sure theres more, but thats my $0.02 for now<br><br>Kevin McArt=
hur<br><br><br>Matthew Weier O&#39;Phinney wrote:=20
<blockquote type=3D"cite"><pre>Hey, all --

There have been a ton of questions about the ZF 2.0 roadmap, and my
answer has been consistently, &quot;I&#39;m working on it; I&#39;ll have so=
mething to
publish soon.&quot;

&quot;Soon&quot; is now:

    <a href=3D"http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework=
+2.0+Roadmap" target=3D"_blank">http://framework.zend.com/wiki/display/ZFDE=
V2/Zend+Framework+2.0+Roadmap</a>

I&#39;d like you, as contributors, to look over it, and start discussing th=
e
various ramifications; we can do that either in comments to the pages or
on this list.

The roadmap is primarily a conceptual one right now, though a
proof-of-concept has been created for the proposed MVC. I&#39;d like to sta=
y
fairly high-level for now, and then start getting a flow of proposals
into the system for specific migration-related tasks.

Thanks everyone who has provided me input over the past many months, and
let&#39;s get started on the next generation of ZF!

  </pre></blockquote><br></div></blockquote></div><br>

--00c09f923134cf607c047830d36e--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 13 Nov 2009 05:35:45 -0800 (PST)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Kevin McArthur <[email-masked]>
Cc: Zend Framework Contributors <[email-masked]>
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

--0-1254001918-1258119345=:84503
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>I don't have much more to say on this subject, as I think I've made my=0Av=
ision clear. But don't underestimate the power of engaged component=0Aleade=
rs to maintain code =0A>quality without formal process. This current=0Aproc=
ess is of but one way to do things, it hasn't always been this way,=0Aand i=
t doesn't have to be in the future. It can be =0A>re-evaluated,=0Aespeciall=
y in the 2.0 context -- and it's certainly not massively=0Amisleading to sa=
y 1.0 was achieved [or that it was a success] without=0Athe current level o=
f =0A>process involved.=0A=0AAlso don't overestimate the same thing. Compon=
ent leaders have a habit of abandoning their components or having at least =
some weaknesses in their PHP skills - have a look through the issue tracker=
. Without tests and documentation these components would be a lot more diff=
icult to maintain. I'm afraid the days of relying on individuals without so=
me process are long since ended. If it worked well in the real world, then =
why do so many modern libraries and projects rely on test suites? Why did Z=
F ever bother adopting them? Also the proposal process has been a great suc=
cess. It's easy to wag the finger at it when your example is a ZF from 2006=
 comprised of a grand total of 25 odd components compared to whatever it is=
 today, not counting the pages long proposal list.=0A=0AThere is also anoth=
er hidden danger in avoiding a process - missing the point. Would Zend_Feed=
 have ever made it to the finish line if a robust process existed to assess=
 it? That component is not a tenth as useful as it appears on its face. Wou=
ld Zend_Cache have responsibilities mixed between Frontends and Backends in=
stead of consolidated where they really belong (e.g. backend validation for=
 tags and ids occurs in the frontend - for no particular reason). Would Zen=
d_View have ever evolved beyond its original template rendering basics? Pos=
t 1.0 a lot of changes and flaws were very quickly realised once the wider =
PHP community got involved. I've had this debate several times about older =
components - they just do not match up compared to later efforts within the=
 proposal process and the rules it enforces. The few exceptions are the obv=
ious ones - like Zend_Controller which simply has to work perfectly for eve=
ryone.=0A=0AI still think the previous statement was misleading. Anyone can=
 checkout a pre-1.0 release and confirm that it was indeed documented and t=
ested. The old releases should be up on SVN for anyone to look at. In my mi=
nd there is nothing to re-evaluate. Unit testing is an established means of=
 quality control, whatever you might think of the future iterations of that=
 like TDD. The proposal process ensures oversight and quality review. Dropp=
ing both would be a disaster - feedback on proposals and incubator code is =
surprisingly rare outside of this.=0A=0APaddy=0A=0A P=E1draic Brady=0A=0Aht=
tp://blog.astrumfutura.com=0Ahttp://www.survivethedeepend.com=0AOpenID Euro=
pe Foundation Irish Representative=0A=0A=0A=0A=0A=0A_______________________=
_________=0AFrom: Kevin McArthur <[email-masked]>=0ATo: P=E1draic Brady=
 <[email-masked]>=0ACc: Zend Framework Contributors <zf-contributo=
[email-masked]>=0ASent: Fri, November 13, 2009 4:19:22 AM=0ASubject: Re:=
 [zf-contributors] Zend Framework 2.0 Roadmap=0A=0A  =0AThat's a massively =
misleading statement.=0AI don't have much more to say on this subject, as I=
 think I've made my=0Avision clear. But don't underestimate the power of en=
gaged component=0Aleaders to maintain code quality without formal process. =
This current=0Aprocess is of but one way to do things, it hasn't always bee=
n this way,=0Aand it doesn't have to be in the future. It can be re-evaluat=
ed,=0Aespecially in the 2.0 context -- and it's certainly not massively=0Am=
isleading to say 1.0 was achieved [or that it was a success] without=0Athe =
current level of process involved. =0A=0AKevin=0A=0AP=E1draic Brady wrote: =
=0A> =0A>>I=0A>doubt this greatly, ZF to 1.0 was a huge success and had non=
e of this=0A>stuff. A decent vetting by interested coders was all it took t=
o keep=0A>the quality up. Most of that =0A>>>code still comprises the code =
base today,=0A>and it still runs fine. The docs were enough to get interest=
ed=0A>developers over the initial hurdles and the rest came through other=
=0A> =0A>>>sources like blogs, irc, books and sample code. I'm not saying w=
e=0A>go=0A>back to totally untested code or anything like that, I guess I j=
ust see=0A>tests like icing, not an =0A>>>ingredient. If there's tests, gre=
at, if not,=0A>put it on the todo and move on. Instead we've got tests that=
 are at=0A>times even counter-productive as you describe.=0A>=0A>>That's a =
massively misleading statement. I was around pre-1.0 too. The=0A>number of =
components and lines-of-code were a tiny fraction of what=0A>currently exis=
ts, and oddly enough, even at that there were tests and=0A>docs. ZF 0.x wit=
hout those would never have been a success.=0A>Counter-productive tests are=
 a problem - unfortunately overview has=0A>been lacking in the past otherwi=
se they'd have been noticed a lot=0A>sooner. Not to drag this into a presen=
t context - as far as I know=0A>Matthew does review new test suites as part=
 of the review process.=0A>=0A>>>I'd argue that some of those components ar=
e bad in part because of=0A>the=0A>requirement.=0A>=0A>>No, they are bad in=
 spite of the requirement. Tests, docs or nothing at=0A>all - bad code is b=
ad code.=0A>=0A>>>That assumes that a large amount of this work isn't optio=
nal --=0A>when it=0A>is. Those useless tests are there because someone said=
 'must have=0A>tests', many, possibly most, of =0A>>>them are totally unnee=
ded except to up=0A>the code coverage report statistics. A minority of the =
ZFW tests do any=0A>useful testing, and for those, I'm glad there's tests..=
. and I =0A>>>believe=0A>those tests would still be there if they weren't r=
equired to be.=0A>=0A>>I agree the code coverage is sometimes horribly arti=
ficial (personally=0A>I believe a coverage of 60% is acceptable in a lot of=
 cases - I do add=0A>stupid little tests to get to 85% like testing getters=
 (ye gods) or=0A>worse). It's always a complaint when I run code coverage o=
n a shiny new=0A>class and it pops a 55% coverage ;). I know the tests are =
sufficient=0A>but a rule is a rule since, as many tests prove, you really c=
an't trust=0A>all developers. Even I make silly typos at times - even in du=
mb getters=0A>sometimes.=0A>=0A>>Nevertheless, whether the rule adds work o=
r not - the point is that the=0A>work must get done one way or another befo=
re any contribution can be=0A>committed to trunk for the next release.=0A>=
=0A>>>I suspect many wont expect their contributions to be accepted --=0A>a=
nd=0A>instead of capitulating to the requirements, will simply abandon the=
=0A>contribution.=0A>=0A>>Already happening to be honest. Unfortunately, I'=
m unwilling to vet=0A>every single contribution and patch, and so are the c=
ontributors. It's=0A>going to happen a lot.=0A>=0A>>>I think you just made =
my point.=0A>=0A>>Rest of quote? ;) The front controller is just another ob=
ject - how do=0A>you get any other object in whatever class you need it? It=
's not=0A>something magical...=0A>=0A>>>I'd hate to think what it=0A>would =
take to get a class as complicated as=0A>Zend_Pdf_Resource_Image_Tiff commi=
tted today....=0A>=0A>>Probably the same effort - with testing. I'm a fan o=
f TDD though so I'm=0A>totally biased in favour of a test driven approach -=
 I've yet to find=0A>anything too complex to handle with it.=0A>=0A>>>We ag=
ree here. Today is too complicated... Tomorrow will be too=0A>complicated..=
. I was hoping with 2.0 that we would figure out where the=0A>redundancies =
are and nix em >--> i'd start at the actionstack,=0A>but=0A>thats just me. =
Now we're talking FSM's, and DI systems... which is cool=0A>in a compsci ki=
nda way, but fantastically complicated out of >the=0A>box.=0A>>>Is it a SDK=
, a black box, or are we helping people make=0A>applications=0A>they unders=
tand? Whats the implication of blind use of the framework?=0A>=0A>>Same cou=
ld be said of namespaces, closures, all that other compsci ECMA=0A>stuff. D=
I and FSM are not complicated or weird or conceptually=0A>difficult - they =
are merely different. What we have at the moment is=0A>more familiar - and =
a mess. Unfortunately, ZF or not, MVC is always=0A>going to be more complic=
ated as it needs more features. The C part of=0A>MVC remains the most expen=
sive part of ZF performance wise. That won't=0A>change, but maybe the new c=
oncepts will help. They surely will NOT make=0A>it more complex. Whether it=
 simplifies anything - open question to=0A>Matthew? ;)=0A>=0A>>>Theres a re=
ason we write books on this stuff instead of user=0A>docs.....=0A>=0A>>Devs=
 are horrible writers. Unrelated, but true! The manual has become a=0A>mons=
ter read.=0A>=0A>>>"No" is a policy, and its not a very good one.=0A>=0A>>D=
on't get me wrong - I agree it's not the best policy ever, but who's=0A>goi=
ng to contribute the resources to make the policy "yes"? In reality=0A>a "n=
o" is the only possible answer in an open source project with=0A>limited re=
sources.=0A>=0A>>Paddy=0A>=0A>> P=E1draic Brady=0A>=0A>http://blog.astrumfu=
tura.com=0A>http://www.survivethedeepend.com=0A>OpenID Europe Foundation Ir=
ish=0A>Representative=0A> =0A>=0A>=0A>=0A>=0A>=0A__________________________=
______=0AFrom: >Kevin McArthur <[email-masked]>=0A>To: P=E1draic Brady=
=0A><[email-masked]>=0A>Cc: Zend Framework=0A>Contributors <zf-con=
[email-masked]>=0A>Sent: Fri, November=0A>13, 2009 12:58:43 AM=0A=
>Subject: Re:=0A>[zf-contributors] Zend Framework 2.0 Roadmap=0A>=0A>>  =0A=
>P=E1draic Brady wrote:=0A> =0A>=0A>>>>The main wall Kevin just hit is simp=
ly never going away. If it ever=0A>>did, ZF wouldn't be far behind it as a =
untested, undocumented morass of=0A>>code that (allegedly) does stuff. =0A>=
I doubt this greatly, ZF to 1.0 was a huge success and had none of this=0A>=
stuff. A decent vetting by interested coders was all it took to keep=0A>the=
 quality up. Most of that code still comprises the code base today,=0A>and =
it still runs fine. The docs were enough to get interested=0A>developers ov=
er the initial hurdles and the rest came through other=0A>sources like blog=
s, irc, books and sample code. I'm not saying we go=0A>back to totally unte=
sted code or anything like that, I guess I just see=0A>tests like icing, no=
t an ingredient. If there's tests, great, if not,=0A>put it on the todo and=
 move on. Instead we've got tests that are at=0A>times even counter-product=
ive as you describe.=0A>=0A>=0A>We=0A>>need all the "contribution overhead"=
. It is absolutely essential. There=0A>>are components in the ZF which, to =
be generous, are pretty bad in terms=0A>>of testing, documentation and flex=
ibility already - and that's with the=0A>>requirement! I have worse descrip=
tions. Catch me on IRC during a bug=0A>>hunt and I'll share some ;).=0A>>=
=0A>>I'd argue that some of those components are bad in part because of the=
=0A>requirement.=0A>=0A>=0A>>>>The fact is, if you cannot handle the additi=
onal work that underpins,=0A>>supports and ensures ease of maintenance for =
a component - then you are=0A>>begging for a developer to start swearing ov=
er IRC. I had the joy of=0A>>dealing with such a component a few weeks back=
. It took me hours to=0A>>figure out a bug. Why? Because the unit tests DID=
 NOT TEST the=0A>>functionality of the component. I could have deleted ever=
y single test=0A>>with no ill effect - they were all busy with XML parsing =
or something=0A>>(performed by a completely different component with its ow=
n perfectly=0A>>functional unit tests).=0A>>=0A>That sounds about right.=0A=
>=0A>=0A>>>>But worse than all this, is the assumption that lowering the=0A=
>>contribution overhead is a positive thing. It's not - it merely shifts=0A=
>>that work onto someone else. =0A>That assumes that a large amount of this=
 work isn't optional -- when it=0A>is. Those useless tests are there becaus=
e someone said 'must have=0A>tests', many, possibly most, of them are total=
ly unneeded except to up=0A>the code coverage report statistics. A minority=
 of the ZFW tests do any=0A>useful testing, and for those, I'm glad there's=
 tests... and I believe=0A>those tests would still be there if they weren't=
 required to be.=0A>=0A>Someone=0A>>else with precious little time and a ch=
argeout rate to justify work=0A>>with. And surprise - they won't like that =
in the slightest. Sometimes=0A>>you get lucky - I spent about 10 hours of o=
therwise chargeable time in=0A>>September's bug hunt (which I enjoyed a lot=
 by the way) along with=0A>>several evenings but generally everyday work wi=
ll always lean towards=0A>>ignoring contributions where no supporting "cont=
ribution overhead" has=0A>>also been committed. Such contributions/patches/=
whatever can be=0A>>horrible to work on. No tests, poor explanations, lack =
of=0A>>communication, differing assumptions - ugh. If it's not worth=0A>>co=
ntributing in full, don't expect someone else to do it - they=0A>>probably =
won't.=0A>>=0A>I suspect many wont expect their contributions to be accepte=
d -- and=0A>instead of capitulating to the requirements, will simply abando=
n the=0A>contribution.=0A>=0A>=0A>>>>Sorry for the ranty piece - but code d=
oesn't write itself. It is great=0A>>to have a contribution - so long as yo=
u don't pin it all on someone=0A>>else ;).=0A>>=0A>Pin what? When I develop=
ed the Zend PDF image parsers for example, I=0A>didn't write any tests, I d=
id functional testing to the best I=0A>could.... and we went from there. Th=
ose classes exist in the framework=0A>today in basically the same format. T=
hat contribution process was very=0A>different from today, but it worked gr=
eat. I'd hate to think what it=0A>would take to get a class as complicated =
as=0A>Zend_Pdf_Resource_Image_Tiff committed today....=0A>=0A>=0A>>>>Which =
one? Nobody said there would be one front controller.=0A>For 99.999% of use=
s theres only one url, and only a need for one front=0A>controller. =0A>=0A=
>My=0A>>guess, is that it will be accessible from your bootstrap, which is=
=0A>>registered to the front controller, which is registered to...I'm lost=
=0A>>now. =0A>I think you just made my point.=0A>=0A>=0A>>>>Trace what unde=
r the hood?=0A>>Request->Route->Dispatch->Controller->Action <- stick=0A>>p=
lugins in between. It's not rocket science. =0A>Add into that Zend_Applicat=
ion->Zend_Config->Get Bootstrap Name=0A>Setting->do whatever *secret sauce*=
->all before you get to the=0A>mvc dispatch process above. Now, from the co=
de source I looked at=0A>before, its going to require creating some sort of=
 methodinvokers,=0A>event delegates and hooking into a series of events. Tr=
acing back from=0A>output to figure out where something is happening truly =
is a science=0A>these days -- most of the time I end up pecking around in t=
he leaves,=0A>instead of tracing from the trunk. It gets even more complica=
ted when=0A>you start talking partials, helpers( think actionstack ), and t=
he=0A>myriad of other ways to inject into the request cycle. =0A>=0A>If=0A>=
>you doubled the complexity of the implementation today, it would still=0A>=
>quack like the same duck it was yesterday. =0A>We agree here. Today is too=
 complicated... Tomorrow will be too=0A>complicated... I was hoping with 2.=
0 that we would figure out where the=0A>redundancies are and nix em --> i'd=
 start at the actionstack, but=0A>thats just me. Now we're talking FSM's, a=
nd DI systems... which is cool=0A>in a compsci kinda way, but fantastically=
 complicated out of the box.=0A>=0A>>Is it a SDK, a black box, or are we he=
lping people make applications=0A>they understand? Whats the implication of=
 blind use of the framework?=0A>=0A>Right=0A>>now you can still conceptuall=
y grasp MVC and use it, without ever=0A>>reading the source code. In fact, =
right now MVC is a pretty complex=0A>>beast in ZF. It would take a serious =
effort to complicate it further :).=0A>>=0A>Theres a reason we write books =
on this stuff instead of user docs..... =0A>=0A>=0A>>>>>Can a skilled PHP d=
eveloper contribute a change to the framework=0A>>easily=0A>>>>>without bei=
ng involved in the ZFW core politics, contribution=0A>>processes,=0A>>>>>pr=
oposal processes, test writing, doc writing, etc.=0A>>=0A>>>>ZF may be one =
of the few non-political projects around. I've had some=0A>>fun of course b=
utting heads in the past, but the last two years have=0A>>been politics fre=
e. Everything else is answered "no". Who else is going=0A>>to miraculously =
write someone else's tests/docs/proposals? Not me :P.=0A>>=0A>"No" is a pol=
icy, and its not a very good one.=0A>=0A>>$0.02=0A>=0A>>Kevin=0A>=0A
--0-1254001918-1258119345=:84503
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">&gt;I don't have much more to say on this subject, as I think =
I've made my=0Avision clear. But don't underestimate the power of engaged c=
omponent=0Aleaders to maintain code <br>&gt;quality without formal process.=
 This current=0Aprocess is of but one way to do things, it hasn't always be=
en this way,=0Aand it doesn't have to be in the future. It can be <br>&gt;r=
e-evaluated,=0Aespecially in the 2.0 context -- and it's certainly not mass=
ively=0Amisleading to say 1.0 was achieved [or that it was a success] witho=
ut=0Athe current level of <br>&gt;process involved.<br><br>Also don't overe=
stimate the same thing. Component leaders have a habit of abandoning their =
components or having at least some weaknesses in their PHP skills - have a =
look through the issue tracker. Without tests and documentation these compo=
nents would be a lot more difficult to maintain. I'm afraid the days of rel=
ying on individuals without some process are long since ended. If it worked=
 well in the real world, then why do so many modern libraries and projects =
rely on test suites? Why did ZF ever bother adopting them? Also the proposa=
l process has been a great success. It's easy to wag the finger at it when =
your example is a ZF from 2006 comprised of a grand total of 25 odd compone=
nts compared to whatever it is today, not counting the pages long proposal =
list.<br><br>There is also another hidden danger in avoiding a process - mi=
ssing the point. Would Zend_Feed have ever made it to the finish line if
 a robust process existed to assess it? That component is not a tenth as us=
eful as it appears on its face. Would Zend_Cache have responsibilities mixe=
d between Frontends and Backends instead of consolidated where they really =
belong (e.g. backend validation for tags and ids occurs in the frontend - f=
or no particular reason). Would Zend_View have ever evolved beyond its orig=
inal template rendering basics? Post 1.0 a lot of changes and flaws were ve=
ry quickly realised once the wider PHP community got involved. I've had thi=
s debate several times about older components - they just do not match up c=
ompared to later efforts within the proposal process and the rules it enfor=
ces. The few exceptions are the obvious ones - like Zend_Controller which s=
imply has to work perfectly for everyone.<br><br>I still think the previous=
 statement was misleading. Anyone can checkout a pre-1.0 release and confir=
m that it was indeed documented and tested. The old releases should
 be up on SVN for anyone to look at. In my mind there is nothing to re-eval=
uate. Unit testing is an established means of quality control, whatever you=
 might think of the future iterations of that like TDD. The proposal proces=
s ensures oversight and quality review. Dropping both would be a disaster -=
 feedback on proposals and incubator code is surprisingly rare outside of t=
his.<br><br>Paddy<br> <div>&nbsp;</div><span style=3D"color: rgb(0, 0, 191)=
;"><font style=3D"font-family: times new roman,new york,times,serif;" size=
=3D"3"><span style=3D"font-weight: bold;">P=E1draic Brady<br><br></span></f=
ont><span style=3D"font-style: italic;"><font style=3D"font-family: times n=
ew roman,new york,times,serif;" size=3D"3"><a rel=3D"nofollow" target=3D"_b=
lank" href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a=
><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedee=
pend.com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" targe=
t=3D"_blank"
 href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish Repres=
entative</a><br></font></span></span><div><br></div><div style=3D"font-fami=
ly: times new roman,new york,times,serif; font-size: 12pt;"><br><div style=
=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;"><f=
ont face=3D"Tahoma" size=3D"2"><hr size=3D"1"><b><span style=3D"font-weight=
: bold;">From:</span></b> Kevin McArthur &lt;[email-masked]&gt;<br><b><=
span style=3D"font-weight: bold;">To:</span></b> P=E1draic Brady &lt;padrai=
[email-masked]&gt;<br><b><span style=3D"font-weight: bold;">Cc:</span></=
b> Zend Framework Contributors &lt;[email-masked]&gt;<br><b=
><span style=3D"font-weight: bold;">Sent:</span></b> Fri, November 13, 2009=
 4:19:22 AM<br><b><span style=3D"font-weight: bold;">Subject:</span></b> Re=
: [zf-contributors] Zend Framework 2.0 Roadmap<br></font><br>=0A<meta http-=
equiv=3D"x-dns-prefetch-control" content=3D"off">=0A=0A=0A  =0A  <title></t=
itle>=0A=0A<blockquote type=3D"cite">That's a massively misleading statemen=
t.</blockquote>=0A<br>=0AI don't have much more to say on this subject, as =
I think I've made my=0Avision clear. But don't underestimate the power of e=
ngaged component=0Aleaders to maintain code quality without formal process.=
 This current=0Aprocess is of but one way to do things, it hasn't always be=
en this way,=0Aand it doesn't have to be in the future. It can be re-evalua=
ted,=0Aespecially in the 2.0 context -- and it's certainly not massively=0A=
misleading to say 1.0 was achieved [or that it was a success] without=0Athe=
 current level of process involved. <br>=0A<br>=0AKevin<br>=0A<br>=0AP=E1dr=
aic Brady wrote:=0A<blockquote type=3D"cite">=0A  =0A  <div style=3D"font-f=
amily: times new roman,new york,times,serif; font-size: 12pt;">&gt;I=0Adoub=
t this greatly, ZF to 1.0 was a huge success and had none of this=0Astuff. =
A decent vetting by interested coders was all it took to keep=0Athe quality=
 up. Most of that <br>=0A&gt;code still comprises the code base today,=0Aan=
d it still runs fine. The docs were enough to get interested=0Adevelopers o=
ver the initial hurdles and the rest came through other=0A  <br>=0A&gt;sour=
ces like blogs, irc, books and sample code. I'm not saying we=0Ago=0Aback t=
o totally untested code or anything like that, I guess I just see=0Atests l=
ike icing, not an <br>=0A&gt;ingredient. If there's tests, great, if not,=
=0Aput it on the todo and move on. Instead we've got tests that are at=0Ati=
mes even counter-productive as you describe.<br>=0A  <br>=0AThat's a massiv=
ely misleading statement. I was around pre-1.0 too. The=0Anumber of compone=
nts and lines-of-code were a tiny fraction of what=0Acurrently exists, and =
oddly enough, even at that there were tests and=0Adocs. ZF 0.x without thos=
e would never have been a success.=0ACounter-productive tests are a problem=
 - unfortunately overview has=0Abeen lacking in the past otherwise they'd h=
ave been noticed a lot=0Asooner. Not to drag this into a present context - =
as far as I know=0AMatthew does review new test suites as part of the revie=
w process.<br>=0A  <br>=0A&gt;I'd argue that some of those components are b=
ad in part because of=0Athe=0Arequirement.<br>=0A  <br>=0ANo, they are bad =
in spite of the requirement. Tests, docs or nothing at=0Aall - bad code is =
bad code.<br>=0A  <br>=0A&gt;That assumes that a large amount of this work =
isn't optional --=0Awhen it=0Ais. Those useless tests are there because som=
eone said 'must have=0Atests', many, possibly most, of <br>=0A&gt;them are =
totally unneeded except to up=0Athe code coverage report statistics. A mino=
rity of the ZFW tests do any=0Auseful testing, and for those, I'm glad ther=
e's tests... and I <br>=0A&gt;believe=0Athose tests would still be there if=
 they weren't required to be.<br>=0A  <br>=0AI agree the code coverage is s=
ometimes horribly artificial (personally=0AI believe a coverage of 60% is a=
cceptable in a lot of cases - I do add=0Astupid little tests to get to 85% =
like testing getters (ye gods) or=0Aworse). It's always a complaint when I =
run code coverage on a shiny new=0Aclass and it pops a 55% coverage ;). I k=
now the tests are sufficient=0Abut a rule is a rule since, as many tests pr=
ove, you really can't trust=0Aall developers. Even I make silly typos at ti=
mes - even in dumb getters=0Asometimes.<br>=0A  <br>=0ANevertheless, whethe=
r the rule adds work or not - the point is that the=0Awork must get done on=
e way or another before any contribution can be=0Acommitted to trunk for th=
e next release.<br>=0A  <br>=0A&gt;I suspect many wont expect their contrib=
utions to be accepted --=0Aand=0Ainstead of capitulating to the requirement=
s, will simply abandon the=0Acontribution.<br>=0A  <br>=0AAlready happening=
 to be honest. Unfortunately, I'm unwilling to vet=0Aevery single contribut=
ion and patch, and so are the contributors. It's=0Agoing to happen a lot.<b=
r>=0A  <br>=0A&gt;I think you just made my point.<br>=0A  <br>=0ARest of qu=
ote? ;) The front controller is just another object - how do=0Ayou get any =
other object in whatever class you need it? It's not=0Asomething magical...=
<br>=0A  <br>=0A&gt;I'd hate to think what it=0Awould take to get a class a=
s complicated as=0AZend_Pdf_Resource_Image_Tiff committed today....<br>=0A =
 <br>=0AProbably the same effort - with testing. I'm a fan of TDD though so=
 I'm=0Atotally biased in favour of a test driven approach - I've yet to fin=
d=0Aanything too complex to handle with it.<br>=0A  <br>=0A&gt;We agree her=
e. Today is too complicated... Tomorrow will be too=0Acomplicated... I was =
hoping with 2.0 that we would figure out where the=0Aredundancies are and n=
ix em &gt;--&gt; i'd start at the actionstack,=0Abut=0Athats just me. Now w=
e're talking FSM's, and DI systems... which is cool=0Ain a compsci kinda wa=
y, but fantastically complicated out of &gt;the=0Abox.<br>=0A&gt;Is it a SD=
K, a black box, or are we helping people make=0Aapplications=0Athey underst=
and? Whats the implication of blind use of the framework?<br>=0A  <br>=0ASa=
me could be said of namespaces, closures, all that other compsci ECMA=0Astu=
ff. DI and FSM are not complicated or weird or conceptually=0Adifficult - t=
hey are merely different. What we have at the moment is=0Amore familiar - a=
nd a mess. Unfortunately, ZF or not, MVC is always=0Agoing to be more compl=
icated as it needs more features. The C part of=0AMVC remains the most expe=
nsive part of ZF performance wise. That won't=0Achange, but maybe the new c=
oncepts will help. They surely will NOT make=0Ait more complex. Whether it =
simplifies anything - open question to=0AMatthew? ;)<br>=0A  <br>=0A&gt;The=
res a reason we write books on this stuff instead of user=0Adocs.....<br>=
=0A  <br>=0ADevs are horrible writers. Unrelated, but true! The manual has =
become a=0Amonster read.<br>=0A  <br>=0A&gt;"No" is a policy, and its not a=
 very good one.<br>=0A  <br>=0ADon't get me wrong - I agree it's not the be=
st policy ever, but who's=0Agoing to contribute the resources to make the p=
olicy "yes"? In reality=0Aa "no" is the only possible answer in an open sou=
rce project with=0Alimited resources.<br>=0A  <br>=0APaddy<br>=0A  <br>=0A&=
nbsp;<span style=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: tim=
es new roman,new york,times,serif;" size=3D"3"><span style=3D"font-weight: =
bold;">P=E1draic Brady<br>=0A  <br>=0A  </span></font><span style=3D"font-s=
tyle: italic;"><font style=3D"font-family: times new roman,new york,times,s=
erif;" size=3D"3"><span><a target=3D"_blank" href=3D"http://blog.astrumfutu=
ra.com">http://blog.astrumfutura.com</a></span><br><span>=0A  <a target=3D"=
_blank" href=3D"http://www.survivethedeepend.com">http://www.survivethedeep=
end.com</a></span><br>=0A  <a rel=3D"nofollow" target=3D"_blank" href=3D"ht=
tp://www.openideurope.eu/">OpenID Europe Foundation Irish=0ARepresentative<=
/a><br>=0A  </font></span></span>=0A  <div><br>=0A  </div>=0A  <div style=
=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;"><b=
r>=0A  <div style=3D"font-family: times new roman,new york,times,serif; fon=
t-size: 12pt;"><font face=3D"Tahoma" size=3D"2">=0A  <hr size=3D"1"><b><spa=
n style=3D"font-weight: bold;">From:</span></b>=0AKevin McArthur <a rel=3D"=
nofollow" class=3D"moz-txt-link-rfc2396E" ymailto=3D"mailto:kevin@stormtide=
.ca" target=3D"_blank" href=3D"mailto:[email-masked]">&lt;kevin@stormti=
de.ca&gt;</a><br>=0A  <b><span style=3D"font-weight: bold;">To:</span></b> =
P=E1draic Brady=0A<a rel=3D"nofollow" class=3D"moz-txt-link-rfc2396E" ymail=
to=3D"mailto:[email-masked]" target=3D"_blank" href=3D"mailto:padr=
[email-masked]">&lt;[email-masked]&gt;</a><br>=0A  <b><span s=
tyle=3D"font-weight: bold;">Cc:</span></b> Zend Framework=0AContributors <a=
 rel=3D"nofollow" class=3D"moz-txt-link-rfc2396E" ymailto=3D"mailto:zf-cont=
[email-masked]" target=3D"_blank" href=3D"mailto:zf-contributors@l=
ists.zend.com">&lt;[email-masked]&gt;</a><br>=0A  <b><span =
style=3D"font-weight: bold;">Sent:</span></b> Fri, November=0A13, 2009 12:5=
8:43 AM<br>=0A  <b><span style=3D"font-weight: bold;">Subject:</span></b> R=
e:=0A[zf-contributors] Zend Framework 2.0 Roadmap<br>=0A  </font><br>=0A  =
=0AP=E1draic Brady wrote:=0A  <blockquote type=3D"cite">=0A    <div style=
=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;"><b=
r>=0AThe main wall Kevin just hit is simply never going away. If it ever=0A=
did, ZF wouldn't be far behind it as a untested, undocumented morass of=0Ac=
ode that (allegedly) does stuff. </div>=0A  </blockquote>=0AI doubt this gr=
eatly, ZF to 1.0 was a huge success and had none of this=0Astuff. A decent =
vetting by interested coders was all it took to keep=0Athe quality up. Most=
 of that code still comprises the code base today,=0Aand it still runs fine=
. The docs were enough to get interested=0Adevelopers over the initial hurd=
les and the rest came through other=0Asources like blogs, irc, books and sa=
mple code. I'm not saying we go=0Aback to totally untested code or anything=
 like that, I guess I just see=0Atests like icing, not an ingredient. If th=
ere's tests, great, if not,=0Aput it on the todo and move on. Instead we've=
 got tests that are at=0Atimes even counter-productive as you describe.<br>=
=0A  <br>=0A  <blockquote type=3D"cite">=0A    <div style=3D"font-family: t=
imes new roman,new york,times,serif; font-size: 12pt;">We=0Aneed all the "c=
ontribution overhead". It is absolutely essential. There=0Aare components i=
n the ZF which, to be generous, are pretty bad in terms=0Aof testing, docum=
entation and flexibility already - and that's with the=0Arequirement! I hav=
e worse descriptions. Catch me on IRC during a bug=0Ahunt and I'll share so=
me ;).<br>=0A    </div>=0A  </blockquote>=0A  <br>=0AI'd argue that some of=
 those components are bad in part because of the=0Arequirement.<br>=0A  <bl=
ockquote type=3D"cite">=0A    <div style=3D"font-family: times new roman,ne=
w york,times,serif; font-size: 12pt;"><br>=0AThe fact is, if you cannot han=
dle the additional work that underpins,=0Asupports and ensures ease of main=
tenance for a component - then you are=0Abegging for a developer to start s=
wearing over IRC. I had the joy of=0Adealing with such a component a few we=
eks back. It took me hours to=0Afigure out a bug. Why? Because the unit tes=
ts DID NOT TEST the=0Afunctionality of the component. I could have deleted =
every single test=0Awith no ill effect - they were all busy with XML parsin=
g or something=0A(performed by a completely different component with its ow=
n perfectly=0Afunctional unit tests).<br>=0A    </div>=0A  </blockquote>=0A=
That sounds about right.<br>=0A  <blockquote type=3D"cite">=0A    <div styl=
e=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;"><=
br>=0ABut worse than all this, is the assumption that lowering the=0Acontri=
bution overhead is a positive thing. It's not - it merely shifts=0Athat wor=
k onto someone else. </div>=0A  </blockquote>=0AThat assumes that a large a=
mount of this work isn't optional -- when it=0Ais. Those useless tests are =
there because someone said 'must have=0Atests', many, possibly most, of the=
m are totally unneeded except to up=0Athe code coverage report statistics. =
A minority of the ZFW tests do any=0Auseful testing, and for those, I'm gla=
d there's tests... and I believe=0Athose tests would still be there if they=
 weren't required to be.<br>=0A  <blockquote type=3D"cite">=0A    <div styl=
e=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;">S=
omeone=0Aelse with precious little time and a chargeout rate to justify wor=
k=0Awith. And surprise - they won't like that in the slightest. Sometimes=
=0Ayou get lucky - I spent about 10 hours of otherwise chargeable time in=
=0ASeptember's bug hunt (which I enjoyed a lot by the way) along with=0Asev=
eral evenings but generally everyday work will always lean towards=0Aignori=
ng contributions where no supporting "contribution overhead" has=0Aalso bee=
n committed. Such contributions/patches/whatever can be=0Ahorrible to work =
on. No tests, poor explanations, lack of=0Acommunication, differing assumpt=
ions - ugh. If it's not worth=0Acontributing in full, don't expect someone =
else to do it - they=0Aprobably won't.<br>=0A    </div>=0A  </blockquote>=
=0AI suspect many wont expect their contributions to be accepted -- and=0Ai=
nstead of capitulating to the requirements, will simply abandon the=0Acontr=
ibution.<br>=0A  <blockquote type=3D"cite">=0A    <div style=3D"font-family=
: times new roman,new york,times,serif; font-size: 12pt;"><br>=0ASorry for =
the ranty piece - but code doesn't write itself. It is great=0Ato have a co=
ntribution - so long as you don't pin it all on someone=0Aelse ;).<br>=0A  =
  </div>=0A  </blockquote>=0APin what? When I developed the Zend PDF image =
parsers for example, I=0Adidn't write any tests, I did functional testing t=
o the best I=0Acould.... and we went from there. Those classes exist in the=
 framework=0Atoday in basically the same format. That contribution process =
was very=0Adifferent from today, but it worked great. I'd hate to think wha=
t it=0Awould take to get a class as complicated as=0AZend_Pdf_Resource_Imag=
e_Tiff committed today....<br>=0A  <blockquote type=3D"cite">=0A    <div st=
yle=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;"=
><br>=0AWhich one? Nobody said there would be one front controller.</div>=
=0A  </blockquote>=0AFor 99.999% of uses theres only one url, and only a ne=
ed for one front=0Acontroller. <br>=0A  <blockquote type=3D"cite">=0A    <d=
iv style=3D"font-family: times new roman,new york,times,serif; font-size: 1=
2pt;">My=0Aguess, is that it will be accessible from your bootstrap, which =
is=0Aregistered to the front controller, which is registered to...I'm lost=
=0Anow. </div>=0A  </blockquote>=0AI think you just made my point.<br>=0A  =
<blockquote type=3D"cite">=0A    <div style=3D"font-family: times new roman=
,new york,times,serif; font-size: 12pt;"><br>=0ATrace what under the hood?=
=0ARequest-&gt;Route-&gt;Dispatch-&gt;Controller-&gt;Action &lt;- stick=0Ap=
lugins in between. It's not rocket science. </div>=0A  </blockquote>=0AAdd =
into that Zend_Application-&gt;Zend_Config-&gt;Get Bootstrap Name=0ASetting=
-&gt;do whatever *secret sauce*-&gt;all before you get to the=0Amvc dispatc=
h process above. Now, from the code source I looked at=0Abefore, its going =
to require creating some sort of methodinvokers,=0Aevent delegates and hook=
ing into a series of events. Tracing back from=0Aoutput to figure out where=
 something is happening truly is a science=0Athese days -- most of the time=
 I end up pecking around in the leaves,=0Ainstead of tracing from the trunk=
. It gets even more complicated when=0Ayou start talking partials, helpers(=
 think actionstack ), and the=0Amyriad of other ways to inject into the req=
uest cycle. <br>=0A  <blockquote type=3D"cite">=0A    <div style=3D"font-fa=
mily: times new roman,new york,times,serif; font-size: 12pt;">If=0Ayou doub=
led the complexity of the implementation today, it would still=0Aquack like=
 the same duck it was yesterday. </div>=0A  </blockquote>=0AWe agree here. =
Today is too complicated... Tomorrow will be too=0Acomplicated... I was hop=
ing with 2.0 that we would figure out where the=0Aredundancies are and nix =
em --&gt; i'd start at the actionstack, but=0Athats just me. Now we're talk=
ing FSM's, and DI systems... which is cool=0Ain a compsci kinda way, but fa=
ntastically complicated out of the box.<br>=0A  <br>=0AIs it a SDK, a black=
 box, or are we helping people make applications=0Athey understand? Whats t=
he implication of blind use of the framework?<br>=0A  <blockquote type=3D"c=
ite">=0A    <div style=3D"font-family: times new roman,new york,times,serif=
; font-size: 12pt;">Right=0Anow you can still conceptually grasp MVC and us=
e it, without ever=0Areading the source code. In fact, right now MVC is a p=
retty complex=0Abeast in ZF. It would take a serious effort to complicate i=
t further :).<br>=0A    </div>=0A  </blockquote>=0ATheres a reason we write=
 books on this stuff instead of user docs..... <br>=0A  <blockquote type=3D=
"cite">=0A    <div style=3D"font-family: times new roman,new york,times,ser=
if; font-size: 12pt;"><br>=0A&gt;Can a skilled PHP developer contribute a c=
hange to the framework=0Aeasily<br>=0A&gt;without being involved in the ZFW=
 core politics, contribution=0Aprocesses,<br>=0A&gt;proposal processes, tes=
t writing, doc writing, etc.<br>=0A    <br>=0AZF may be one of the few non-=
political projects around. I've had some=0Afun of course butting heads in t=
he past, but the last two years have=0Abeen politics free. Everything else =
is answered "no". Who else is going=0Ato miraculously write someone else's =
tests/docs/proposals? Not me :P.<br>=0A    </div>=0A  </blockquote>=0A"No" =
is a policy, and its not a very good one.<br>=0A  <br>=0A$0.02<br>=0A  <br>=
=0AKevin<br>=0A  =0A  </div>=0A  </div>=0A=0A  </div>=0A</blockquote>=0A<br=
>=0A<meta http-equiv=3D"x-dns-prefetch-control" content=3D"on"></div></div>=
=0A<!-- cg2.c902.mail.ac4.yahoo.com compressed/chunked Fri Nov 13 03:38:11 =
PST 2009 -->=0A</div></body></html>
--0-1254001918-1258119345=:84503--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 20 Feb 2010 20:55:47 +0100
From: Maghiel Dijksman <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] New Proposal: Change of
	ZendX_JQuery_View_Helper_AjaxLink
	(ZendX_JQuery_View_Helper_AjaxRequest etc)

Hello all,

I'm not getting a reply from Benjamin.

What would be proper action; submit an issue to the issue tracker with 
patches, or commit a new proposal?

Regards,
Maghiel

On 7-2-2010 1:52, Maghiel Dijksman wrote:
> Hello Dolf,
>
> The wiki says: "Those considering submitting a proposal are strongly 
> encouraged to present and discuss their idea on the mailing list 
> before creating the proposal document so that it may be initially 
> vetted by- and improved upon with the help of- the most active members 
> of our community."
> That's why I've send this mail around.
>
> It's definately just a minor change(but useful imho, and I want to 
> start of a bit small to get to know my way around here.)
> but I wasn't sure if this had to go in proposals or not. Just eager to 
> contribute something. I will contact Benjamin first!
>
> Thanks for your answer!
>
> Regards,
> Maghiel
>
>
>
> On 7-2-2010 1:22, Dolf Schimmel wrote:
>> Hey Maghiel,
>>
>> Proposals should be put in the wiki, and should then be announced on
>> the mailing lists (oh, and please do so in #zftalk.dev on freenode,
>> irc) as all described here:
>> http://framework.zend.com/wiki/display/ZFPROP/Proposal+Process
>>
>> As to what the actual proposal is concerned, imho (note: that's just
>> an opinion) this is just a (slight) change in existing
>> behavior/functionality. Therefore I think you better contact the
>> maintainer of ZendX_Jquery (Benjamin Eberlei, aka Beberlei) for this
>> rather than actually putting an entire proposal out - which is usually
>> done for entire components.
>>
>> Regards,
>>
>> Dolf
>> -- Freeaqingme
>>
>> On Sun, Feb 7, 2010 at 12:49 AM, Maghiel Dijksman<[email-masked]>  
>> wrote:
>>> This is my first idea for a proposal that i submit to the mailing 
>>> list, so
>>> pardon me if i take the wrong steps
>>> (and please correct me ;))
>>>
>>> I think it's a bit, ehm, weird that theres Zend_View_Helper_Url, which
>>> returns a url as string,
>>> and ZendX_JQuery_View_Helper_AjaxLink, which can only return a 
>>> complete HTML
>>> hyperlink (although
>>> the naming DOES cleary state what you get).
>>>
>>> But what if a user wants to only have the JQuery function declaration
>>> returned as string, by example
>>> for usage in a onclick attribute of an element?
>>> ZendX_JQuery_View_Helper_AjaxLink has the inline option,
>>> but this makes the helper return a hyperlink with the function 
>>> declared in
>>> the onclick attribute of that hyperlink.
>>> So the only option the user has in my use case is to either create 
>>> his/her
>>> own view helper, or declare the function
>>> him/herself in the view.
>>>
>>> So I thought the following might be useful:
>>> Drop: ZendX_JQuery_View_Helper_AjaxLink
>>> Add:
>>> ZendX_JQuery_View_Helper_AjaxRequest_Abstract
>>> ZendX_JQuery_View_Helper_AjaxRequest (probably needs a better name :p)
>>> ZendX_JQuery_View_Helper_AjaxRequest_Link
>>>
>>> Something like:
>>> abstract class ZendX_JQuery_View_Helper_AjaxRequest_Abstract
>>>     extends Zend_View_Helper_HtmlElement
>>> {
>>>     protected $_jQuery;
>>>     protected $_jQHandler;
>>>
>>>     /**
>>>      * Set JQuery view helper and JQuery Handler
>>>      */
>>>     public function __construct()
>>>     {
>>>         $this->_jQuery = $this->view->jQuery();
>>>         $this->_jQuery->enable();
>>>
>>>         $this->_jQHandler = true ===
>>> ZendX_JQuery_View_Helper_JQuery::getNoConflictMode() ? '$j' : '$';
>>>     }
>>>
>>>     /**
>>>      * Get js string for the given effect (example: $this->_jQHandler .
>>> '(this).fadeOut();')
>>>      *
>>>      * @return string
>>>      */
>>>     protected function getEffect()
>>>     {
>>>     }
>>>
>>> }
>>>
>>> class ZendX_JQuery_View_Helper_AjaxRequest extends
>>> ZendX_JQuery_View_Helper_AjaxRequest_Abstract
>>> {
>>>
>>>     /**
>>>      * Create inline JQuery function that enables ajax-based 
>>> requests and
>>> handling of the response.
>>>      * @see ZendX_JQuery_View_Helper_AjaxLink
>>>      *
>>>      * @param string url
>>>      * @param array $options (optional)
>>>      * @param array $params (optional)
>>>      * @return string
>>>      */
>>>     public function ajaxRequest($url, array $options = null, array 
>>> $params =
>>> null)
>>>     {
>>>     }
>>>
>>>     /**
>>>      * Determine which request method (GET or POST) should be used.
>>>      *
>>>      * Normally the request method is determined implicitly by the 
>>> rule,
>>>      * if addiotional params are sent, POST, if not GET. You can 
>>> overwrite
>>>      * this behaviiour by implicitly setting $options['method'] = 
>>> "POST|GET";
>>>      *
>>>      * @param  Array   $options
>>>      * @param  Boolean $hasParams
>>>      * @return String
>>>      */
>>>     protected function _determineRequestHandler($options, $hasParams)
>>>     {
>>>     }
>>>
>>> }
>>>
>>> class ZendX_JQuery_View_Helper_AjaxRequest_Link extends
>>> ZendX_JQuery_View_Helper_AjaxRequest
>>> {
>>>
>>>     private static $currentLinkCallbackId = 1;
>>>
>>>     public function ajaxLink($label, $url, $options=null, $params=null)
>>>     {
>>>         $js = parent::ajaxRequest($url, $options, $params);
>>>
>>>         // Etc
>>>
>>>         return $js;
>>>     }
>>>
>>>     private function _getAttributes(array $attrib = array())
>>>     {
>>>     }
>>>
>>> }
>>>
>>>
>>>
>>> What do you guys think?
>>> If i'm coming up with a stupid proposal please flame me (although 
>>> useful
>>> critics are more welcome ;))
>>>
>>> Regards,
>>> Maghiel
>>>
>>
>
>
>

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 17 Nov 2009 13:06:22 -0800
From: Kevin McArthur <[email-masked]>
To: [email-masked]
Subject: Re: [zf-contributors] New Sections for Zend Framework 2.0 Roadmap

This is a multi-part message in MIME format.
--------------070700000502080501030903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

*Sorry about the formatting, my power went out as writing this and had 
to save to a textfile before my ups died!... Fun days on Vancouver 
Island BC... *

<snip>
 >
 > Are we talking about the same thing?
Maybe not... When I use PRG I mean it to be any page the user _sees_ is 
the result of a get action --- always --- Errors, Success, Username 
taken... etc. This is essential in avoiding the 'this page has expired', 
repost/cancel dialog. In a modern environment with sessions as 
accessible as they are now, there's really no reason not to do this.
 > We're either not, or you're using
 > Zend_Form and Zend_Controller very differently from anyone I've ever
 > talked to.

There's lots of guys like me ;) [and a few more who read my book , and 
do it the way I describe in there, which is PRG but without the form 
data state save]

[code for (listing 15-16)]

public function addAction() {
  $request = $this->getRequest();

  //Determine if processing a post request
  if($request->isPost()) {

    //Filter tags from the name field
    $filters = array(
      'name' => 'StripTags'
    );

    //Validate name is not less than 1 character and not more than 64
    $validation = array(
      'name' => array (
        array('StringLength', 1, 64)
      )
    );

    //Initialize Zend_Filter_Input (ZFI) passing it the entire getPost() 
array
    $zfi = new Zend_Filter_Input($filters, $validation, 
$request->getPost());

    //If the validators passed this will be true
    if ($zfi->isValid()) {

      //Fetch the data from zfi directly and create an array for Zend_Db
      $clean = array();
      $clean['name'] = $zfi->name;

      //Create an instance of the customers table and insert the $clean row
      $customers = new Customers();
      $customers->insert($clean);

      //Redirect to the display page after adding
      $this->getHelper('redirector')->goto('index');

    } else {

      //The form didn't validate, get the messages from ZFI
      foreach($zfi->getMessages() as $field=>$messages) {

        //Put each ZFI message into the FlashMessenger so it shows on 
the form
        foreach($messages as $message) {
          $this->getHelper('FlashMessenger')
               ->addMessage($field . ' : '. $message);
        }
      }

      //Redirect back to the input form, but with messages
      $this->getHelper('redirector')->goto('add');
    }
  }

  //Not a post request, check for flash messages and expose to the view
  if($this->getHelper('FlashMessenger')->hasMessages()) {
    $this->view->messages = 
$this->getHelper('FlashMessenger')->getMessages();
  }

  //The view renderer will now automatically render the add.phtml template

}

[/code]

So thats a basic error-state prg... but normally I also add in a 
Zend_Session object around where I enqueue the error messages into the 
flashmessenger. On the display side, I manually pull from the session 
and repopulate the form saved values. That looks like:

[code, pseudo]

public function addAction() {
  $request = $this->getRequest();

  //Determine if processing a post request
  if($request->isPost()) {

    //Filter tags from the name field
    $filters = array(
      'name' => 'StripTags'
    );

    //Validate name is not less than 1 character and not more than 64
    $validation = array(
      'name' => array (
        array('StringLength', 1, 64)
      )
    );

    //Initialize Zend_Filter_Input (ZFI) passing it the entire getPost() 
array
    $zfi = new Zend_Filter_Input($filters, $validation, 
$request->getPost());

    //If the validators passed this will be true
    if ($zfi->isValid()) {

      //Fetch the data from zfi directly and create an array for Zend_Db
      $clean = array();
      $clean['name'] = $zfi->name;

      //Create an instance of the customers table and insert the $clean row
      $customers = new Customers();
      $customers->insert($clean);

      //Redirect to the display page after adding
      $this->getHelper('redirector')->goto('index');

    } else {

      //The form didn't validate, get the messages from ZFI
      foreach($zfi->getMessages() as $field=>$messages) {

        //Put each ZFI message into the FlashMessenger so it shows on 
the form
        foreach($messages as $message) {
          $this->getHelper('FlashMessenger')
               ->addMessage($field . ' : '. $message);
        }
      }
       $session = new Zend_Session_Namespace('nameofform');
       $session->nameField = $zfi->name;

      //Redirect back to the input form, but with messages
      $this->getHelper('redirector')->goto('add');
    }
  }

  //Not a post request, check for flash messages and expose to the view
  if($this->getHelper('FlashMessenger')->hasMessages()) {
    $this->view->messages = 
$this->getHelper('FlashMessenger')->getMessages();
  }

  $session = new Zend_Session_Namespace('nameofform');
  $this->view->nameField = $session->nameField;

  //The view renderer will now automatically render the add.phtml template

}

[/code]

... add in a big form (this is for one field)... and this gets rather 
terse to do for each form...

<snip>

 >
 >
 > The above does most aspects of PRG, and all those steps would be
 > necessary regardless of how Zend_Form works; you're marshalling input,
 > and deciding how to respond.

I think the most important part of PRG is in-fact on failure. If you're 
just going forward, you're not going to get to that expired state 
anyway. With this approach I've been able to make multi-stage shopping 
cart checkouts that can gracefully handle the back/forward button being 
clicked, and portions of a multi-stage form resubmitted, without 
breaking everything or confusing the user with state expired pages.

 >
 > If you're wanting redirection on failure, I'm not entirely sure I see
 > the point; you'd get the same exact result as before. Most literature on
 > PRG actually indicates that the Redirect/Get are only really necessary
 > for _successful_ actions, not those resulting in validation errors.

Its important for an error state as when confronted with an error, users 
often hit the back button, and then state gets really messed up if they 
do or dont repost... and such. The flow charts can get really nasty if 
you don't follow the 'display only as a result of get' rule.

 >
 > The work done for multi-page form support would make PRG for error cases
 > trivially possible, however, and maintains the loose coupling between
 > Zend_Form and the other MVC components by pushing this interaction into
 > an action helper. This is the preferred approach, as keeping the
 > components isolated makes them easier to test and repurpose.  (As for
 > the multi-page form support, unfortunately, the contributor has had no
 > time to complete that component. If somebody is willing to step up and
 > work on it, I'm sure the help would be welcome.)

I've been tracking this, hoping it would be the solution to PRG. I 
hadn't realized it had died on the vine. I'm happy to work on the 
architecture with you guys if there's interest.

 >
 > Forms do have use-cases outside of HTTP -- I personally want to work up
 > a version that utilizes ncurses and/or readline so as to create
 > CLI-based forms -- where PRG would have absolutely no meaning
 > whatsoever.

That would be cool... not sure what the ecosystem looks like when we 
start talking about forms processing in abstract terms tho. I've wanted 
to get some forms stuff setup for put and delete requests too, but those 
have their own caveats too.

 >
 >> Using PRG _should_ be as easy as not using it, and the Zend_Session/
 >> FlashMessenger/SaveState stuff should all be handled in the core 
classes as its
 >> really laborious to do it in the controllers, and for the most part, 
totally
 >> redundant and unnecessary.
 >
 > Regarding your comments on sessions... those *are* core classes, can be
 > used with or without the MVC, and are as simple as instantiating and
 > using objects. I'm really needing some examples here if I'm going to
 > understand what you're getting at.
 >

It's not complicated at current, but its terse and undocumented. You can 
see the examples above, but it really comes down to the state-saving, 
and integration with all the objects that are in play. It would also 
solve your multi-page forms requirement as a by-product really.

 >
 > See my above notes. If you apply the RG portion of PRG to simply the
 > success responses, then it's already easily and readily supported. If
 > you want to apply it to *all* form responses, then we need some more
 > infrastructure -- but that is not difficult to achieve. We simply need a
 > proposal (BTW, there is no PRG proposal, just the multi-page form
 > proposal).

Should be applied to all IMHO. Its a rule in my shop that all pages a 
user sees is a result of a get request -- never post.

 >
 >> What I'm recommending is for 2.0 is that PRG become 'the' way to do 
post forms
 >> in ZFW 2.0. Or at least, a heck of a lot less terse in terms of the 
coding
 >> required. Lets integrate Session/FlashMessenger/Routing/Controllers 
into a
 >> comprehensive 'forms' solution -- it'll result in better outcomes 
for deployed
 >> applications. There's already some unimplemented support in the 1.0 
model in
 >> terms of state saving... so its been on the radar...
 >
 > Let's discuss this from a use cases perspective -- if you can provide
 > some examples of how you envision it working, we can start creating a
 > proposal, or work from the existing multi-page form proposal.
 >

I hope this is a good first step -- if you want to take the discussion 
off-list and onto the tracker, just lemme know where.

Kevin

Matthew Weier O'Phinney wrote:
> -- Kevin McArthur <[email-masked]> wrote
> (on Tuesday, 17 November 2009, 11:44 AM -0800):
>   
>> Inline.
>>
>>     PRG is something that can be built around forms, but has nothing to do
>>     with the main purpose of the form component, which is to encapsulate
>>     form element metadata and validation, and to facilitate rendering. PRG
>>     is something you'd handle in your controller. We should not be tightly
>>     binding forms and controllers; they should remain loosely coupled (if at
>>     all coupled).
>>
>>
>> The issue is that Zend_Form and PRG being so loosely coupled makes it a real
>> pain to do PRG, and sadly results in most people who use Zend_Form not doing
>> PRG (not good for anyone). The biggest issue comes from when validators add
>> error messages, and fields need to remember their values. Currently this has to
>> be manually saved to each field, and the controllers quickly become unwieldy.
>> There's a prop for prg (and multi-page forms)... but I'm not sure how that
>> integrates into 2.0 here....
>>
>> PRG can be handled in the controller, but when you start doing that you really
>> lose any value that ZFORM adds -- I pretty much just use Zend_Validate/
>> Zend_Filter_Input on its own these days because ZFORM adds so little value in
>> the the PRG context.
>>
>> I really think that a PRG scenario, and a simplification on how this works
>> currently should be added to the 2.0 map -- even if you wont accept PRG as a
>> default scenario [which I think it should be as get forms are usually treated
>> as parameters, and most forms are therefore posted statefully]
>>     
>
> Are we talking about the same thing? We're either not, or you're using
> Zend_Form and Zend_Controller very differently from anyone I've ever
> talked to. 
>
> As an example of what I'm talking about:
>
>     class FooController extends Zend_Controller_Action
>     {
>         public function barAction()
>         {
>             $form    = new SomeForm();
>             $request = $this->getRequest();
>             
>             if ($request->isPost()) {
>                 // POST request; validate form
>                 if (!$form->isValid($request->getPost())) {
>                     // Invalid; redisplay with errors
>                     $this->view->form = $form;
>                     return;
>                 }
>
>                 // Valid; update model, and REDIRECT
>                 $model = new SomeModel();
>                 $id = $model->create($form->getValues());
>                 return $this->_helper->redirector('item', 'foo', 'default', array(
>                     'id' => $id,
>                 ));
>             }
>
>             // Display form
>             $this->view->form = $form;
>         }
>     }
>
> The above does most aspects of PRG, and all those steps would be
> necessary regardless of how Zend_Form works; you're marshalling input,
> and deciding how to respond. 
>
> If you're wanting redirection on failure, I'm not entirely sure I see
> the point; you'd get the same exact result as before. Most literature on
> PRG actually indicates that the Redirect/Get are only really necessary
> for _successful_ actions, not those resulting in validation errors.
>
> The work done for multi-page form support would make PRG for error cases
> trivially possible, however, and maintains the loose coupling between
> Zend_Form and the other MVC components by pushing this interaction into
> an action helper. This is the preferred approach, as keeping the
> components isolated makes them easier to test and repurpose.  (As for
> the multi-page form support, unfortunately, the contributor has had no
> time to complete that component. If somebody is willing to step up and
> work on it, I'm sure the help would be welcome.)
>
> Forms do have use-cases outside of HTTP -- I personally want to work up
> a version that utilizes ncurses and/or readline so as to create
> CLI-based forms -- where PRG would have absolutely no meaning
> whatsoever.
>
>   
>> Using PRG _should_ be as easy as not using it, and the Zend_Session/
>> FlashMessenger/SaveState stuff should all be handled in the core classes as its
>> really laborious to do it in the controllers, and for the most part, totally
>> redundant and unnecessary.
>>     
>
> Regarding your comments on sessions... those *are* core classes, can be
> used with or without the MVC, and are as simple as instantiating and
> using objects. I'm really needing some examples here if I'm going to
> understand what you're getting at.
>
>   
>>         This is obviously a quick overview, but the idea is to more tightly
>>         tie Zend_Form in with the request cycle, assume PRG is the priority
>>         method for forms, and treat decoration in the view, not the model or
>>         controller.
>>
>>
>>     As noted, I don't think PRG has anything to do with the forms, but
>>     everything to do with controllers, and should be treated there. It's
>>     already trivially easy to accomplish.
>>
>>
>> Trivial is relative I suppose. The tying in of Zend_Form with
>> Zend_Session to remember state, validation errors and flash messenger
>> with the controller layer to glue it together, its not trivial enough. 
>>
>> Most of the forms examples don't do PRG, and last I checked its not
>> even the quickstart recommended method. (
>> http://framework.zend.com/docs/quickstart/create-a-form doesn't
>> redirect on failure for example) ... the docs follow in the same vain.
>>     
>
> See my above notes. If you apply the RG portion of PRG to simply the
> success responses, then it's already easily and readily supported. If
> you want to apply it to *all* form responses, then we need some more
> infrastructure -- but that is not difficult to achieve. We simply need a
> proposal (BTW, there is no PRG proposal, just the multi-page form
> proposal).
>
>   
>> What I'm recommending is for 2.0 is that PRG become 'the' way to do post forms
>> in ZFW 2.0. Or at least, a heck of a lot less terse in terms of the coding
>> required. Lets integrate Session/FlashMessenger/Routing/Controllers into a
>> comprehensive 'forms' solution -- it'll result in better outcomes for deployed
>> applications. There's already some unimplemented support in the 1.0 model in
>> terms of state saving... so its been on the radar...
>>     
>
> Let's discuss this from a use cases perspective -- if you can provide
> some examples of how you envision it working, we can start creating a
> proposal, or work from the existing multi-page form proposal.
>
>   

--------------070700000502080501030903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
*Sorry about the formatting, my power went out as writing this and had
to save to a textfile before my ups died!... Fun days on Vancouver
Island BC... *<br>
<br>
&lt;snip&gt;<br>
&gt;<br>
&gt; Are we talking about the same thing? <br>
Maybe not... When I use PRG I mean it to be any page the user _sees_ is
the result of a get action --- always --- Errors, Success, Username
taken... etc. This is essential in avoiding the 'this page has
expired', repost/cancel dialog. In a modern environment with sessions
as accessible as they are now, there's really no reason not to do this.<br>
&gt; We're either not, or you're using<br>
&gt; Zend_Form and Zend_Controller very differently from anyone I've
ever<br>
&gt; talked to. <br>
<br>
There's lots of guys like me ;) [and a few more who read my book , and
do it the way I describe in there, which is PRG but without the form
data state save]<br>
<br>
<br>
[code for (listing 15-16)]<br>
<br>
public function addAction() {<br>
&nbsp; $request = $this-&gt;getRequest();<br>
<br>
&nbsp; //Determine if processing a post request<br>
&nbsp; if($request-&gt;isPost()) {<br>
<br>
&nbsp;&nbsp;&nbsp; //Filter tags from the name field<br>
&nbsp;&nbsp;&nbsp; $filters = array(<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'name' =&gt; 'StripTags'<br>
&nbsp;&nbsp;&nbsp; );<br>
<br>
&nbsp;&nbsp;&nbsp; //Validate name is not less than 1 character and not more than 64<br>
&nbsp;&nbsp;&nbsp; $validation = array(<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'name' =&gt; array (<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; array('StringLength', 1, 64)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )<br>
&nbsp;&nbsp;&nbsp; );<br>
<br>
&nbsp;&nbsp;&nbsp; //Initialize Zend_Filter_Input (ZFI) passing it the entire
getPost() array<br>
&nbsp;&nbsp;&nbsp; $zfi = new Zend_Filter_Input($filters, $validation,
$request-&gt;getPost());<br>
<br>
&nbsp;&nbsp;&nbsp; //If the validators passed this will be true<br>
&nbsp;&nbsp;&nbsp; if ($zfi-&gt;isValid()) {<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Fetch the data from zfi directly and create an array for Zend_Db<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $clean = array();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $clean['name'] = $zfi-&gt;name;<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Create an instance of the customers table and insert the $clean
row<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $customers = new Customers();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $customers-&gt;insert($clean);<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Redirect to the display page after adding<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;getHelper('redirector')-&gt;goto('index');<br>
<br>
&nbsp;&nbsp;&nbsp; } else {<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //The form didn't validate, get the messages from ZFI<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; foreach($zfi-&gt;getMessages() as $field=&gt;$messages) {<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Put each ZFI message into the FlashMessenger so it shows on
the form<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; foreach($messages as $message) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;getHelper('FlashMessenger')<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;addMessage($field . ' : '. $message);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Redirect back to the input form, but with messages<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;getHelper('redirector')-&gt;goto('add');<br>
&nbsp;&nbsp;&nbsp; }<br>
&nbsp; }<br>
<br>
&nbsp; //Not a post request, check for flash messages and expose to the view<br>
&nbsp; if($this-&gt;getHelper('FlashMessenger')-&gt;hasMessages()) {<br>
&nbsp;&nbsp;&nbsp; $this-&gt;view-&gt;messages =
$this-&gt;getHelper('FlashMessenger')-&gt;getMessages();<br>
&nbsp; }<br>
<br>
&nbsp; //The view renderer will now automatically render the add.phtml
template<br>
<br>
}<br>
<br>
[/code]<br>
<br>
So thats a basic error-state prg... but normally I also add in a
Zend_Session object around where I enqueue the error messages into the
flashmessenger. On the display side, I manually pull from the session
and repopulate the form saved values. That looks like:<br>
<br>
[code, pseudo]<br>
<br>
public function addAction() {<br>
&nbsp; $request = $this-&gt;getRequest();<br>
<br>
&nbsp; //Determine if processing a post request<br>
&nbsp; if($request-&gt;isPost()) {<br>
<br>
&nbsp;&nbsp;&nbsp; //Filter tags from the name field<br>
&nbsp;&nbsp;&nbsp; $filters = array(<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'name' =&gt; 'StripTags'<br>
&nbsp;&nbsp;&nbsp; );<br>
<br>
&nbsp;&nbsp;&nbsp; //Validate name is not less than 1 character and not more than 64<br>
&nbsp;&nbsp;&nbsp; $validation = array(<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'name' =&gt; array (<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; array('StringLength', 1, 64)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )<br>
&nbsp;&nbsp;&nbsp; );<br>
<br>
&nbsp;&nbsp;&nbsp; //Initialize Zend_Filter_Input (ZFI) passing it the entire
getPost() array<br>
&nbsp;&nbsp;&nbsp; $zfi = new Zend_Filter_Input($filters, $validation,
$request-&gt;getPost());<br>
<br>
&nbsp;&nbsp;&nbsp; //If the validators passed this will be true<br>
&nbsp;&nbsp;&nbsp; if ($zfi-&gt;isValid()) {<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Fetch the data from zfi directly and create an array for Zend_Db<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $clean = array();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $clean['name'] = $zfi-&gt;name;<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Create an instance of the customers table and insert the $clean
row<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $customers = new Customers();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $customers-&gt;insert($clean);<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Redirect to the display page after adding<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;getHelper('redirector')-&gt;goto('index');<br>
<br>
&nbsp;&nbsp;&nbsp; } else {<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //The form didn't validate, get the messages from ZFI<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; foreach($zfi-&gt;getMessages() as $field=&gt;$messages) {<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Put each ZFI message into the FlashMessenger so it shows on
the form<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; foreach($messages as $message) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;getHelper('FlashMessenger')<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;addMessage($field . ' : '. $message);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $session = new Zend_Session_Namespace('nameofform');<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $session-&gt;nameField = $zfi-&gt;name;<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Redirect back to the input form, but with messages<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $this-&gt;getHelper('redirector')-&gt;goto('add');<br>
&nbsp;&nbsp;&nbsp; }<br>
&nbsp; }<br>
<br>
&nbsp; //Not a post request, check for flash messages and expose to the view<br>
&nbsp; if($this-&gt;getHelper('FlashMessenger')-&gt;hasMessages()) {<br>
&nbsp;&nbsp;&nbsp; $this-&gt;view-&gt;messages =
$this-&gt;getHelper('FlashMessenger')-&gt;getMessages();<br>
&nbsp; }<br>
<br>
&nbsp; $session = new Zend_Session_Namespace('nameofform');<br>
&nbsp; $this-&gt;view-&gt;nameField = $session-&gt;nameField;<br>
<br>
&nbsp; //The view renderer will now automatically render the add.phtml
template<br>
<br>
}<br>
<br>
[/code]<br>
<br>
... add in a big form (this is for one field)... and this gets rather
terse to do for each form...<br>
<br>
<br>
&lt;snip&gt;<br>
<br>
<br>
&gt;<br>
&gt;<br>
&gt; The above does most aspects of PRG, and all those steps would be<br>
&gt; necessary regardless of how Zend_Form works; you're marshalling
input,<br>
&gt; and deciding how to respond. <br>
<br>
I think the most important part of PRG is in-fact on failure. If you're
just going forward, you're not going to get to that expired state
anyway. With this approach I've been able to make multi-stage shopping
cart checkouts that can gracefully handle the back/forward button being
clicked, and portions of a multi-stage form resubmitted, without
breaking everything or confusing the user with state expired pages.<br>
<br>
&gt;<br>
&gt; If you're wanting redirection on failure, I'm not entirely sure I
see<br>
&gt; the point; you'd get the same exact result as before. Most
literature on<br>
&gt; PRG actually indicates that the Redirect/Get are only really
necessary<br>
&gt; for _successful_ actions, not those resulting in validation errors.<br>
<br>
Its important for an error state as when confronted with an error,
users often hit the back button, and then state gets really messed up
if they do or dont repost... and such. The flow charts can get really
nasty if you don't follow the 'display only as a result of get' rule.<br>
<br>
&gt;<br>
&gt; The work done for multi-page form support would make PRG for error
cases<br>
&gt; trivially possible, however, and maintains the loose coupling
between<br>
&gt; Zend_Form and the other MVC components by pushing this interaction
into<br>
&gt; an action helper. This is the preferred approach, as keeping the<br>
&gt; components isolated makes them easier to test and repurpose.&nbsp; (As
for<br>
&gt; the multi-page form support, unfortunately, the contributor has
had no<br>
&gt; time to complete that component. If somebody is willing to step up
and<br>
&gt; work on it, I'm sure the help would be welcome.)<br>
<br>
I've been tracking this, hoping it would be the solution to PRG. I
hadn't realized it had died on the vine. I'm happy to work on the
architecture with you guys if there's interest.<br>
<br>
&gt;<br>
&gt; Forms do have use-cases outside of HTTP -- I personally want to
work up<br>
&gt; a version that utilizes ncurses and/or readline so as to create<br>
&gt; CLI-based forms -- where PRG would have absolutely no meaning<br>
&gt; whatsoever.<br>
<br>
That would be cool... not sure what the ecosystem looks like when we
start talking about forms processing in abstract terms tho. I've wanted
to get some forms stuff setup for put and delete requests too, but
those have their own caveats too.<br>
<br>
&gt;<br>
&gt;&gt; Using PRG _should_ be as easy as not using it, and the
Zend_Session/<br>
&gt;&gt; FlashMessenger/SaveState stuff should all be handled in the
core classes as its<br>
&gt;&gt; really laborious to do it in the controllers, and for the most
part, totally<br>
&gt;&gt; redundant and unnecessary.<br>
&gt;<br>
&gt; Regarding your comments on sessions... those *are* core classes,
can be<br>
&gt; used with or without the MVC, and are as simple as instantiating
and<br>
&gt; using objects. I'm really needing some examples here if I'm going
to<br>
&gt; understand what you're getting at.<br>
&gt;<br>
<br>
It's not complicated at current, but its terse and undocumented. You
can see the examples above, but it really comes down to the
state-saving, and integration with all the objects that are in play. It
would also solve your multi-page forms requirement as a by-product
really.<br>
<br>
&gt;<br>
&gt; See my above notes. If you apply the RG portion of PRG to simply
the<br>
&gt; success responses, then it's already easily and readily supported.
If<br>
&gt; you want to apply it to *all* form responses, then we need some
more<br>
&gt; infrastructure -- but that is not difficult to achieve. We simply
need a<br>
&gt; proposal (BTW, there is no PRG proposal, just the multi-page form<br>
&gt; proposal).<br>
<br>
Should be applied to all IMHO. Its a rule in my shop that all pages a
user sees is a result of a get request -- never post.<br>
<br>
&gt;<br>
&gt;&gt; What I'm recommending is for 2.0 is that PRG become 'the' way
to do post forms<br>
&gt;&gt; in ZFW 2.0. Or at least, a heck of a lot less terse in terms
of the coding<br>
&gt;&gt; required. Lets integrate
Session/FlashMessenger/Routing/Controllers into a<br>
&gt;&gt; comprehensive 'forms' solution -- it'll result in better
outcomes for deployed<br>
&gt;&gt; applications. There's already some unimplemented support in
the 1.0 model in<br>
&gt;&gt; terms of state saving... so its been on the radar...<br>
&gt;<br>
&gt; Let's discuss this from a use cases perspective -- if you can
provide<br>
&gt; some examples of how you envision it working, we can start
creating a<br>
&gt; proposal, or work from the existing multi-page form proposal.<br>
&gt;<br>
<br>
I hope this is a good first step -- if you want to take the discussion
off-list and onto the tracker, just lemme know where.<br>
<br>
Kevin<br>
<br>
<br>
<br>
Matthew Weier O'Phinney wrote:
<blockquote cite="mid:20091117202626.GU25898@localhost" type="cite">
  <pre wrap="">-- Kevin McArthur <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote
(on Tuesday, 17 November 2009, 11:44 AM -0800):
  </pre>
  <blockquote type="cite">
    <pre wrap="">Inline.

    PRG is something that can be built around forms, but has nothing to do
    with the main purpose of the form component, which is to encapsulate
    form element metadata and validation, and to facilitate rendering. PRG
    is something you'd handle in your controller. We should not be tightly
    binding forms and controllers; they should remain loosely coupled (if at
    all coupled).

The issue is that Zend_Form and PRG being so loosely coupled makes it a real
pain to do PRG, and sadly results in most people who use Zend_Form not doing
PRG (not good for anyone). The biggest issue comes from when validators add
error messages, and fields need to remember their values. Currently this has to
be manually saved to each field, and the controllers quickly become unwieldy.
There's a prop for prg (and multi-page forms)... but I'm not sure how that
integrates into 2.0 here....

PRG can be handled in the controller, but when you start doing that you really
lose any value that ZFORM adds -- I pretty much just use Zend_Validate/
Zend_Filter_Input on its own these days because ZFORM adds so little value in
the the PRG context.

I really think that a PRG scenario, and a simplification on how this works
currently should be added to the 2.0 map -- even if you wont accept PRG as a
default scenario [which I think it should be as get forms are usually treated
as parameters, and most forms are therefore posted statefully]
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Are we talking about the same thing? We're either not, or you're using
Zend_Form and Zend_Controller very differently from anyone I've ever
talked to. 

As an example of what I'm talking about:

    class FooController extends Zend_Controller_Action
    {
        public function barAction()
        {
            $form    = new SomeForm();
            $request = $this-&gt;getRequest();
            
            if ($request-&gt;isPost()) {
                // POST request; validate form
                if (!$form-&gt;isValid($request-&gt;getPost())) {
                    // Invalid; redisplay with errors
                    $this-&gt;view-&gt;form = $form;
                    return;
                }

                // Valid; update model, and REDIRECT
                $model = new SomeModel();
                $id = $model-&gt;create($form-&gt;getValues());
                return $this-&gt;_helper-&gt;redirector('item', 'foo', 'default', array(
                    'id' =&gt; $id,
                ));
            }

            // Display form
            $this-&gt;view-&gt;form = $form;
        }
    }

The above does most aspects of PRG, and all those steps would be
necessary regardless of how Zend_Form works; you're marshalling input,
and deciding how to respond. 

If you're wanting redirection on failure, I'm not entirely sure I see
the point; you'd get the same exact result as before. Most literature on
PRG actually indicates that the Redirect/Get are only really necessary
for _successful_ actions, not those resulting in validation errors.

The work done for multi-page form support would make PRG for error cases
trivially possible, however, and maintains the loose coupling between
Zend_Form and the other MVC components by pushing this interaction into
an action helper. This is the preferred approach, as keeping the
components isolated makes them easier to test and repurpose.  (As for
the multi-page form support, unfortunately, the contributor has had no
time to complete that component. If somebody is willing to step up and
work on it, I'm sure the help would be welcome.)

Forms do have use-cases outside of HTTP -- I personally want to work up
a version that utilizes ncurses and/or readline so as to create
CLI-based forms -- where PRG would have absolutely no meaning
whatsoever.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Using PRG _should_ be as easy as not using it, and the Zend_Session/
FlashMessenger/SaveState stuff should all be handled in the core classes as its
really laborious to do it in the controllers, and for the most part, totally
redundant and unnecessary.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Regarding your comments on sessions... those *are* core classes, can be
used with or without the MVC, and are as simple as instantiating and
using objects. I'm really needing some examples here if I'm going to
understand what you're getting at.

  </pre>
  <blockquote type="cite">
    <pre wrap="">        This is obviously a quick overview, but the idea is to more tightly
        tie Zend_Form in with the request cycle, assume PRG is the priority
        method for forms, and treat decoration in the view, not the model or
        controller.

    As noted, I don't think PRG has anything to do with the forms, but
    everything to do with controllers, and should be treated there. It's
    already trivially easy to accomplish.

Trivial is relative I suppose. The tying in of Zend_Form with
Zend_Session to remember state, validation errors and flash messenger
with the controller layer to glue it together, its not trivial enough. 

Most of the forms examples don't do PRG, and last I checked its not
even the quickstart recommended method. (
<a class="moz-txt-link-freetext" href="http://framework.zend.com/docs/quickstart/create-a-form">http://framework.zend.com/docs/quickstart/create-a-form</a> doesn't
redirect on failure for example) ... the docs follow in the same vain.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
See my above notes. If you apply the RG portion of PRG to simply the
success responses, then it's already easily and readily supported. If
you want to apply it to *all* form responses, then we need some more
infrastructure -- but that is not difficult to achieve. We simply need a
proposal (BTW, there is no PRG proposal, just the multi-page form
proposal).

  </pre>
  <blockquote type="cite">
    <pre wrap="">What I'm recommending is for 2.0 is that PRG become 'the' way to do post forms
in ZFW 2.0. Or at least, a heck of a lot less terse in terms of the coding
required. Lets integrate Session/FlashMessenger/Routing/Controllers into a
comprehensive 'forms' solution -- it'll result in better outcomes for deployed
applications. There's already some unimplemented support in the 1.0 model in
terms of state saving... so its been on the radar...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Let's discuss this from a use cases perspective -- if you can provide
some examples of how you envision it working, we can start creating a
proposal, or work from the existing multi-page form proposal.

  </pre>
</blockquote>
<br>
</body>
</html>

--------------070700000502080501030903--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: =?iso-8859-1?Q?Marcus_St=F6hr?= <[email-masked]>
Date: Tue, 8 Dec 2009 13:15:40 +0100
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] Incubator Issue Tracker: Adding component for each
	incubator component

Hi,

at the moment, there are several components sitting in the incubator for =
development. Wouldn't it be convinient to have a category for each =
component in the issue tracker, e.g. for Zend_Oauth?

- Marcus=

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 06 Nov 2009 00:25:47 +0100
From: Ben Scholzen 'DASPRiD' <[email-masked]>
Organization: DASPRiD's
To: [email-masked]
Subject: Re: [zf-contributors] Zend_Text_Tree proposal ready for review

I'd like a utf-8 decorator like Zend_Text_Table has one, you may want to 
look into it's decorators, they are pretty simple.

Benjamin Eberlei wrote on 06.11.2009 00:13:
> Hello everyone,
> 
> while discussion some of the 1.10 features for Zend_Tool Ralph and I discussed 
> Tree views of datastructures on the console.
> 
> Examples would be displaying the ZF User Config, a Zend Project Structure or 
> the Zend Application config.
> 
> We came to the conslusion that some code that was written already for this 
> task should be generally refactored to allow to print treets on the console 
> using a Tree structure (like the unix command tree generates).
> 
> Here is a simple proposal for this: 
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Text_Tree+-+Benjamin+Eberlei
> 
> greetings,
> Benjamin
> 

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: =?iso-8859-1?Q?Lukas_K=F6ll?= <[email-masked]>
Date: Wed, 31 Mar 2010 21:38:01 +0200
To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

-1 from me, too - I'm totally agreeing with Renan.=20
Additionally I don't think design decisions should be based on how much =
work it=20
is to write the corresponding unit tests. Don't get me wrong, of course =
the code=20
must be testable. But especially for framework code I think that a low =
overhead
should be preferred against easier testability - infact framework code =
is=20
written (or changed) far more seldom than executed.

If, however you decide to use __invoke as proxy, I would recommend to =
somehow
prevent the proxied methods (filter, validate) to be called from outside =
or at least mark them as deprecated
so client code _must_ use invoke and we could then remove the proxies =
later on if
it should be decided that the tests are rewritten.

best regards

Lukas K=F6ll

> -1
>=20
> Talking to my coworkers, a big piece of people take a little more time
> to understand something when there is more than one way to do what
> they want to do. I think that when we start a new project with
> unnecessary duplicated features it's not good. This usually happens
> after years, we should get this situations away. Obviously sometimes
> it's interesting we provide alternative ways to achieve a goal, but
> for those situations  (filter, validator...) it's not.
>=20
>>> The benefits:
>>>=20
>>> * Fewer changes necessary to existing unit tests
>=20
> time is the solution ;-)
>=20
>>> * interface method names may be more descriptive of intent
>=20
> they should pick a better name for their variables, like $filterFloat,
> $filterAlpha
>=20
>>> Problems:
>>>=20
>>> * Using __invoke() introduces overhead -- 2 method calls instead of =
one
>>> * Redundancy (two methods doing the same thing)
>=20
> that's my point! this extra way is not relevant, this one adds no new =
feature
>=20
>>> * A few extra tests to write (to ensure __invoke works as expecte)
>=20
> my 1 cent ;-)
>=20
> --
> Renan de Lima Barbosa
> gtalk/msn: [email-masked]
> skype: renandelima
> +55 61 8166-7755
> renandelima.com
>=20
>=20
>=20
> On 31 March 2010 11:38, Dennis Winter =
<[email-masked]> wrote:
>> +1 on this! It's ok to have two methods for the same thing! And the =
benefit
>> of clearer interfaces is overwhelming the disadvantages!
>> Just my 2 cents!
>>=20
>> Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney =
<[email-masked]>:
>>=20
>>> Greetings, all --
>>>=20
>>> Per the roadmap, one change we're planning on making is making =
plugin
>>> usage consistent across components: plugins will implement =
__invoke(),
>>> which makes them inherently callable.
>>>=20
>>> In our refactoring branch, I've done this now with Zend_Filter. =
However,
>>> it required a ton of refactoring on the unit tests (had to either =
call
>>> __invoke() directly, or $filter($value)), and it got me to thinking:
>>>=20
>>> Would it make sense to keep the original interfaces (filter, =
isValid,
>>> render, etc.), but also implement __invoke() -- having it proxy to =
the
>>> appropriate interface method?
>>>=20
>>> As an example:
>>>=20
>>>   interface Filter
>>>   {
>>>       public function filter($value);
>>>       public function __invoke($value);
>>>   }
>>>=20
>>>   class Digits implements Filter
>>>   {
>>>       public function filter($value)
>>>       {
>>>           // ... logic...
>>>       }
>>>=20
>>>       public function __invoke($value)
>>>       {
>>>           return $this->filter($value);
>>>       }
>>>   }
>>>=20
>>> The benefits:
>>>=20
>>> * Fewer changes necessary to existing unit tests
>>> * interface method names may be more descriptive of intent
>>>=20
>>> Problems:
>>>=20
>>> * Using __invoke() introduces overhead -- 2 method calls instead of =
one
>>> * Redundancy (two methods doing the same thing)
>>> * A few extra tests to write (to ensure __invoke works as expecte)
>>>=20
>>> After discussion with Ralph and Alex, I'm leaning towards having
>>> __invoke() as an _additional_ method, instead of replacing existing
>>> methods.
>>>=20
>>> Any thoughts or comments?
>>>=20
>>> --
>>> Matthew Weier O'Phinney
>>> Project Lead            | [email-masked]
>>> Zend Framework          | http://framework.zend.com/
>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>=20

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 30 Apr 2009 17:30:07 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Zend Framework 1.8.0 Released

Greetings!

I'm pleased to announce the Zend Framework 1.8.0 release, the first in our
1.8 series of releases. This release marks the culmination of several
long-standing projects, as well as a formalization of many of our
recommended practices. You can get it here:

    http://framework.zend.com/download/latest

The number of community contributions and bug fixes for 1.8.0 has been
phenomenal -- we logged well over 200 bug/feature fixes for this minor
releaes alone! 

Below is a list of the primary feature additions for the release.

  * Zend_Tool, contributed by Ralph Schindler
  * Zend_Application, contributed by Ben Scholzen and 
    Matthew Weier O'Phinney
  * Zend_Loader_Autoloader and Zend_Loader_Autoloader_Resource,
    contributed by Matthew Weier O'Phinney
  * Zend_Navigation, contributed by Robin Skoglund
  * Zend_CodeGenerator, by Ralph Schindler
  * Zend_Reflection, Ralph Schindler and Matthew Weier O'Phinney
  * Zend Server backend for Zend_Cache, contributed by 
    Alexander Veremyev
  * Zend_Service_Amazon_Ec2, contributed by Jon Whitcraft
  * Zend_Service_Amazon_S3, Justin Plock and Stas Malyshev
  * Incorporated Dojo 1.3
  * Added support for arbitrary Dojo Dijits via view helpers
  * Zend_Filter_Encrypt, contributed by Thomas Weidner
  * Zend_Filter_Decrypt, contributed by Thomas Weidner
  * Zend_Filter_LocalizedToNormalized and _NormalizedToLocalized,
    contributed by Thomas Weidner 
  * Support for file upload progress support in Zend_File_Transfer, 
    contributed by Thomas Weidner
  * Translation-aware routes, contributed by Ben Scholzen
  * Route chaining capabilities, contributed by Ben Scholzen
  * Zend_Json expression support, contributed by Benjamin Eberlei and
    Oscar Reales
  * Zend_Http_Client_Adapter_Curl, contributed by Benjamin Eberlei
  * SOAP input and output header support, contributed by 
    Alexander Veremyev
  * Support for keyword field search using query strings, contributed by
    Alexander Veremyev
  * Support for searching across multiple indexes in Zend_Search_Lucene,
    contributed by Alexander Veremyev
  * Significant improvements for Zend_Search_Lucene search result match
    highlighting capabilities, contributed by Alexander Veremyev
  * Support for page scaling, shifting and skewing in Zend_Pdf,
    contributed by Alexander Veremyev
  * Zend_Tag_Cloud, contributed by Ben Scholzen
  * Locale support in Zend_Validate_Int and Zend_Validate_Float,
    contributed by Thomas Weidner
  * Phonecode support in Zend_Locale, contributed by Thomas Weidner
  * Zend_Validate_Db_RecordExists and _RecordNotExists, contributed by
    Ryan Mauger
  * Zend_Validate_Iban, contributed by Thomas Weidner
  * Zend_Validate_File_WordCount, contributed by Thomas Weidner

Please join me in a hearty round of congratualations and acknowledgement of
all contributors who helped make this release possible through code
contributions, feedback, testing, documentation, translations, and issue
reports!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 5 Feb 2010 09:00:05 -0500
From: Juan Felipe Alvarez Saldarriaga <[email-masked]>
To: [email-masked]
Cc: Nigel Chapman <[email-masked]>, 
	Zend Contributors List <[email-masked]>
Subject: Re: [zf-contributors] New Proposal: Zend_Array

Hey, nice proposal, a little bit like LINQ right? my concern is about
performance too.

Saludos.

On Fri, Feb 5, 2010 at 3:56 AM, Carlos Medina
<[email-masked]> wrote:
> Nigel Chapman schrieb:
>>
>> Hi All, =A0(? -- not sure how active this list is.)
>>
>> Just a note to announce a new proposal:
>>
>> Zend_Array is a fluent wrapper for PHP's array functions.
>>
>> It lets you deal with arrays rather as you would in Ruby or JQuery,
>> with chained operators and closures.
>>
>> Over the next few weeks, I'll be workign on the doc standards and test
>> suite, and thinking if it needs more (or less!) core methods.
>>
>> Comments? Improvements?
>>
>> * http://chapman.id.au/zend-array/
>>
>> * http://framework.zend.com/wiki/display/ZFPROP/Zend_Array+-+Nigel+Chapm=
an
>>
>> I sometimes appear on #zftalk as kale77in.
>>
>> Thanks,
>>
>> Nigel.
>>
>>
>>
>
> Hi Nigel,
> i think this is a very usefull proposal. The question is: performance? ha=
ve
> you tests about this.
> Regards
> Carlos

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sat, 5 Dec 2009 11:38:38 +0100
From: Giorgio Sironi <[email-masked]>
To: Sune Kibsgaard Pedersen <[email-masked]>
Cc: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Zend Framework modularity and application 
	structure

--0016e6d7e034c639310479f8d3ba
Content-Type: text/plain; charset=ISO-8859-1

My experience with modules is the typical situation of content management
system: small modules provide unrelated functionalities with possible
dependencies between them. The acl is configured at a controller-action
basis and possibly into lower levels which should be managed by the single
module.
I don't create admin interface as there are many roles an user can assume,
so the interface is always the same modified slightly to reflect the current
user's permission.

-- 
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

--0016e6d7e034c639310479f8d3ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My experience with modules is the typical situation of content management s=
ystem: small modules provide unrelated functionalities with possible depend=
encies between them. The acl is configured at a controller-action basis and=
 possibly into lower levels which should be managed by the single module.<b=
r>
I don&#39;t create admin interface as there are many roles an user can assu=
me, so the interface is always the same modified slightly to reflect the cu=
rrent user&#39;s permission.<br clear=3D"all"><br><br>-- <br>Giorgio Sironi=
<br>
Piccolo Principe &amp; Web Engineer<br><a href=3D"http://giorgiosironi.blog=
spot.com">http://giorgiosironi.blogspot.com</a><br><a href=3D"http://twitte=
r.com/giorgiosironi">http://twitter.com/giorgiosironi</a><br>

--0016e6d7e034c639310479f8d3ba--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
Date: Mon, 15 Mar 2010 21:54:07 +0000
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming
	conventions

On 15 Mar 2010, at 19:58, Matthew Weier O'Phinney wrote:

> 1. Prefix interfaces with "I" ("IFoobar").=20
> 2. Suffix interfaces with "Interface" ("FoobarInterface")
> 3. Use adjective/noun names such as "Foobarable", "Foobarist"
>=20
> For abstract classes, we looked at:
>=20
> 4. Prefix abstract classes with "A" ("AFoobar")
> 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
> 6. Prefix abstract classes with "Base" ("BaseFoobar")
> 7. Suffix abstract classes with "Base" ("FoobarBase")
> 8. Use normal class names ("Foobar")

[snip]

> Based on my experiences writing code, I'm currently recommending that =
we
> do the following:
>=20
> 3. Use adjective/noun names for Interfaces such as "Foobarable",
>    "Foobarist"
> 7. Suffix abstract classes with "Base" ("FoobarableBase")
>=20
> The above solve most issues - names are reasonably sized, don't smack =
of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and =
are,
> most importantly, meaningful. Since we already implement code review =
for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.

I like 3 too. I'm with Court on the "it's like the SPL". In theory it =
would also make the interface name sound better. However, some renamings =
can sound a bit odd in practice.

Looking at some actual interfaces we have at the moment:

These are definite improvements:
* Zend_Filter_Compress_CompressInterface =3D> =
Zend_Filter_Compress_Compressable
* Zend_Oauth_Config_ConfigInterface =3D> Zend_Oauth_Configurable
* Zend_Queue_Stomp_Client_ConnectionInterface =3D> =
Zend_Queue_Stomp_Client_Connectable

but then you also get:
* Zend_Serializer_Adapter_AdapterInterface becomes =
Zend_Serializer_Adaptable
* Zend_Feed_Pubsubhubbub_CallbackInterface =3D> =
Zend_Feed_Pubsubhubbub_Callbackable

and some complete renames:
* Zend_Currency_CurrencyInterface =3D> Zend_Currency_Exchangable / =
Zend_Currency_Convertable
* Zend_Log_FactoryInterface =3D> Zend_ Loggable

which maybe sound less good...

The principle is sound though. I suspect that it's just a case that some =
interfaces need to be re-evaluated as to why they exist and then named =
for what they are actually there for.

As for abstract classes, I'm in favour of "Abstract" in preference to =
"Base" as if we're going to have an artificial construct, "Abstract" is =
completely unambiguous. I would rather try and remove as many as =
possible and rename to a proper name though. e.g. Zend_Db_Table_Abstract =
and Zend_Db_Table could be merged to just Zend_Db_Table, especially as =
Zend_Db_Table causes an E_STRICT warning due to redefining the =
__construct() method signature :)

Regards,

Rob...

Zend_View_Helper_Abstract =3D> Zend_View_Helper

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 15 Sep 2009 06:44:27 -0700 (PDT)
From: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
To: Zend Framework Contributors <[email-masked]>
Subject: [zf-contributors] [Proposal/Discussion] Reusable Self-Contained Zend
	Framework Modules

--0-1316890049-1253022267=:72186
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

As some of the list members may have noticed, I spent late last week poking=
 and prodding at the concept of a reusable Zend Framework module. http://bl=
og.astrumfutura.com/archives/415-Self-Contained-Reusable-Zend-Framework-Mod=
ules-With-Standardised-Configurators.html=0A=0AI figured an email to the Co=
ntributors list was warranted to get more discussion going on the concept, =
and also to present an initial proposal dealing with one facet of this - on=
-access module configuration. The proposal is up at http://framework.zend.c=
om/wiki/pages/viewpage.action?pageId=3D16023853 and Rob Zienert and I are t=
he current proposers. Rob has been working the problem for a while now as h=
e is involved in the http://www.zfcomponents.com project.=0A=0AIn a nutshel=
l, the reusability problem isn't that it's incredibly difficult but rather =
that it has not received a lot of attention. There are no concrete examples=
 in the wild and no standards that modules can adhere to. I can count the b=
log posts referring to the concept on the fingers of one hand (including my=
 blog). This has led to a lot of non-standard directions being attempted: c=
ustom plugins, configuration merging, bootstrap hooks, etc. From the feedba=
ck, the concept of a reusable module is very much desired and Zend_Applicat=
ion has already solved quite a lot of the original problems.=0A=0ADefining =
the problem is easily done with an example. Module Foo utilises a different=
 layout from the Default Module. We can't define the module's layout in app=
lication.ini (I'll assume Zend_Application is always used at this stage) be=
cause even module name prefixed settings will overwrite like application se=
ttings. So, foo.resources.layout.layoutPath will overwrite resources.layout=
.layoutPath.=0A=0AThe solution, typically, is to introduce a plugin with a =
preDispatch() method which detects the current module and switches the layo=
ut by reconfiguring Zend_Layout on the fly. It works, but it has issues. It=
's not a standard Zend Framework component. It's not amenable to configurat=
ion without additional work. No two applications likely do the exact same w=
ay unless they were written by the same developer. With such a mixture of a=
pproaches (most examples online neglect to realise Zend_Layout already offe=
rs a Layout plugin we can subclass and use) it's no wonder agreeing on such=
 a simple thing across third-party modules is difficult.=0A=0AI suggested i=
n the blog that we use classes called Configurators which operate parallel =
to the Resources used during bootstrapping. While bootstrapping occurs prio=
r to routing, Configurators may kick in after routing and allow for the rec=
onfiguration of Resources, or the initialisation of module-specific Resourc=
es (lazy loading), depending on the module detected during routing. The inp=
ut into the process would be an application.ini style configuration file st=
ored within the Module itself (or optionally somewhere near application.ini=
).=0A=0AIn this system, a Layout plugin would never be needed. The Configur=
ator process would locate a Module's on-access configuration, and reconfigu=
re the existing Layout Resource using a Configurator Class, e.g. Zend_Appli=
cation_Module_Configurator_Layout.=0A=0AIn this way, custom plugins are ren=
dered deprecated and can be replaced with a standard system that all Module=
s can utilise, immediately boosting the ability to port Modules to applicat=
ions and distribute them through third-party networks like Rob's ZFComponen=
ts.com. Forgetting Layouts, this applies to all Resources for any configura=
tion change (except those used during routing for obvious reasons). Perhaps=
 a Module uses a different character encoding, a different doctype, a diffe=
rent database connection, etc.=0A=0AIn terms of feedback, besides the propo=
sal above, we need a picture of what else would be required for a perfectly=
 reusable module. What other concerns would users have? What other conventi=
ons and features would be required? I'm sure one proposal isn't the entire =
picture.=0A=0A P=E1draic Brady=0A=0Ahttp://blog.astrumfutura.com=0Ahttp://w=
ww.survivethedeepend.com=0AOpenID Europe Foundation Irish Representative
--0-1316890049-1253022267=:72186
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">As some of the list members may have noticed, I spent late las=
t week poking and prodding at the concept of a reusable Zend Framework modu=
le. <a href=3D"http://blog.astrumfutura.com/archives/415-Self-Contained-Reu=
sable-Zend-Framework-Modules-With-Standardised-Configurators.html">http://b=
log.astrumfutura.com/archives/415-Self-Contained-Reusable-Zend-Framework-Mo=
dules-With-Standardised-Configurators.html</a><br><br>I figured an email to=
 the Contributors list was warranted to get more discussion going on the co=
ncept, and also to present an initial proposal dealing with one facet of th=
is - on-access module configuration. The proposal is up at <a href=3D"http:=
//framework.zend.com/wiki/pages/viewpage.action?pageId=3D16023853">http://f=
ramework.zend.com/wiki/pages/viewpage.action?pageId=3D16023853</a> and Rob
 Zienert and I are the current proposers. Rob has been working the problem =
for a while now as he is involved in the <a href=3D"http://www.zfcomponents=
.com">http://www.zfcomponents.com</a> project.<br><br>In a nutshell, the re=
usability problem isn't that it's incredibly difficult but rather that it h=
as not received a lot of attention. There are no concrete examples in the w=
ild and no standards that modules can adhere to. I can count the blog posts=
 referring to the concept on the fingers of one hand (including my blog). T=
his has led to a lot of non-standard directions being attempted: custom plu=
gins, configuration merging, bootstrap hooks, etc. From the feedback, the c=
oncept of a reusable module is very much desired and Zend_Application has a=
lready solved quite a lot of the original problems.<br><br>Defining the pro=
blem is easily done with an example. Module Foo utilises a different layout=
 from the Default Module. We can't define the module's layout in
 application.ini (I'll assume Zend_Application is always used at this stage=
) because even module name prefixed settings will overwrite like applicatio=
n settings. So, foo.resources.layout.layoutPath will overwrite resources.la=
yout.layoutPath.<br><br>The solution, typically, is to introduce a plugin w=
ith a preDispatch() method which detects the current module and switches th=
e layout by reconfiguring Zend_Layout on the fly. It works, but it has issu=
es. It's not a standard Zend Framework component. It's not amenable to conf=
iguration without additional work. No two applications likely do the exact =
same way unless they were written by the same developer. With such a mixtur=
e of approaches (most examples online neglect to realise Zend_Layout alread=
y offers a Layout plugin we can subclass and use) it's no wonder agreeing o=
n such a simple thing across third-party modules is difficult.<br><br>I sug=
gested in the blog that we use classes called Configurators which
 operate parallel to the Resources used during bootstrapping. While bootstr=
apping occurs prior to routing, Configurators may kick in after routing and=
 allow for the reconfiguration of Resources, or the initialisation of modul=
e-specific Resources (lazy loading), depending on the module detected durin=
g routing. The input into the process would be an application.ini style con=
figuration file stored within the Module itself (or optionally somewhere ne=
ar application.ini).<br><br>In this system, a Layout plugin would never be =
needed. The Configurator process would locate a Module's on-access configur=
ation, and reconfigure the existing Layout Resource using a Configurator Cl=
ass, e.g. Zend_Application_Module_Configurator_Layout.<br><br>In this way, =
custom plugins are rendered deprecated and can be replaced with a standard =
system that all Modules can utilise, immediately boosting the ability to po=
rt Modules to applications and distribute them through third-party
 networks like Rob's ZFComponents.com. Forgetting Layouts, this applies to =
all Resources for any configuration change (except those used during routin=
g for obvious reasons). Perhaps a Module uses a different character encodin=
g, a different doctype, a different database connection, etc.<br><br>In ter=
ms of feedback, besides the proposal above, we need a picture of what else =
would be required for a perfectly reusable module. What other concerns woul=
d users have? What other conventions and features would be required? I'm su=
re one proposal isn't the entire picture.<br><div>&nbsp;</div><span style=
=3D"color: rgb(0, 0, 191);"><font style=3D"font-family: times new roman,new=
 york,times,serif;" size=3D"3"><span style=3D"font-weight: bold;">P=E1draic=
 Brady<br><br></span></font><span style=3D"font-style: italic;"><font style=
=3D"font-family: times new roman,new york,times,serif;" size=3D"3"><a rel=
=3D"nofollow" target=3D"_blank"
 href=3D"http://blog.astrumfutura.com">http://blog.astrumfutura.com</a><br>=
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.survivethedeepend.=
com">http://www.survivethedeepend.com</a><br><a rel=3D"nofollow" target=3D"=
_blank" href=3D"http://www.openideurope.eu/">OpenID Europe Foundation Irish=
 Representative</a><br></font></span></span><div><br></div></div></body></h=
tml>
--0-1316890049-1253022267=:72186--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 30 Sep 2009 07:55:24 +0200
From: =?UTF-8?B?0KHQsNGI0LAg0KHRgtCw0LzQtdC90LrQvtCy0LjRmw==?=
	<[email-masked]>
To: Justin Plock <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Re: Google Wave Invites

--0016364c79535221380474c52d7a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Me 2 - [email-masked]

Regards,
Sa=C5=A1a Stamenkovi=C4=87

On Wed, Sep 30, 2009 at 12:46 AM, Justin Plock <[email-masked]> wrote:

> I'll take one - [email-masked]
>
> Thanks!
>
> -Justin
>
>
> Graham Anderson wrote:
>
>> The first wave (pardon the pun) of mass invites for Google Wave are goin=
g
>> out tomorrow, people with existing accounts and new invitees will be
>> allocated 8 additional invites.
>>
>> If you don't already have a wave account and have *not* signed up to get
>> one, I'll send out my 8 invites in on a first come first served basis on
>> this list.
>>
>> Graham
>>
>
>

--0016364c79535221380474c52d7a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Me 2 - <a href=3D"mailto:[email-masked]">[email-masked]</a><br clea=
r=3D"all"><br>Regards,<br>Sa=C5=A1a Stamenkovi=C4=87<br>
<br><br><div class=3D"gmail_quote">On Wed, Sep 30, 2009 at 12:46 AM, Justin=
 Plock <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">jplock@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I&#39;ll take one - <a href=3D"mailto:[email-masked]" target=3D"_blank">j=
[email-masked]</a><br>
<br>
Thanks!<br><font color=3D"#888888">
<br>
-Justin</font><div><div></div><div class=3D"h5"><br>
<br>
Graham Anderson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The first wave (pardon the pun) of mass invites for Google Wave are going o=
ut tomorrow, people with existing accounts and new invitees will be allocat=
ed 8 additional invites.<br>
<br>
If you don&#39;t already have a wave account and have *not* signed up to ge=
t one, I&#39;ll send out my 8 invites in on a first come first served basis=
 on this list.<br>
<br>
Graham<br>
</blockquote>
<br>
</div></div></blockquote></div><br>

--0016364c79535221380474c52d7a--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 19 Oct 2009 00:01:02 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] JIRA Incubator Components Update

-- P=E1draic Brady <[email-masked]> wrote
(on Saturday, 17 October 2009, 06:15 AM -0700):
> Just requesting that we add in the missing Incubator components to JIRA=
 if
> possible. At present we can't create issues for these.

Can you refresh my memory as to which incubator components need to be
added? I'll try and do so Tuesday, once I have a list.

> Assuming everyone has recovered from fixing 100 issues during the bug h=
unt! :P

Indeed! Awesome job, everyone! The final count for the official hunt was
95, and you can view the list here:

    http://framework.zend.com/issues/secure/IssueNavigator.jspa?mode=3Dhi=
de&requestId=3D11156

I'll be announcing the winner on Tuesday -- but many thanks now to
everyone who participated!

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 29 Jan 2010 14:54:18 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] ZF-8938

-- Andy Fowler <[email-masked]> wrote
(on Friday, 29 January 2010, 08:26 AM -0500):
> Interesting -- I didn't see that ticket. After my patches (which I'm currently
> implementing in subclasses), numerically-named forms are working fine for us,
> but we aren't explicitly accessing them via overload. I had assumed they were
> accepted because of all of the existing empty() || === "0" code.
> 
> More importantly, there is already an existing "testZeroAsNameIsAllowed" unit
> test. If numerically-named forms aren't permitted, that test should fail,
> rather than silently allow data to be mangled.

There are tests for the overloading support. If those tests still run
with your patch applied, then I think we should apply it.

I'll take a look at it next week, and work with getting you SVN access
at that time.

> Zend_Form::__clone() also currently breaks with all-numerically-indexed
> subforms, but could be easily patched.
> 
> 
> On Jan 29, 2010, at 3:23 AM, Giorgio Sironi wrote:
> 
> 
>     Are you sure numeric names should be accepted? I reported a similar issue
>     and Matthew pointed out that numeric form names would break overloading of
>     properties:
>     http://framework.zend.com/issues/browse/ZF-6062
>     For instance $form->2 when $form has a subform with a numeric name would
>     not work.
>     If numeric form names have been re-evaluated I hope also #6062 can be
>     fixed.
> 
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Graham Anderson <[email-masked]>
To: [email-masked]
Date: Tue, 29 Sep 2009 18:17:15 +0200
Subject: [zf-contributors] Google Wave Invites

The first wave (pardon the pun) of mass invites for Google Wave are going o=
ut=20
tomorrow, people with existing accounts and new invitees will be allocated =
8=20
additional invites.

If you don't already have a wave account and have *not* signed up to get on=
e,=20
I'll send out my 8 invites in on a first come first served basis on this li=
st.

Graham
=2D-=20
=E2=80=9CExperience is the name everyone gives to their mistakes.=E2=80=9D
 =E2=98=98 Oscar Wilde

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
To: "Zend Framework Contributors ([email-masked])"
	<[email-masked]>
Date: Wed, 23 Sep 2009 08:32:43 +0100
Subject: Re: [zf-contributors] Considering yanking 1.9.3 -- thoughts?

On 22 Sep 2009, at 19:01, Matthew Weier O'Phinney wrote:

> I'd like the opinion of the various contributors, if you could.

[snip]

> The options I can see are:
>
> * Yank the current package, and rebuild.
> * Create a patch-level package (1.9.3pl1), and deprecate 1.9.3.
> * Do nothing, and continue on.
>

That was fast work - I don't read email for an evening and missed the  
excitement! :)

FWIW, I completely agree with reverting to the 1.9.2 behaviour. I can  
live with (a few) BC breaks at the .y level, but need to be confident  
that .z is "safe".

The only sane options were to either release 1.9.3pl1 or release  
1.9.4. Personally, I'd have preferred 1.9.4 as pl releases  always  
confuse me, but understand that complexities of the release process  
meant that a pl could be done much faster.

Mildly surprised that noone noticed that ZendX db adapters didn't work  
in 1.9.0 before the release of 1.9.0 though. Surely the tests failed?!

Regards,

Rob... 

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Sawan Ruparel <[email-masked]>
Date: Wed, 30 Sep 2009 11:26:59 +0530
To: =?UTF-8?B?0KHQsNGI0LAg0KHRgtCw0LzQtdC90LrQvtCy0LjRmw==?=
	<[email-masked]>
Cc: Justin Plock <[email-masked]>, 
	"[email-masked]" <[email-masked]>
Subject: Re: [zf-contributors] Re: Google Wave Invites

--000e0cd32f7e7116240474c53322
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Can u have 1 pl. [email-masked]

Sent from my iPhone

On 30-Sep-2009, at 11:25 AM, =D0=A1=D0=B0=D1=88=D0=B0 =D0=A1=D1=82=D0=B0=D0=
=BC=D0=B5=D0=BD=D0=BA=D0=BE=D0=B2=D0=B8=D1=9B <[email-masked]> wrote:

Me 2 - [email-masked]

Regards,
Sa=C5=A1a Stamenkovi=C4=87

On Wed, Sep 30, 2009 at 12:46 AM, Justin Plock <[email-masked]> wrote:

> I'll take one - [email-masked]
>
> Thanks!
>
> -Justin
>
>
> Graham Anderson wrote:
>
>> The first wave (pardon the pun) of mass invites for Google Wave are goin=
g
>> out tomorrow, people with existing accounts and new invitees will be
>> allocated 8 additional invites.
>>
>> If you don't already have a wave account and have *not* signed up to get
>> one, I'll send out my 8 invites in on a first come first served basis on
>> this list.
>>
>> Graham
>>
>
>

--000e0cd32f7e7116240474c53322
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><body bgcolor=3D"#FFFFFF"><div>Can u have 1 pl. <a href=3D"mailto:S.r=
[email-masked]"><a href=3D"mailto:[email-masked]">[email-masked]=
m</a></a><br><br>Sent from my iPhone</div><div><br>On 30-Sep-2009, at 11:25=
 AM, =D0=A1=D0=B0=D1=88=D0=B0 =D0=A1=D1=82=D0=B0=D0=BC=D0=B5=D0=BD=D0=BA=D0=
=BE=D0=B2=D0=B8=D1=9B &lt;<a href=3D"mailto:[email-masked]">umpirsky@gm=
ail.com</a>&gt; wrote:<br>
<br></div><div></div><blockquote type=3D"cite"><div>Me 2 - <a href=3D"mailt=
o:[email-masked]"><a href=3D"mailto:[email-masked]">umpirsky@gmail.=
com</a></a><br clear=3D"all"><br>Regards,<br>Sa=C5=A1a Stamenkovi=C4=87<br>
<br><br><div class=3D"gmail_quote">On Wed, Sep 30, 2009 at 12:46 AM, Justin=
 Plock <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"><a href=3D=
"mailto:[email-masked]">[email-masked]</a></a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex;">

I&#39;ll take one - <a href=3D"mailto:[email-masked]" target=3D"_blank"><=
a href=3D"mailto:[email-masked]">[email-masked]</a></a><br>
<br>
Thanks!<br><font color=3D"#888888">
<br>
-Justin</font><div><div></div><div class=3D"h5"><br>
<br>
Graham Anderson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The first wave (pardon the pun) of mass invites for Google Wave are going o=
ut tomorrow, people with existing accounts and new invitees will be allocat=
ed 8 additional invites.<br>
<br>
If you don&#39;t already have a wave account and have *not* signed up to ge=
t one, I&#39;ll send out my 8 invites in on a first come first served basis=
 on this list.<br>
<br>
Graham<br>
</blockquote>
<br>
</div></div></blockquote></div><br>
</div></blockquote></body></html>

--000e0cd32f7e7116240474c53322--

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 14:32:50 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

-- till <[email-masked]> wrote
(on Friday, 10 April 2009, 08:28 PM +0200):
> a general question -- will 2.0 raise the dependency PHP 5.3?

Most likely, yes. We're still deciding on the scope of 2.0. :)

> On Fri, Apr 10, 2009 at 8:24 PM, Matthew Weier O'Phinney
> <[email-masked]> wrote:
> > Greetings, all --
> >
> > Below is a proposal I am making to modify the Zend Framework Coding
> > Standards conventions for the naming of Interfaces and Abstract class=
es.
> >
> > This decision is basically already made, but I'd appreciate any feedb=
ack
> > that you may have on the matter.
> >
> > Thanks!
> >
> > The problem
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > PHP 5.3 introduces namespaces to the PHP language. While this won't h=
ave an
> > impact much on userland code, it will have an impact on library and f=
ramework
> > code, as it provides a useful paradigm for organizing components as w=
ell as
> > simplifying syntax. Instead of having to say things like:
> >
> > =A0 =A0$analyzer =3D new Zend_Search_Lucene_Analysis_Analyzer_Common_=
TextNum();
> >
> > we can instead do something like this:
> >
> > =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> > =A0 =A0$analyzer =3D new Common_TextNum();
> >
> > or even:
> >
> > =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
> >
> > =A0 =A0class Common_TextNum extends Common
> > =A0 =A0{
> > =A0 =A0}
> >
> > The problem that arises for Zend Framework has to do with how we name=
 abstract
> > classes and interfaces. Currently, the final segment of such classes =
are
> > expected to end with _Abstract and _Interface, respectively. This wil=
l not work
> > when we migrate to utilize namespaces, for two reasons.
> >
> > First, and most obviously, 'abstract' and 'interface' are reserved PH=
P keywords.
> > As such, in situations such as the following:
> >
> > =A0 =A0namespace Zend\Controller\Request;
> >
> > =A0 =A0class Abstract
> > =A0 =A0{
> > =A0 =A0}
> >
> > =A0 =A0// or:
> >
> > =A0 =A0namespace Zend\Controller\Dispatcher;
> >
> > =A0 =A0interface Interface
> > =A0 =A0{
> > =A0 =A0}
> >
> > we'll run into issues.
> >
> > Second, and less obvious, is that perhaps the easiest solution breaks=
 one of the
> > key principles of namespaces (which are designed to help encapsulate
> > components). This one's harder to explain, so let's look at examples.=
 Consider a
> > component such as Zend_Controller_Request. The simplest solution woul=
d be to
> > name the abstract class or interface Zend\Controller\Request, and the=
n have the
> > various concrete implementations under that namespace:
> >
> > =A0 =A0namespace Zend\Controller;
> >
> > =A0 =A0interface Request
> > =A0 =A0{
> > =A0 =A0}
> >
> > =A0 =A0// and concrete ones:
> >
> > =A0 =A0namespace Zend\Controller\Request;
> >
> > =A0 =A0class Http
> > =A0 =A0{
> > =A0 =A0}
> >
> > What's the problem here? The interface is not in the same namespace a=
s the
> > concrete implementations.
> >
> > Potential solutions and recommendation
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > So, how should Zend Framework "solve" these issues? A number of propo=
sals and
> > recommendations have been floated around, both within ZF circles and =
in the
> > greater PHP community.
> >
> > Considerations include:
> >
> > =A0* Avoiding the use of PHP reserved keywords (already noted).
> > =A0* Avoiding Hungarian Notation (i.e., having the name or a portion =
of the name
> > =A0 describe its type -- which, to a degree, the current naming conve=
ntions
> > =A0 already violate). (See http://en.wikipedia.org/wiki/Hungarian_Not=
ation, the
> > =A0 sections "Disadvantages of Systems Hungarian" and "Notable Opinio=
ns" for some
> > =A0 of the arguments against using Hungarian Notation.)
> >
> > Approaches that have been considered include:
> >
> > =A0* Using 'I' to prefix interfaces. This derives from standards in o=
ther
> > =A0 programming languages (.Net and python, in particular). This is j=
ust another
> > =A0 form of Hungarian Notation, however.
> >
> > =A0* Using "Interface" or "Abstract" as a class name suffix: RequestI=
nterface,
> > =A0 RequestAbstract. Again, however this is Hungarian Notation.
> >
> > =A0* Using the term "Base" for abstract classes: BaseRequest, Request=
Base, Base.
> > =A0 This is just substituting the word Base for Abstract, however, an=
d is really
> > =A0 not much different than the above.
> >
> > =A0* Use generic, descriptive names indicative of functionality or be=
havior. As
> > =A0 examples from the SPL, "Countable", "Iterator", "ArrayObject".
> >
> > My recommendation is to use the latter, as it solves all consideratio=
ns. It will
> > take more thought when naming, but will ensure that components can li=
ve in a
> > self-contained namespace, do not use reserved keywords, and avoid Hun=
garian
> > Notation.
> >
> > Plan for implementation
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > I recommend that the Coding Standards documentation be updated to ref=
lect this
> > approach.
> >
> > All new components going into 1.8 and onwards should adopt these stan=
dards. In
> > releases 1.9 and forward, we will begin migrating existing interfaces=
/abstract
> > classe. First, new classes/interfaces will be created that follow the=
se
> > conventions and which extend the originals; later, any type-hinting b=
ased on the
> > original class/interface names will be updated to point to the new na=
mes; and
> > finally, in 2.0, we will remove the old interfaces/abstract classes e=
ntirely.

--=20
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 8 Oct 2009 15:19:12 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Code Review

-- Whitcraft, Jon <[email-masked]> wrote
(on Thursday, 08 October 2009, 03:11 PM -0400):
> I have been thinking about the problem that ZF ran into right after 1.9.3 was
> release a few weeks ago and then we had to rush a 1.9.3pl1 into release.  Would
> using a tool such as Crucible from Atlassian help with this problem?
> 
> What does everyone else think?

In this case, it might not have helped.

There were no tests for the original behavior, and it was not documented
in the manual either -- it was only documented in passing within the API
docs.

We may use Crucible in the future (we actually have it setup already),
but I want to explore a few other options as well.

(My personal experience with Crucible has not been great, but I have
hope that it can be configured to work better.)

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 22 Sep 2009 14:01:47 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] Considering yanking 1.9.3 -- thoughts?

I'd like the opinion of the various contributors, if you could.

There's been a lot of debate about the BC break regarding
Zend_Db::factory(), and I'm even hearing rumblings about forks over it.
Putting all personal issues aside, I'd like to hear your thoughts about
how we should proceed.

First, I need to give some background about the situation we find
ourselves in, and not just from the code side.

On the code side, the matter is spelled out in the release announcement:

    http://dz.zend.com/a/10050

On the non-code side, we have a number of issues going on. 

First, on my side, I did not realize a BC break had occurred until this
morning -- and not from any official report in response to the sanity
check packages, but from an innocent post on fw-general. At that time,
we were already in progress deploying the packages and site updates.
For better or worse, re-packaging and releasing takes ~6-8 hours. It's
non-trivial, and this is why we do it on a schedule (what takes so long?
primarily building the manuals, building the API docs, and creating the
manual search indexes). 

Second, we have an added onus this week: our colo facility is being
relocated at the end of the week, and we have a very small window for
getting new packages released before we have to sync and do a site
freeze.

The options I can see are:

 * Yank the current package, and rebuild.
 * Create a patch-level package (1.9.3pl1), and deprecate 1.9.3.
 * Do nothing, and continue on.

I understand that many do not see original behavior as buggy, and relied
on it. I also feel that the new solution is much better -- but if
somebody can propose and implement a better one, I'm open to it.

I'd like to make a decision in the next few hours; if new packages are
needed, we need to make them ASAP. 

Please spread the word about this post and help in the process.

Thanks!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Mon, 12 Oct 2009 16:38:06 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Code Review

-- Trevor Johns <[email-masked]> wrote
(on Monday, 12 October 2009, 12:08 PM -0700):
> On Sat, Oct 10, 2009 at 11:04 AM, Matthew Ratzloff
> <[email-masked]> wrote:
> > > (My personal experience with Crucible has not been great, but I have
> > > hope that it can be configured to work better.)
> >
> > Unfortunately, Crucible is the best of the bunch.  Using it with FishEye is
> > basically a requirement, as is throwing several gigs of RAM at it.  Once you
> > do that, it's not that bad.
> > -Matt
> 
> My personal experience with Crucible has been pretty bad too. The
> problem isn't performance, it's the workflow.
> 
> Namely:
> 
> 1. The way we have Crucible setup, code reviews are started so that
> everybody on the project is invited to the review, which is totally
> impractical. If I just want to invite one person, I need to uncheck an
> ungodly number of checkboxes.

Yes, I ran into this as well. With a project the size of ZF... imagine
the pain...

> 2. It's not easy to do pre-commit reviews in Crucible, which I greatly
> prefer over post-commit reviews. There is a mechanism to upload a
> patch file, but that's done outside of SVN/Git. I don't believe
> there's any way to start a code review from my command line.

Well, the idea here would be for reviewing a trunk commit for
inclusion in the release branch and/or because of potential BC breakage.
I think pre-commit would be a bit unwieldy and introduce too much
overhead and complexity to the project.

The other issue I had with Crucible had to do with how comments were
relayed to the reviewees and peer reviewers: After each comment was
entered, an email was sent. This led to a ton of emails being sent in
many cases, or comments being deleted *after* an email was already sent.
I'd much prefer that we be able to send only when the reviewer has
finished the review.

> Personally, the best code review experience I've had is with Gerrit
> (review.source.android.com), with Rietveld (codereview.appspot.com)
> coming in second place.

I may look at those.

> That being said, I'd love to have a formal code review policy in place
> for ZF. I've had an unofficial policy in place for Zend_Gdata for a
> while now, since I work directly with most of the other committers on
> that module, and it's worked very well.

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 25 Mar 2009 00:30:46 +0100
From: till <[email-masked]>
To: Tobias Gies <[email-masked]>
Cc: Wil Sinclair <[email-masked]>, [email-masked]
Subject: Re: [zf-contributors] Release date for 1.8

Hush! :)

On Tue, Mar 24, 2009 at 11:17 PM, Tobias Gies <[email-masked]> w=
rote:
> *ahem*
>
> Even if it is not well-promoted (and, AFAIK, not archived) this
> mailing list is public - so I doubt your aim towards secrecy will last
> for too long.
>
> Anyways, I won't be the whistleblower. ;-)
>
> Best regards,
> Tobias
>
> 2009/3/24 Wil Sinclair <[email-masked]>:
>> Hi all, I=92m going to do something a little new for this release, but I=
 ask
>> that you all do me a favor in return. I=92m announcing the dates for the
>> release. The favor that I ask is that you do not discuss these dates out=
side
>> of this list. Yes, I know that the dates will likely get out anyways- I=
=92m
>> just asking you not to immediately go out and tweet/blog them. J Let=92s=
 try
>> to build some suspense with our users.
>>
>> With no further do:
>>
>>
>>
>> Preview Release on 4/7: All features going in to ZF 1.8 must be committe=
d by
>> EOD 4/5. We are currently working to get through all the pending proposa=
ls
>> by EOW, but feel free to ping me if you=92re concerned about a specific
>> proposal.
>>
>>
>>
>> Final Release on 4/28: Code freeze on 4/21. That=92s a hard-stop so have
>> everything ready to go by that date or be prepared to wait months for th=
e
>> next minor release.
>>
>>
>>
>> These dates won=92t be a death-march, but I do put a lot of effort in to
>> making sure that we don=92t miss dates that other teams within Zend or a=
t our
>> partners are depending on.
>>
>> Feel free to mail me directly if you have any concerns.
>>
>>
>>
>> Thanks! It will be an exciting next month or so.
>>
>> ,Wil
>

nFrom nobody Wed Apr  7 08:46:19 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Carlton Gibson <[email-masked]>
Date: Wed, 23 Sep 2009 14:29:51 +0100
Cc: Zend Framework Contributors <[email-masked]>
To: =?iso-8859-1?Q?P=E1draic_Brady?= <[email-masked]>
Subject: Re: [zf-contributors] Discussion about Quality/Review Process -
	Community RM proposal

--Apple-Mail-1-527484824
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1;
	format=flowed;
	delsp=yes

P=E1draic makes many fine points. I just want to pause on one:

On 23 Sep 2009, at 13:52, P=E1draic Brady wrote:

> Documentation is the least of the worries. Mostly it's accurate, but =20=

> it does need a fuller review at some point, or a deliberate restart =20=

> for Zend Framework 2.0. It's main problem is that it's written by =20
> developers (that will not change ;)) but also that it seems =20
> impervious to any form of iterative improvement. Once written, =20
> documentation rarely changes and any of its flaws become permanent =20
> problems that will very rarely ever reach the issue tracker.

[snip]

> Of course all of my meandering has one simple problem - how to =20
> motivate the community to actively take part and contribute their =20
> time and skill. Without that, it would all be doomed to failure =20
> anyway.

I know I've mentioned it before but having a wiki for the =20
documentation would (I think) make _many_ more people contribute.

The response previously was that we can't have a Wiki because of the =20
need to use Docbook. Having pondered this response I can't see that it =20=

follows. Wikis are about collaborative editing, Docbook is a markup/=20
storage format; surely the wiki could write to Docbook? (Does the =20
software for this not already exist? I'm sure we could knock it up in =20=

Rails in no time :-)

Regards,
Carlton
 =20=

--Apple-Mail-1-527484824
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>P=E1draic makes many fine points. I just want to pause on =
one:&nbsp;</div><br><div><div>On 23 Sep 2009, at 13:52, P=E1draic Brady =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"font-family: =
'times new roman', 'new york', times, serif; font-size: 16px; =
">Documentation is the least of the worries. Mostly it's accurate, but =
it does need a fuller review at some point, or a deliberate restart for =
Zend Framework 2.0. It's main problem is that it's written by developers =
(that will not change ;)) but also that it seems impervious to any form =
of iterative improvement. Once written, documentation rarely changes and =
any of its flaws become permanent problems that will very rarely ever =
reach the issue =
tracker.<br></span></blockquote><div><br></div><div>[snip]</div><div><br><=
/div><blockquote type=3D"cite"><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; font-family: Helvetica; font-size: =
medium; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" =
style=3D"font-family: 'times new roman', 'new york', times, serif; =
font-size: 16px; ">Of course all of my meandering has one simple problem =
- how to motivate the community to actively take part and contribute =
their time and skill. Without that, it would all be doomed to failure =
anyway.</span></span></blockquote></div><br><div>I know I've mentioned =
it before but having a wiki for the documentation would (I think) make =
_many_ more people contribute.&nbsp;</div><div><br></div><div>The =
response previously was that we can't have a Wiki because of the need to =
use Docbook. Having pondered this response I can't see that it follows. =
Wikis are about collaborative editing, Docbook is a markup/storage =
format; surely the wiki could write to Docbook? (Does the software for =
this not already exist? I'm sure we could knock it up in Rails in no =
time =
:-)&nbsp;</div><div><br></div><div><div>Regards,</div><div>Carlton</div></=
div><div>&nbsp;</div></body></html>=

--Apple-Mail-1-527484824--

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 12 Jul 2009 14:46:39 +0200
From: =?UTF-8?B?0KHQsNGI0LAg0KHRgtCw0LzQtdC90LrQvtCy0LjRmw==?=
	<[email-masked]>
To: Benjamin Eberlei <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend_Entity & Zend_Db_Mapper ready for 
	recommendation

--001636af0342c3a0d7046e81988b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Great work!

Exactly what is missing in zf. I hope it will be possible to automatiic
generate mappings from db schema.

Regards,
Sa=C5=A1a Stamenkovi=C4=87

On Sun, Jul 12, 2009 at 1:26 PM, Benjamin Eberlei <[email-masked]>wrot=
e:

> Hello everyone,
>
> after a very long feedback phase from the community (and me having proble=
ms
> with time also) I finished lots of refactoring and API redesign on the
> Entity &
> Mapper components (which go hand in hand).
>
> What I now ended up with is an API that somewhat follows the EJB 3.0
> specification, but has some PHP and Zend specific features to match.
> Details of
> the API are still not finished and further exploration might make me
> refactor
> the whole thing for the 100st time, but I think it is "finished enough" t=
o
> go
> to ready for recommendation.
>
> I updated the proposal a bit with more requirements and details in
> description. I also removed the large example and just point to the SVN
> where
> two integration test-cases are currently residing.
>
> http://framework.zend.com/wiki/pages/viewpage.action?pageId=3D9437243
>
> Furthermore I refactored alot in these last days and hope to get some
> additional feedback on the current API :-)
>
> greetings,
> Benjamin
> --
> Benjamin Eberlei
> http://www.beberlei.de
>

--001636af0342c3a0d7046e81988b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Great work!<br><br>Exactly what is missing in zf. I hope it will be possibl=
e to automatiic generate mappings from db schema.<br clear=3D"all"><br>Rega=
rds,<br>Sa=C5=A1a Stamenkovi=C4=87<br>
<br><br><div class=3D"gmail_quote">On Sun, Jul 12, 2009 at 1:26 PM, Benjami=
n Eberlei <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">kont=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8=
ex; padding-left: 1ex;">
Hello everyone,<br>
<br>
after a very long feedback phase from the community (and me having problems=
<br>
with time also) I finished lots of refactoring and API redesign on the Enti=
ty &amp;<br>
Mapper components (which go hand in hand).<br>
<br>
What I now ended up with is an API that somewhat follows the EJB 3.0<br>
specification, but has some PHP and Zend specific features to match. Detail=
s of<br>
the API are still not finished and further exploration might make me refact=
or<br>
the whole thing for the 100st time, but I think it is &quot;finished enough=
&quot; to go<br>
to ready for recommendation.<br>
<br>
I updated the proposal a bit with more requirements and details in<br>
description. I also removed the large example and just point to the SVN whe=
re<br>
two integration test-cases are currently residing.<br>
<br>
<a href=3D"http://framework.zend.com/wiki/pages/viewpage.action?pageId=3D94=
37243" target=3D"_blank">http://framework.zend.com/wiki/pages/viewpage.acti=
on?pageId=3D9437243</a><br>
<br>
Furthermore I refactored alot in these last days and hope to get some<br>
additional feedback on the current API :-)<br>
<br>
greetings,<br>
Benjamin<br>
<font color=3D"#888888">--<br>
Benjamin Eberlei<br>
<a href=3D"http://www.beberlei.de" target=3D"_blank">http://www.beberlei.de=
</a><br>
</font></blockquote></div><br>

--001636af0342c3a0d7046e81988b--

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: <[email-masked]>
Date: Fri, 1 May 2009 18:27:56 +0200
Subject: Re: [zf-contributors] ZF has mostly integration-tests, no unittests

Some notes:
Why should I use getMock() when there is no need to mock any data? For 
example, within Zend_Date there is no adapter and no need to use mocks.

It should also be mentioned that not all unittests are written to have only 
"code coverage" at 80%.
Take a look at Zend_Date's unittests for example. I think it's actually the 
biggest testbed and I think it's also the reason why there are not much 
issues for Zend_Date.

Regarding test-driven:
My opinion is that we should not force how developers are coding. Using only 
test-driven could also lead to problems. Not all people are conform with 
this style of coding. And if they are not well thought of, this could also 
lead to a massive overhead.

I agree that the unittests for several components seem to be useless. But 
you should also note the only having more or better unittests does not mean 
that there are less issues. Issues are not always bugs but also improvements 
or new features. And several components in core are missing a lead which 
means that they are loosly supported.

Having a component with many bugs is in my eyes only a indicator that this 
component is eighter actually unsupported or that the author has not much 
time.

My 2 eur. :-)

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Benjamin Eberlei" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 01, 2009 3:30 PM
Subject: [zf-contributors] ZF has mostly integration-tests, no unittests

> Running a grep on the function 'getMock' of phpunit in the Zend Framework 
> code
> basis shows that there are exactly 13 calls. Running any single testsuite
> shows that tests mostly depend on several other components, who depend on
> other components and so on.
>
> Tests are for defect localization, otherwise they are integration tests 
> and
> produce a large set of unmaintainable test-code which bites any component 
> lead
> in the back some day.
>
> We should maybe revisit our testing-strategy and enforce test-driven
> development on new components, additionally old unittests should be 
> refactored
> to be more unittest like and not general tests that are build after the 
> fact
> and only by tricking get to > 80% code-coverage . Any Ideas on how to 
> improve
> test-code? Its totally going to get back at us.
>
> For example look at Zend_Service_Amazon_OnlineTest. It talks to amazon for 
> ALL
> its tests and asserts nothing. Still if you for example only run the
> "testItemSearchPhp" test you get a coverage of 76%! This is just bullhist!
>
> Many ZF testsuites are that bad. They dont really test much and produce 
> false
> comfort. The high number of bugs in many of the components are an 
> indicator
> that there is something wrong somewhat.
>
> greetings,
> Benjamin
>
> -- 
> Benjamin Eberlei
> http://www.beberlei.de 

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Dolf Schimmel <[email-masked]>
Date: Sat, 23 Jan 2010 00:29:10 +0100
To: Thomas Weidner <[email-masked]>
Cc: [email-masked]
Subject: Re: [zf-contributors] Zend_Date & build-in class DateTime

Thomas,

Do I understand correctly that as of ZF2.0 (which uses php5.3 and
above) you plan on utilizing DateTime in Zend_Date?

Dolf

On Sat, Jan 23, 2010 at 12:24 AM, Thomas Weidner <[email-masked]> wr=
ote:
> This has been discussed several times in past and the answer is still the
> same.
>
> "As long as ZF uses minimum required PHP Versions where DateTime is not
> available per default (without changing configuration after installation)=
 we
> will not change the I18n core."
>
> Additionally the method "getTimestamp" you referred to is available per P=
HP
> 5.3.0. It was not available in DateTime below this PHP release.
>
> Greetings
> Thomas Weidner, I18N Team Leader, Zend Framework
> http://www.thomasweidner.com
>
> ----- Original Message ----- From: "Marc Bennewitz"
> <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, January 22, 2010 11:16 PM
> Subject: [zf-contributors] Zend_Date & build-in class DateTime
>
>
>> Hi all,
>>
>> Does is matter that Zend_Date doesn't extends the build-in DateTime clas=
s
>> ?
>> -> The DateTime class is available since PHP 5.2.0 and ZF require PHP
>> 5.2.4.
>>
>> It would be very nice because than Zend_Date would be compatible to
>> other php libraries using DateTime and within ZF tests like the
>> following can simplify:
>>
>> if ($date instanceof Zend_Date_DateObject) {
>> =C2=A0 $timestamp =3D $date->getUnixTimestamp();
>> } elseif ($date instanceof DateTime) {
>> =C2=A0 $timestamp =3D $date->getTimestamp();
>> } else {
>> =C2=A0 $timestamp =3D (float)$date;
>> }
>>
>> Greetings,
>> Marc
>>
>
>

nFrom nobody Wed Apr  7 08:46:20 2010
To: Matthew Weier O'Phinney <[email-masked]>
Subject: Re: [zf-contributors] Plugin implementations
Date: Wed, 31 Mar 2010 17:57:36 +0200
From: Benjamin Eberlei <[email-masked]>
Content-Length: 2442

Hey Matthew,

Hm, my 2 cents on this issue, all magic method calls are automagically
at least 2 times slower than a direct method invocation. Is this really
necessary given that plugins will probably be used in the hundrets to
thousands during a request?

Additionally although its nice to know that all plugins use __invoke
you still interface them (as you mentioned in your post),
which is a much more restrictive constraint programming wise. IDEs
will even auto-complete you the methods for implementing interfaces.
You need to know the interface name anyways to be able to build
the plugin, it doesn't really help you to know that one of the methods
is called __invoke.

In the light of this, I don't see the benefit of using __invoke at all.

greetings,
Benjamin

On Wed, 31 Mar 2010 10:21:52 -0400, Matthew Weier O'Phinney
<[email-masked]> wrote:
> Greetings, all --
>=20
> Per the roadmap, one change we're planning on making is making plugin
> usage consistent across components: plugins will implement __invoke(),
> which makes them inherently callable.
>=20
> In our refactoring branch, I've done this now with Zend_Filter. However=
,
> it required a ton of refactoring on the unit tests (had to either call
> __invoke() directly, or $filter($value)), and it got me to thinking:
>=20
> Would it make sense to keep the original interfaces (filter, isValid,
> render, etc.), but also implement __invoke() -- having it proxy to the
> appropriate interface method?
>=20
> As an example:
>=20
>     interface Filter
>     {
>         public function filter($value);
>         public function __invoke($value);
>     }
>=20
>     class Digits implements Filter
>     {
>         public function filter($value)
>         {
>             // ... logic...
>         }
>=20
>         public function __invoke($value)
>         {
>             return $this->filter($value);
>         }
>     }
>=20
> The benefits:
>=20
>  * Fewer changes necessary to existing unit tests
>  * interface method names may be more descriptive of intent
>=20
> Problems:
>=20
>  * Using __invoke() introduces overhead -- 2 method calls instead of on=
e
>  * Redundancy (two methods doing the same thing)
>  * A few extra tests to write (to ensure __invoke works as expecte)
>=20
> After discussion with Ralph and Alex, I'm leaning towards having
> __invoke() as an _additional_ method, instead of replacing existing
> methods.
>=20
> Any thoughts or comments?

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 28 Aug 2009 07:18:07 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Discussions of the possible Query API in
	Zend_Entity

-- Benjamin Eberlei <[email-masked]> wrote
(on Friday, 28 August 2009, 08:41 AM +0200):
> good point, but in my opinion not compelling on second sight. Both
> ORMs are active record implementations.
> 
> Since yesterday propel is not being actively maintained anymore, so
> this will not necessarily be an option for large new projects anymore.
> 
> Doctrine is being completly rewritten for the 2.0 release, because
> they are unhappy with the current internals and everything, so
> although they clearly have the expertise the solution is not yet
> finished either.

In addition, Doctrine 2.0 will be PHP 5.3 *only* -- which means for
those not yet able to upgrade to 5.3.x, it will be a non-option.

I have been in discussions with them to do some integration, but the
question at this point is _when_. Doctrine 2.0 is well underway, and,
based on the current rate of development, I could see it being released
before the end of the year. If we aim for integration now, we would have
to integrate with a 1.x version -- meaning that for those who *do* have
access to 5.3, they'd be unable to use our integration and also use
Doctrine 2; for us, it would mean completely rewriting the integration
once we jump to our own 2.0 version.

I think we may still have some more lightweight integration points we
can introduce, but it's a tricky situation right now.

> As for a Zend ORM, the abstraction is already implemented. Its not on
> a very high level, so other implementations except RDBMS still have to
> go a long way, however they can make use of a range of data mapping
> utilities. The question of my post was, in which way do i make the
> differences in Query API between different storages explicit.
> 
> Personally i guess competition never hurts anyone. :-)

And this is precisely where I see Zend_Entity offering an *alternative*
to Doctrine. I'd like to see options for both within ZF. Doctrine is
well-established and has significant mindshare; having integration with
the project makes it easy for developers to migrate to ZF if they've
already written their models in Doctrine. Having a ZF-specific ORM
solution offers the ability to take advantage of ZF's i18n, caching,
etc. One specific area where I like Ben's proposal is that it's abstract
enough to allow for non-RDBMS storage -- something that would be very
difficult to accomplish with Doctrine currently. I've played a fair bit
with some of the new document databases, and they offer some flexibility
that makes many CMS tasks *soooo* much easier.

Ben, I'll answer your email in a separate reply.

> On Friday 28 August 2009 01:34:54 am Rafael Dohms wrote:
> > Guys,
> >
> > Just a quick notice and question.
> >
> > Isn't this an area where ORMs like Doctrine have already mastered
> > solutions? aren't they rather easy to integrate into Zend Framework?
> > Wouldnt it be easier to provide interaction points to doctrine, propel and
> > others instead of bulging ZF with all stuff needed to fully abstract all
> > databases and storage stuff.
> >
> > Sorry if this is waaay out of line, but its just seems to heavy an area to
> > include.
> 
> 
> -- 
> Benjamin Eberlei
> http://www.beberlei.de
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Cc: [email-masked]
From: Carlton Gibson <[email-masked]>
To: "Matthew Weier O'Phinney" <[email-masked]>
Date: Sun, 26 Jul 2009 18:59:58 +0100
Subject: Re: [zf-contributors] Zend_Service_Amazon API Upgrade + Services to
	ZendX Proposal

Hi Matthew,

On 26 Jul 2009, at 16:29, Matthew Weier O'Phinney wrote:

> We need more community help in maintaining the framework. I have some
> ideas on how to achieve this, but I need *your* ideas as well, as
> contributors.

  From my experience it's really hard to get started helping out, even  
if you want to.

I don't have (or haven't yet had) the time (or indeed perhaps  
skill :-) to be taking on the lead on major components, but I have had  
some time to work on something. What I found though was that it wasn't  
very clear where or how to start.

I think there needs to be a much clearer and easier to follow route  
into helping out. (Something like the Post Office "Help Wanted" board  
in Paper Mario would be great.) The issue tracker works but it takes  
too much time to learn. (95% of the time and energy I have had  
available has been spent on the issue tracker rather than actually  
doing anything. Admittedly I'm slow, but I doubt I'm alone.)

I also think the documentation needs to be moved to a wiki format. A  
lot of the complaints on the mailing list concern the documentation --  
so let people fix it themselves. (Again, I've often thought about  
suggesting a fix to the docs but am put off by the thought of having  
to take on the issue tracker for the sake of a single sentence or  
paragraph.)

Finally, I think there needs to be a place (the contributors list  
maybe) where people are welcome (encouraged) to come with questions  
about how to proceed with an issue. Not enough people are subscribed  
to each issue in the tracker to make this viable there. (Perhaps this  
is what the contributors list is for but if so that needs to be better  
advertised.)

Just ideas.

(I've got some time next month and I'm going to give Benjamin a hand  
with Zend_Entity, so I'm not just complaining and expecting you to do  
it :-)

Regards,
Carlton

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 18 Nov 2009 17:28:37 +0100
To: [email-masked]
From: Lars Kneschke <[email-masked]>
Organization: Metaways Infosystems GmbH
Subject: Re: [zf-contributors] Zend_json_Client or How to start contributing

"Matthew Weier O'Phinney" <[email-masked]> schrieb:
> -- Lars Kneschke <[email-masked]> wrote
> (on Wednesday, 18 November 2009, 08:29 AM +0100):
>> For our project Tine 2.0, we implemented Zend_Json_Client. It's =
modelled
>> after
>> Zend_XmlRpc_Client and I would like to contribute it.
>>=20
>> I signed the CLA. That was easy. But now I'm searching for the best, to
get
>> in
>> contact with right person to merge my work with the existsing
>> Zend_Json_Server
>> codbase.
>>=20
>> The code is available at
http://svn.tine20.org/svn/trunk/tine20/Zend/Json/ .
>>=20
>> We also have extended Zend_Json_Server to handle batched request.
>>=20
>> What is the right way to move forward on this issue?
>> What is the right way to discuss the needed changes with the maintainer
of
>> Zend_Json?
>=20
> For Zend_Json_Client, you will need to go through the proposal process;
> information is available on the wiki:
>=20
>     http://framework.zend.com/wiki/display/ZFPROP/Home
>=20
> (I'm looking forward to this -- it's a component that's been on my
> "todo" backlog for many, many months!)
Then we should be able clean up your backlog a little bit. :-)

> As for the batched request support for Zend_Json_Server, the best way to
> handle that is to add a feature request to the issue tracker
> (http://framework.zend.com/issues), along with a patch that provides
> both the new functionality as well as unit tests for it; bonus points if
> you can provide documentation on it as well.
>=20
> I'm the maintainer of Zend_Json, so ping me if you have questions or
> suggestions on it.
That's goo to know.=20

I'll start the process of bringing the code to ZF probably next week.

--
Lars Kneschke
Team Leader Business Solutions
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

Tine 2.0 now with Calendar, Email and ActiveSync=3D> =
http://www.tine20.org/

E-Mail: mailto:[email-masked]
Web: http://www.metaways.de
Tel: +49 (0) 40 317031-21
Fax: +49 (0) 40 317031-921
Mobile: +49 (0) 175 9304324

Metaways Infosystems GmbH - Sitz: D-22967 Tremsb=C3=BCttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Gesch=C3=A4ftsf=C3=BChrung: Hermann Thaele, L=C3=BCder-H.Thaele

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Sun, 5 Jul 2009 22:48:41 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Two Proposals Ready for Review

-- P=C3=A1draic Brady <[email-masked]> wrote
(on Sunday, 05 July 2009, 12:22 PM -0700):
> How far away is a 2.0 release? It seems reasonable to assume the
> current release frequency will continue until 2.0 is ready for
> release. Even then, there is scope for fixing 1.x release bugs and
> security issues into the future.  I always assumed we'd see 1.11,
> 1.12, ..., 1.34 until support was officially ended for 1.x. Matthew
> stated a few weeks ago to another query that 2.0 was in early
> planning.

I'm currently collating a list of features from the issue tracker as
well as on the ZF team's wishlist that would require either PHP 5.3
and/or BC breaks. Additionally, I'm trying to come up with a list of
features that would provide a compelling reason to upgrade -- PHP 5.3
support alone will not be compelling for many users, particularly if it
means their existing code now must be refactored. New features such as
full-fledged Doctrine integration (I've been in discussions with the
Doctrine developers recently) and a pub-sub system for event-driven
architectures (something I've been playing with the past six months)
could, however, sway more people to switch.

To that end, we're also contemplating the possiblity of maintaining the
1.x branch for some time after 2.0 has been released. The last minor
release before 2.0 will be the last minor release on the 1.X branch,
however, and we would only see mini releases thereafter, primarily for
critical bug and security fixes. The last minor release would also
potentially be a stepping stone for migration, back-porting some
features from 2.0 in order to make the switch easier for those with
larger code bases.

Yes, there *will* be a 1.10, and very likely a 1.11. I'm not sure if
we'll go beyond that.  It depends on how much effort will be required
for 2.0 (based on the scoping I'm doing now). I'd prefer for it not to
be a long, drawn-out process, as the longer it goes, the longer we
need to maintain the 1.X series -- and the less effort available for
moving forward.=20

> =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=
> From: Ralf Eggert <[email-masked]>
> To: Benjamin Eberlei <[email-masked]>
> Cc: [email-masked]
> Sent: Sunday, July 5, 2009 4:56:21 PM
> Subject: Re: [zf-contributors] Two Proposals Ready for Review
>=20
> Thanks Benjamin,
>=20
> Benjamin Eberlei schrieb am 05.07.2009 17:31:
> > to my knowledge there will definately be a 1.10, and even a slight ch=
ance
> that
> > there will be a 1.11
>=20
> Ok, but will 2.0 be published after 1.10 or 1.11. or will be both major
> release be managed parallel?
>=20
> Thanks and best regards,
>=20
> Ralf

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 20 Jan 2010 11:52:32 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend_Grid component proposal

-- Mihai Bojin <[email-masked]> wrote
(on Wednesday, 20 January 2010, 06:25 PM +0200):
> That's subject to a different proposal
> http://framework.zend.com/wiki/display/ZFPROP/
> Zend_Dojo+-+dojox.grid.DataGrid+Support+-+Matthew+Weier+O%27Phinney
> 
> that will actually be a View Helper.
> 
> 
> My proposal intends to be a Zend Framework component that will be able to
> generate grids of data rendered in HTML. The target is mainly admin panels, but
> I will probably provide a way to render a grid using a partial.
> That will mean that Zend_Grid will be able to be used for rendering any type of
> two-dimensional data (mostly SQL table data and arrays).

Actually, there may be some overlap; I need to review your proposal some
more, and also review the changes to DataGrid in recent Dojo versions
before I can say for sure, however.

> On Jan 20, 2010, at 6:02 PM, Giorgio Sironi wrote:
> 
> 
>     On Wed, Jan 20, 2010 at 2:55 PM, Mihai Bojin <[email-masked]> wrote:
> 
>         Hello Everyone,
> 
>         I submitted a proposal for review and right now I'm waiting for any
>         suggestions, advice, opinions and so on :)
> 
>         You can check out the proposal here:
>         http://framework.zend.com/wiki/display/ZFPROP/Zend_Grid+-+Mihai+Bojin
> 
>         Any feedback will be greatly appreciated !
> 
> 
> 
>     Do you intend to take advantage of Zend_Dojo? There is a dojo component
>     named Datagrid which takes a lot of work to integrate currently, and that
>     would be a nice feature.
> 
>     --
>     Giorgio Sironi
>     Piccolo Principe & Web Engineer
>     http://giorgiosironi.blogspot.com
>     http://twitter.com/giorgiosironi
> 
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Thu, 12 Nov 2009 14:41:29 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

-- Kevin McArthur <[email-masked]> wrote
(on Thursday, 12 November 2009, 10:32 AM -0800):
<snip>
> The Bad:
> 
> 1 ) Unified constructor. All constructors will (optionally) accept an array of
> options or Zend_Config object as the first argument.
> 
> I take exception to this because, well, it's just going to kill performance --
> and it doesn't follow industry standard techniques for this type of thing. This
> shouldn't be a rule as a ton of classes have no reason to be configurable, or
> make a lot more sense to take real parameters, rather than instantiating a new
> object. Instead, I recommend a Configurable interface which _may_ mark classes
> as configurable as needed.

That makes sense, and I'm open to that. 

That said, if a component has dependencies on other components or makes
use of other components, I think the pattern should be mandatory.
Dependency Injection -- note, I'm NOT saying DI containers -- is much
simpler with this pattern.

> 2 ) Exception interfacing
> 
> Why mess with it? All the SPL exceptions descend from Exception and can be
> caught/thrown as any normal exception can be. Exceptions should continue to
> contain the Exception class inheritance hierarchy.

The rationale is because it allows us to catch either based on the SPL
exception type OR the component exception type. It's more flexible.

Each component Exception would inherit from the zend\Exception marker
interface -- so, again, there'd still be the Exception inheritance
hierarchy, but also a hierarchy for general purpose exceptions.

Finally, the paradigm encourages creating exceptions for each type of
exceptional situation, instead of having a generic exception per
component. This will make debugging easier, as well as 

As an example, using an SPL-based exception:

    try {
        throw new InvalidArgumentException();
    } catch (\zend\foo\Exception $e) {        // or
    } catch (\zend\Exception $e) {            // or
    } catch (\InvalidArgumentException $e) {  // or
    } catch (\Exception $e) {
    }

All are viable - it gives you, the developer, more choices in how you
handle exceptions.

> From the markup:
> 
> try { 
>     throw new InvalidArgumentException(); 
> } catch (\Foo\Bar\Exception $e) { 
> } 
> 
> Can just be:
> 
> try { 
>     throw new InvalidArgumentException(); 
> } catch (Exception $e) { 
> } 
> 
> Without the marker interface. I must be missing something?

Yes. See above.

> 3) Design By Contract
> 
> I'm actually a big fan of contract programming, but, a framework must be fast
> -- and optimized. Contract programming is great as part of business process
> management, but it has serious runtime performance implications -- and worse,
> increases contribution overhead. Makes testing, acceptance testing easier,
> sure. But this could be realllllly limiting.

Ummmmm.... I don't think we're talking about the same thing here.

Design by contract, in its most simplified form, refers to the idea of
programming to interfaces. This simply means that we'll be ensuring that
we have solid, concise interfaces for each component, which will allow
developers to create their own implementations when they're needs
deviate from those shipped.

This actually will have some substantial benefits. First, we can have a
more conventions based approach, which allows us to develop more
targetted, performant code since we're no longer worrying about edge
cases created by configurability. This brings me to my second point: it
pushes the burden of custom and fringe use cases onto individual
developers instead of the framework -- which allows us to focus on
maintaining the core functionality. This will lead to a better product
with fewer open issues. Third, it makes testing much easier,
particularly when considering components with adapters -- you can
implement a given interface in order to test the functionality instead
of needing to override an existing class.

In terms of contribution overhead, it means that part of any component
design will be ascertaining the basic, essential functionality and
creating an interface that encapsulates it; this is just good
programming.

Basically, everything you cite as potential problems are actually
addressed with this decision.

> 4) Getting rid of singletons.
> 
> Why does it make more sense to access the front controller via a registry?
> Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier
> to pick up the framework.

We're not accessing the front controller via a registry. It's simply not
going to be a singleton. The ideas posted use injection to pass objects
around, and do so in a very simple manner. Take a look at the
proof-of-concept I posted before jumping to conclusions.

Singletons have been the source of a ton of pain in testing and
bugfixing -- and there's very little reason for most of them to exist.

> The Ugly:
> 
> The proposed changes to the core api (and to a large extent the framework
> additions since 1.0) really add complexity to the framework to the benefit of
> testing and other 'advanced' use. 

We're getting rid of complexity and focussing on a simplified,
consistent API. I fail to see how you're reaching your conclusions.

> These changes do little, if anything to advance three goals I see as
> core requirements for 2.0:
> 
> a) Can a skilled PHP developer read and understand Zend Framework application
> code without more than an hour's primer on ZFW? Could they trace execution of
> the framework logically without a debugger? Jumps like GOTO's, fancy routers,
> registries, helpers, plugins, and DI models all work against this goal. Keep it
> simple.

Please, please, please read the code and examples before you make these
assumptions.

The new MVC design is not going to be something a developer will need to
understand in order to use it; they will simply need to *use* it. They
won't need to know that it uses a finite state machine under the hood --
they'll only need to know what events and states are available (and
there's *ahem* a finite number of them). Tracing the code execution
should rarely be necessary, but the new prototype is actually far, far
simpler than the current Zend_Controller execution cycle.

(Aside: the router is not likely changing much, except internally.)

> b) Can a skilled PHP developer contribute a change to the framework easily
> without being involved in the ZFW core politics, contribution processes,
> proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for
> this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to
> reduce the contribution overhead and encourage community participation?

Please elaborate on how "ZFW sucks for this."

Our policy has been that contributions require unit tests and
documentation, plain and simple. Yes, it's a barrier to entry -- but it
also helps to ensure the quality of the code and that users have the
information they need to use it. If we don't require that level of
contribution, we'll be doing everyone a dis-service.

Right now, there really are no "core politics". Everything goes through
the contribution process. Yes, myself and my team help determine the
roadmap -- but even the roadmap is open for discussion. This is open
source.

> c) Can a ZFW developer create products and services that leverage ZFW in an
> ecosystem of components? Is there a financial incentive for this? Currently,
> there's very little going on in terms of commercialized redistributable
> components -- How will ZFW 2.0 create, and integrate itself into a marketplace
> for ZFW apps, components, and tools? Official ZFW app/component store? ZFW
> cloud services?

My team has had zero time to focus on a forge-like site for components,
though it's something we'd all like to see.  A large part of the reason
for our lack of time is due to the amount of maintenance required on ZF.
Most of the changes proposed for 2.0 are intended to lighten that
burden, which would make the above much more possible in the future.

> The Atrocious:
> 
> Still nothing about an upgrading / security patches system. 

This is my bad -- I meant to include information on this as part of the
proposal. A big effort for 2.0 will be creating resources to aid in
migration. A big part of the MVC proof of concept was creating something
that could live side-by-side the current implementation and potentially
even make use of it (the demo uses a number of existing components).
We're taking that very seriously.

As for security patches, the plan is to patch existing stable code, as
well as the previous 2 minor branches, and make releases of each.

> Still no components for detecting if an application is vulnerable,
> notifying system admins, or shutting down an installed base of
> vulnerable apps dependent on the framework.  If the problems of the
> other major framework and cms vendors continue to be ignored, there
> will almost certainly be some sort of incident that will tarnish the
> frameworks reputation for security. At some point the framework is
> going to have to take version management more seriously than
> publishing patches to the website (a good first step, but miles away
> from where it needs to be).

If you're interested in such components, then please help make them a
possibility. Don't expect everyone else to do the work for you. As
noted, my team is small and our resources spread thin. Help us and the
rest of the community out.

> --
> 
> I'd also add that there's probably an opportunity to look at phar-ization
> within the 2.0 line. Will the new loader support phar'd components, and how
> will that look? Zend_Tool? Configurable site images?

I've already experimented with Phar and ZF 1.X. It requires minimal
changes to the autoloader for it to work out of the box.

> I'm sure theres more, but thats my $0.02 for now
> 
> Kevin McArthur
> 
> 
> Matthew Weier O'Phinney wrote:
> 
>     Hey, all --
> 
>     There have been a ton of questions about the ZF 2.0 roadmap, and my
>     answer has been consistently, "I'm working on it; I'll have something to
>     publish soon."
> 
>     "Soon" is now:
> 
>         http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
> 
>     I'd like you, as contributors, to look over it, and start discussing the
>     various ramifications; we can do that either in comments to the pages or
>     on this list.
> 
>     The roadmap is primarily a conceptual one right now, though a
>     proof-of-concept has been created for the proposed MVC. I'd like to stay
>     fairly high-level for now, and then start getting a flow of proposals
>     into the system for specific migration-related tasks.
> 
>     Thanks everyone who has provided me input over the past many months, and
>     let's get started on the next generation of ZF!
> 
> 
> 
> 

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 31 Mar 2010 16:42:26 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Plugin implementations

-- Thomas Weidner <[email-masked]> wrote
(on Wednesday, 31 March 2010, 10:04 PM +0200):
> -1 from me
>=20
> I see no benefit of having 2 methods doing the same work
>=20
> Additionally forcing __invoke() means that ZF does no longer work
> below PHP 5.3.
> Even if we limit ZF 2.0 to 5.3 it does not mean that single
> components are not able to work below 5.3.

Thomas, you're forgetting one really important thing here: ZF 2 will
*not* work on versions less than 5.3 anyways, due to the fact that all
code will be using namespaces. ;-)

> And working with OOP I see no benefit of using objects by calling
> them as function. It's like a step backwards from OOP.

Not necessarily. For purposes of plugins, strategy patterns, command
patterns, etc., the main purpose is to provide a single method that is
invoked by the caller. For purposes of consistency, it makes sense for
all classes in the framework that implement these sorts of patterns to
follow the same general API. While we could do something like "execute"
or "run" as the method, PHP's __invoke() fulfills the same sort of
purpose on the language level. Additionally, unlike using functions, you
have the benefits of state -- you can pass arguments to the constructor,
or call other methods to configure the object prior to "invoking" it.
This is far from a step backwards from OOP -- it's simply a different
pattern for using OOP in PHP.

> ----- Original Message ----- From: "Lukas K=F6ll" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, March 31, 2010 9:38 PM
> Subject: Re: [zf-contributors] Plugin implementations
>=20
>=20
> -1 from me, too - I'm totally agreeing with Renan.
> Additionally I don't think design decisions should be based on how
> much work it
> is to write the corresponding unit tests. Don't get me wrong, of
> course the code
> must be testable. But especially for framework code I think that a
> low overhead
> should be preferred against easier testability - infact framework code =
is
> written (or changed) far more seldom than executed.
>=20
> If, however you decide to use __invoke as proxy, I would recommend
> to somehow
> prevent the proxied methods (filter, validate) to be called from
> outside or at least mark them as deprecated
> so client code _must_ use invoke and we could then remove the
> proxies later on if
> it should be decided that the tests are rewritten.
>=20
> best regards
>=20
> Lukas K=F6ll
>=20
> >-1
> >
> >Talking to my coworkers, a big piece of people take a little more time
> >to understand something when there is more than one way to do what
> >they want to do. I think that when we start a new project with
> >unnecessary duplicated features it's not good. This usually happens
> >after years, we should get this situations away. Obviously sometimes
> >it's interesting we provide alternative ways to achieve a goal, but
> >for those situations  (filter, validator...) it's not.
> >
> >>>The benefits:
> >>>
> >>>* Fewer changes necessary to existing unit tests
> >
> >time is the solution ;-)
> >
> >>>* interface method names may be more descriptive of intent
> >
> >they should pick a better name for their variables, like $filterFloat,
> >$filterAlpha
> >
> >>>Problems:
> >>>
> >>>* Using __invoke() introduces overhead -- 2 method calls instead of =
one
> >>>* Redundancy (two methods doing the same thing)
> >
> >that's my point! this extra way is not relevant, this one adds no
> >new feature
> >
> >>>* A few extra tests to write (to ensure __invoke works as expecte)
> >
> >my 1 cent ;-)
> >
> >--
> >Renan de Lima Barbosa
> >gtalk/msn: [email-masked]
> >skype: renandelima
> >+55 61 8166-7755
> >renandelima.com
> >
> >
> >
> >On 31 March 2010 11:38, Dennis Winter
> ><[email-masked]> wrote:
> >>+1 on this! It's ok to have two methods for the same thing! And
> >>the benefit
> >>of clearer interfaces is overwhelming the disadvantages!
> >>Just my 2 cents!
> >>
> >>Am 31.03.2010 um 16:21 schrieb Matthew Weier O'Phinney
> >><[email-masked]>:
> >>
> >>>Greetings, all --
> >>>
> >>>Per the roadmap, one change we're planning on making is making plugi=
n
> >>>usage consistent across components: plugins will implement __invoke(=
),
> >>>which makes them inherently callable.
> >>>
> >>>In our refactoring branch, I've done this now with Zend_Filter. Howe=
ver,
> >>>it required a ton of refactoring on the unit tests (had to either ca=
ll
> >>>__invoke() directly, or $filter($value)), and it got me to thinking:
> >>>
> >>>Would it make sense to keep the original interfaces (filter, isValid=
,
> >>>render, etc.), but also implement __invoke() -- having it proxy to t=
he
> >>>appropriate interface method?
> >>>
> >>>As an example:
> >>>
> >>>  interface Filter
> >>>  {
> >>>      public function filter($value);
> >>>      public function __invoke($value);
> >>>  }
> >>>
> >>>  class Digits implements Filter
> >>>  {
> >>>      public function filter($value)
> >>>      {
> >>>          // ... logic...
> >>>      }
> >>>
> >>>      public function __invoke($value)
> >>>      {
> >>>          return $this->filter($value);
> >>>      }
> >>>  }
> >>>
> >>>The benefits:
> >>>
> >>>* Fewer changes necessary to existing unit tests
> >>>* interface method names may be more descriptive of intent
> >>>
> >>>Problems:
> >>>
> >>>* Using __invoke() introduces overhead -- 2 method calls instead of =
one
> >>>* Redundancy (two methods doing the same thing)
> >>>* A few extra tests to write (to ensure __invoke works as expecte)
> >>>
> >>>After discussion with Ralph and Alex, I'm leaning towards having
> >>>__invoke() as an _additional_ method, instead of replacing existing
> >>>methods.
> >>>
> >>>Any thoughts or comments?
> >>>
> >>>--
> >>>Matthew Weier O'Phinney
> >>>Project Lead            | [email-masked]
> >>>Zend Framework          | http://framework.zend.com/
> >>>PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >>
>=20

--=20
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Andy Fowler <[email-masked]>
Date: Fri, 29 Jan 2010 08:26:28 -0500
To: [email-masked]
Subject: Re: [zf-contributors] ZF-8938

--Apple-Mail-4-849063455
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Interesting -- I didn't see that ticket. After my patches (which I'm =
currently implementing in subclasses), numerically-named forms are =
working fine for us, but we aren't explicitly accessing them via =
overload. I had assumed they were accepted because of all of the =
existing empty() || =3D=3D=3D "0" code.

More importantly, there is already an existing "testZeroAsNameIsAllowed" =
unit test. If numerically-named forms aren't permitted, that test should =
fail, rather than silently allow data to be mangled.

Zend_Form::__clone() also currently breaks with all-numerically-indexed =
subforms, but could be easily patched.

On Jan 29, 2010, at 3:23 AM, Giorgio Sironi wrote:

> Are you sure numeric names should be accepted? I reported a similar =
issue and Matthew pointed out that numeric form names would break =
overloading of properties:
> http://framework.zend.com/issues/browse/ZF-6062
> For instance $form->2 when $form has a subform with a numeric name =
would not work.
> If numeric form names have been re-evaluated I hope also #6062 can be =
fixed.

--Apple-Mail-4-849063455
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Interesting -- I didn't see that ticket. After my patches (which I'm =
currently implementing in subclasses), numerically-named forms are =
working fine for us, but we aren't explicitly accessing them via =
overload. I had assumed they were accepted because of all of the =
existing empty() || =3D=3D=3D "0" code.<div><br></div><div>More =
importantly, there is already an existing "testZeroAsNameIsAllowed" unit =
test. If numerically-named forms aren't permitted, that test should =
fail, rather than silently allow data to be =
mangled.<div><br></div><div>Zend_Form::__clone() also currently breaks =
with all-numerically-indexed subforms, but could be easily =
patched.<br><div><br></div><div><br><div><div>On Jan 29, 2010, at 3:23 =
AM, Giorgio Sironi wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; ">Are you sure numeric names =
should be accepted? I reported a similar issue and Matthew pointed out =
that numeric form names would break overloading of properties:<br><a =
href=3D"http://framework.zend.com/issues/browse/ZF-6062">http://framework.=
zend.com/issues/browse/ZF-6062</a><br>For instance $form-&gt;2 when =
$form has a subform with a numeric name would not work.<br>If numeric =
form names have been re-evaluated I hope also #6062 can be =
fixed.<br></span></blockquote></div><br></div></div></div></body></html>=

--Apple-Mail-4-849063455--

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Cc: [email-masked]
From: Jon Whitcraft <[email-masked]>
To: Matthew Weier O'Phinney <[email-masked]>
Date: Fri, 10 Apr 2009 15:55:07 -0400
Subject: Re: [zf-contributors] 1.8 Components Categories in JIRA

--Boundary_(ID_tPFxDXZOYiG6km7MDaUfCg)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT

Matthew,

What's the update on this?  I just want to know as I want to add the  
tasks to update the Abstract classes and unit tests.

Thanks,

	Jon Whitcraft
Zend Certified Engineer
[email-masked]
On Apr 8, 2009, at 9:29 AM, Matthew Weier O'Phinney wrote:

> -- Whitcraft, Jon <[email-masked]> wrote
> (on Wednesday, 08 April 2009, 08:13 AM -0400):
>> I am wondering when the new Component Categories will be created in  
>> JIRA for
>> the new components in 1.8?
>
> I'll take care of most of those in the next day or so. I know that the
> EC2/S3 support and Zend_Navigation need categories; I think most of  
> the
> rest already are setup.
>
> -- 
> Matthew Weier O'Phinney
> Software Architect      | [email-masked]
> Zend Framework          | http://framework.zend.com/

--Boundary_(ID_tPFxDXZOYiG6km7MDaUfCg)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; =
">Matthew,<div><br></div><div>What's the update on this? &nbsp;I just =
want to know as I want to add the tasks to update the Abstract classes =
and unit tests.</div><div><br></div><div>Thanks,</div><div><br><div>  =
<div> <table cellpadding=3D"2" cellspacing=3D"0" border=3D"0" =
style=3D"font-size: 13px;"> 	<tbody> 		<tr> 			=
<td rowspan=3D"3" valign=3D"top"><a =
href=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><img =
src=3D"http://www.whitcraftconsulting.com/images/php5_zce_logo_new.gif" =
width=3D"73" height=3D"68"></a></td> 			<td =
style=3D"font-size: 16px; font-weight: bold;">Jon Whitcraft</td> 		=
</tr> 		<tr> 			<td>Zend Certified Engineer</td> =
		</tr> 		<tr> 			<td =
valign=3D"top"><a =
href=3D"mailto:[email-masked]">[email-masked]</a></td> 		=
</tr> 	</tbody> </table> </div> </div><br><div><div>On Apr 8, 2009, at =
9:29 AM, Matthew Weier O'Phinney wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>-- =
Whitcraft, Jon &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>> =
wrote<br>(on Wednesday, 08 April 2009, 08:13 AM -0400):<br><blockquote =
type=3D"cite">I am wondering when the new Component Categories will be =
created in JIRA for<br></blockquote><blockquote type=3D"cite">the new =
components in 1.8?<br></blockquote><br>I'll take care of most of those =
in the next day or so. I know that the<br>EC2/S3 support and =
Zend_Navigation need categories; I think most of the<br>rest already are =
setup.<br><br>-- <br>Matthew Weier O'Phinney<br>Software Architect =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>Zend Framework =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| <a =
href=3D"http://framework.zend.com/">http://framework.zend.com/</a><br></di=
v></blockquote></div><br></div></body></html>=

--Boundary_(ID_tPFxDXZOYiG6km7MDaUfCg)--

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 26 Feb 2010 13:56:54 +0100
From: Julien Pauli <[email-masked]>
To: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] ZF 2.0 development begins!

Just translated ext/yaml doc (http://www.php.net/yaml), perhaps we
could detect the presence of the extension and make an adapter that
would use it ?
Does it cope with the need ?

J.Pauli

On Thu, Feb 25, 2010 at 8:38 PM, Matthew Weier O'Phinney
<[email-masked]> wrote:
> -- Ryan Albertson <[email-masked]> wrote
> (on Thursday, 25 February 2010, 02:20 PM -0500):
>> Another consideration of mine would be if Doctrine is used, would ZF use=
 yaml
>> like symfony does for the generation of schemas and model classes by mak=
ing
>> Zend_Tool work with yaml like the symfony CLI?
>
> One consideration I have for 2.0 is to do a YAML backend for
> Zend_Config, which would consume sfYaml. This would allow you to do what
> you're suggesting, while simultaneously using the same configuration
> file(s) with your ZF application.
>
> --
> Matthew Weier O'Phinney
> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| [email-masked]
> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Whitcraft, Jon" <[email-masked]>
To: Wil Sinclair <[email-masked]>, "[email-masked]"
	<[email-masked]>
Date: Mon, 6 Apr 2009 14:49:34 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [zf-contributors] RE: 1.8 PR feature list and *acknowledgements*

--_004_6B4A8009371807499638509271DEA796CC59256940IMSCMAIL1imsc_
Content-Type: multipart/alternative;
	boundary="_000_6B4A8009371807499638509271DEA796CC59256940IMSCMAIL1imsc_"

--_000_6B4A8009371807499638509271DEA796CC59256940IMSCMAIL1imsc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Zend_Service_Amazon_Ec2, contributed by Jon Whitcraft

<http://zend.com/zce.php?c=3DZEND002524=
&r=3D219549271>

Jon Whitcraft
Indianapolis Motor Speedway
[email-masked]<mailto:[email-masked]>
P: (317) 492-8623 - F: (317) 492-6419

From: Wil Sinclair [mailto:[email-masked]]
Sent: Monday, April 06, 2009 1:55 PM
To: [email-masked]
Subject: [zf-contributors] 1.8 PR feature list and *acknowledgements*

Hi all, it's that time again. I need everyone to reply with any and all fea=
tures that they have contributed to this release. Please feel free to reply=
 to the list, as I think it's useful for every contributor to know what's g=
oing in to this release and provide feedback before it is tagged. My apolog=
ies for sending this mail relatively late; I will send the feature request =
mail for the 1.8 production release about a week before we cut it.

NOTE: For this release, we'd like to try something new in the feature list-=
 actually acknowledging the significant contributions that y' all have made=
. :) The format would be like this:

* Zend_Application, contributed by Matthew Weier O'Phinney and Ben Scholzen

As a rule of thumb, this should include everyone who has contributed at lea=
st 20% or more of code *and* documentation. We reserve the right to put wha=
tever we want in the feature list. ;) Also, it is *your* responsibility to =
get the features to me before the release, along with the appropriate ackno=
wledgment list. If you do not send this in time to include in the feature n=
otes- typically a few days before production releases- then all complaints =
can be directed to /dev/null. Only names of individuals will be included; n=
o company or project names allowed. Finally, if you do not want your name o=
n the list for whatever reason, it is your prerogative. Just include a note=
 that you would like to remain anonymous.

Keep in mind that this is another way for us to thank you for your efforts.=
 Regardless of whose name or what features are included in the feature list=
, we recognize and appreciate all of your contributions. If you'd like to g=
et your name on the list for the next release, the best way is to lead a co=
mponent that interests you to completion.

Nuff said. Now send me your features! :)

,Wil

********************
********************
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify the sender by reply E-mail and erase this=
 E-mail from your system. Your assistance is appreciated. E-mail transmissi=
on may not be secure or error-free. The company is not responsible for any =
loss/damage arising from any virus transmitted.
********************
********************

--_000_6B4A8009371807499638509271DEA796CC59256940IMSCMAIL1imsc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Lucida Sans";
	panose-1:2 11 6 2 3 5 4 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Zend_Service_Amazon_Ec=
2, contributed by Jon Whitcraft<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0">
<tbody>
<tr>
<td width=3D"80" valign=3D"top" style=3D"width:60.0pt;padding:0in 0in 0in 0=
in">
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><a href=
=3D"http://zend.com/zce.php?c=3DZEND002524&amp;r=3D219549271"><span style=
=3D"color:#1F497D;text-decoration:none"><img border=3D"0" width=3D"73" heig=
ht=3D"68" id=3D"Picture_x0020_1" src=3D"cid:[email-masked]"=
 alt=3D"php5_zce_logo_new"></span></a><span style=3D"font-size:12.0pt;color=
:#1F497D"><o:p></o:p></span></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Lu=
cida Sans&quot;,&quot;sans-serif&quot;;
  color:#1F497D">Jon Whitcraft<br>
Indianapolis Motor Speedway<br>
</span><span style=3D"font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;
  color:#1F497D"><a href=3D"mailto:[email-masked]"><span style=3D=
"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-serif&quot=
;">[email-masked]</span></a><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span s=
tyle=3D"font-size:10.0pt;font-family:&quot;Lucida Sans&quot;,&quot;sans-ser=
if&quot;;color:#1F497D">P: (317) 492-8623 - F: (317) 492-6419</span><span s=
tyle=3D"font-size:9.0pt;
  font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>=
</o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><br clear=3D"all">
</span><span style=3D"color:#1F497D"><o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Wil Sinc=
lair [mailto:[email-masked]]
<br>
<b>Sent:</b> Monday, April 06, 2009 1:55 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [zf-contributors] 1.8 PR feature list and *acknowledgements=
*<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi all, it&#8217;s that time again. I need everyone =
to reply with any and all features that they have contributed to this relea=
se. Please feel free to reply to the list, as I think it&#8217;s useful for=
 every contributor to know what&#8217;s going in to
 this release and provide feedback before it is tagged. My apologies for se=
nding this mail relatively late; I will send the feature request mail for t=
he 1.8 production release about a week before we cut it.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">NOTE: For this release, we&#8217;d like to try somet=
hing new in the feature list- actually acknowledging the significant contri=
butions that y&#8217; all have made.
<span style=3D"font-family:Wingdings">J</span> The format would be like thi=
s:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">* Zend_Application, contributed by Matthew Weier O'P=
hinney and Ben Scholzen<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">As a rule of thumb, this should include everyone who=
 has contributed at least 20% or more of code *<b>and</b>* documentation. W=
e reserve the right to put whatever we want in the feature list. ;) Also, i=
t is *<b>your</b>* responsibility
 to get the features to me before the release, along with the appropriate a=
cknowledgment list. If you do not send this in time to include in the featu=
re notes- typically a few days before production releases- then all complai=
nts can be directed to /dev/null.
 Only names of individuals will be included; no company or project names al=
lowed. Finally, if you do not want your name on the list for whatever reaso=
n, it is your prerogative. Just include a note that you would like to remai=
n anonymous.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Keep in mind that this is another way for us to than=
k you for your efforts. Regardless of whose name or what features are inclu=
ded in the feature list, we recognize and appreciate all of your contributi=
ons. If you&#8217;d like to get your name
 on the list for the next release, the best way is to lead a component that=
 interests you to completion.<o:p></o:p></p>
<p class=3D"MsoNormal"><br>
Nuff said. Now send me your features! <span style=3D"font-family:Wingdings"=
>J</span><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">,Wil<o:p></o:p></p>
</div>
<br>
<font face=3D"Arial" color=3D"Gray" size=3D"1">********************<br>
********************<br>
This E-mail (and attachments) may contain confidential/privileged informati=
on intended only for the named addressee(s). If you are not an intended rec=
ipient, do not read, copy, disseminate or take any action based on the cont=
ent of this E-mail. Please notify
 the sender by reply E-mail and erase this E-mail from your system. Your as=
sistance is appreciated. E-mail transmission may not be secure or error-fre=
e. The company is not responsible for any loss/damage arising from any viru=
s transmitted.<br>
********************<br>
********************<br>
</font>
</body>
</html>

--_000_6B4A8009371807499638509271DEA796CC59256940IMSCMAIL1imsc_--

--_004_6B4A8009371807499638509271DEA796CC59256940IMSCMAIL1imsc_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=2553;
	creation-date="Mon, 06 Apr 2009 14:49:35 GMT";
	modification-date="Mon, 06 Apr 2009 14:49:35 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_004_6B4A8009371807499638509271DEA796CC59256940IMSCMAIL1imsc_--

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Content-class: urn:content-classes:message
Date: Tue, 26 May 2009 00:22:54 -0700
From: "Alexander Veremyev" <[email-masked]>
To: <[email-masked]>
Subject: [zf-contributors] Zf 1.8.2 sanity checl packages

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9DDD2.DD1411C2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all!

=20

The sanity check packages for ZF 1.8.2 are now available here:

http://framework.zend.com/releases/preview/ZendFramework-1.8.2.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-apidoc.ta
r.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-apidoc.zi
p

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-de
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-de
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-en
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-en
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-fr
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-fr
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-ja
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-ja
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-ru
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-ru
.zip

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-zh
.tar.gz

http://framework.zend.com/releases/preview/ZendFramework-1.8.2-manual-zh
.zip

=20

=20

Note that this is *NOT* the official release of 1.8.2. If we find no
major issues with these builds, we will issue official 1.8.2 release
from this tag soon.=20

Please do *NOT* log any issues found in these archives in the issue
tracker; instead post any major functional or packaging issues to this
list or mail them to me directly ([email-masked]).

=20

=20

With best regards,

   Alexander Veremyev.

=20

------_=_NextPart_001_01C9DDD2.DD1411C2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@SimSun";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:2.0cm 69.6pt 2.0cm 69.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Hi all!</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>The sanity check packages for ZF 1.8.2 are =
now
available here:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2.ta=
r.gz">http://framework.zend.com/releases/preview/ZendFramework-1.8.2.tar.=
gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2.zi=
p">http://framework.zend.com/releases/preview/ZendFramework-1.8.2.zip</a>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ap=
idoc.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.2-apidoc.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ap=
idoc.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8.2-=
apidoc.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-de.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.2-manual-de.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-de.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.2-manual-de.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-en.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.2-manual-en.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-en.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.2-manual-en.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-fr.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.2-manual-fr.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-fr.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.2-manual-fr.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-ja.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.2-manual-ja.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-ja.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.2-manual-ja.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-ru.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.2-manual-ru.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-ru.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.2-manual-ru.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-zh.tar.gz">http://framework.zend.com/releases/preview/ZendFramework-=
1.8.2-manual-zh.tar.gz</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'><a
href=3D"http://framework.zend.com/releases/preview/ZendFramework-1.8.2-ma=
nual-zh.zip">http://framework.zend.com/releases/preview/ZendFramework-1.8=
.2-manual-zh.zip</a></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Note that this is *NOT* the official release =
of 1.8.2.
If we find no major issues with these builds, we will issue official =
1.8.2
release from this tag soon. </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Please do *NOT* log any issues found in these =
archives
in the issue tracker; instead post any major functional or packaging =
issues to
this list or mail them to me directly =
([email-masked]).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>With best regards,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Alexander Veremyev.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9DDD2.DD1411C2--

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: "Thomas Weidner" <[email-masked]>
To: "Wil Sinclair" <[email-masked]>,
	<[email-masked]>
Date: Fri, 20 Mar 2009 20:56:50 +0100
Subject: Re: [zf-contributors] Release Policies and Conventions

Hy Wil,

In my understanding also "feature enhancements" are actually not allowed to 
be integrated within mini-releases.
Only "Bug fixes" which do not add additional API are allowed.

Maybe you should also add a definition for what's a bug fix, a improvement 
and a new feature to get that also defined, and we can all speak of the same 
in future.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message ----- 
From: "Wil Sinclair" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 20, 2009 8:47 PM
Subject: [zf-contributors] Release Policies and Conventions

Over the 2 years that I've been involved with the project, there have
been many questions about what can go in to a given release and if there
are any guidelines for the release schedules. While many of you have
pieced the picture together from different mails, IRC chats, etc. I've
owed you a document for a long time now. Here it is:

http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conven
tions

I ask all contributors to review this and reply with any question or
edits- especially if I missed something- in this forum.

As always, thanks for all the time and effort. Also, go 1.8!

,Wil

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
From: Rob Allen <[email-masked]>
Date: Tue, 23 Mar 2010 15:49:43 +0000
To: zf-contributors <[email-masked]>
Subject: Re: [zf-contributors] use statements -- usage?

--Apple-Mail-14--1005592025
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 23 Mar 2010, at 13:04, Court Ewing wrote:

> I don't have very strong opinions on the matter, but I generally =
disagree with what has already been said.  For one, I don't think it is =
out of line to say that you use an entire package as opposed to using =
individual components of a package.  I think automated packaging should =
focus on packages; that's kind of how package managers work anyway.  =
When I download something via pacman, I get entire packages and their =
dependent packages therein.  Downloading only portions of a package will =
just lead to confusion and frustration down the line, and there really =
isn't an existing precedent for it, so I don't think we should be =
starting one.
>=20

Like Court, I don't have an especially strong opinion, but tend to agree =
with him here. I don't see the point of having to add a use clause for =
every sub section of the package that we're currently in.

Regards,

Rob...

--Apple-Mail-14--1005592025
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 23 Mar 2010, at 13:04, Court Ewing wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">I don't have very strong opinions on the matter, but I 
generally disagree with what has already been said.&nbsp; For one, I don't 
think it is out of line to say that you use an entire package as opposed
 to using individual components of a package.&nbsp; I think automated 
packaging <i>should</i> focus on packages; that's kind of how package 
managers work anyway.&nbsp; When I download something via pacman, I get 
entire packages and their dependent packages therein.&nbsp; Downloading only 
portions of a package will just lead to confusion and frustration down 
the line, and there really isn't an existing precedent for it, so I 
don't think we should be starting one.<br>
<br></div></blockquote><div><br></div><div>Like Court, I don't have an especially strong opinion, but tend to agree with him here. I don't see the point of having to add a use clause for every sub section of the package that we're currently in.</div><div><br></div><div>Regards,</div><div><br></div><div>Rob...</div></div><br></body></html>
--Apple-Mail-14--1005592025--

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Fri, 10 Apr 2009 19:33:35 -0400
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [zf-contributors] Proposal to update Abstract/Interface Naming
	Conventions

-- Matthew Ratzloff <[email-masked]> wrote
(on Friday, 10 April 2009, 03:35 PM -0700):
> I think Ben and I are saying similar things. =A0Zend\View\PhpCore and Z=
end\View\
> PhpEngine seem a bit awkward. =A0Surely it would be easier and more app=
arent to
> say:
>=20
> Zend_View_Interface =3D> zend\view\IEngine
> Zend_View_Abstract =3D> zend\view\Engine
> Zend_View =3D> zend\view\engine\Standard
>=20
> Where "Standard" could also be "Native" or "PHP" (but was chosen to mim=
ic the
> dispatcher).

First, my examples are not final -- they were merely some brainstorming.
Second, please read the various links at the end of the Hungarian
Notation wikipedia article I linked in the original email. Basically,
Hungarian Notation really doesn't make sense with modern programming
practices and IDEs, and with well named interfaces and abstract classes
-- and, more importantly, well-named concrete classes --- it becomes
very trivial to separate them.

Next, your example doesn't fit one of the criteria -- the concrete
versions are not in the same namespace as the interfaces/abstracts.

> View this as a compromise between your suggested solution and the "I"
> notation for interfaces. =A0A single "I" is not much in the way of
> Hungarian notation and every experienced developer will be familiar
> with the meaning. I think this will solve a lot of naming dilemmas
> easily in advance, as well--like Interface and Abstract do currently.

I've actually had a lot of debates about the I prefix. Try this one we
recently encounted on for size: IItem. That looks like a mistake with
the double I's.

The point is that there's really no need to indicate in the name that a
class is an interface or abstract class. Indeed, when porting to other
languages, this can actually lead to potential WTFs when there are not
direct correlations between the two languages.

The other thing is that your IDEs very easily tell you what the class is
-- if it's an interface, and abstract, a concrete class, what it
extends, etc. Even vim users like me can easily find this information
out with things like ctags and the taglist plugin.

> On Fri, Apr 10, 2009 at 1:38 PM, Matthew Weier O'Phinney <matthew@zend.=
com>
> wrote:
>=20
>     -- Matthew Ratzloff <[email-masked]> wrote
>     (on Friday, 10 April 2009, 01:08 PM -0700):
>     > "This decision is basically already made..."
>     >
>     > Before I weigh in, I'd=A0first=A0like to suggest that this is per=
haps a poor
>     > approach to this sort of thing. =A0It's like bringing in a job ca=
ndidate
>     and
>     > saying, "He's basically already hired, but feel free to interview=
 him."
>=20
>     Heh -- I actually did this intentionally in part to stimulate the
>     debate. Nothing like something inflammatory to get people to start
>     commenting. :)
>=20
>     > That said, I have no real preference, but one consideration that =
I didn't
>     see
>     > in the latter solution was how to go about naming if there is bot=
h an
>     interface
>     > and an abstract class. =A0For example, Zend_View_Interface and
>     > Zend_View_Abstract. =A0I'm guessing the abstract will probably ch=
ange to
>     > something like Zend_View_Engine or Zend_View_Adapter, but what ab=
out the
>     > interface?
>=20
>     It will depend in large part on the implementation. In the case of
>     Zend_View, it will likely actually be the following:
>=20
>     =A0* Zend_View_Interface -> Zend\View\Engine (the interface referen=
ces
>     =A0 =A0"getEngine()", which makes this appropriate
>=20
>     =A0* Zend_View_Abstract -> Zend\View\PhpCore (because this is the c=
ore
>     =A0 =A0functionality for a concrete PHP view implementation)
>=20
>     ...and that leads to your next point, as we need to address Zend_Vi=
ew...
>=20
>     > Also, how would you go about renaming classes in a situation wher=
e you
>     have a
>     > "root" class and an abstract class? =A0For example, Zend_Session =
extends
>     > Zend_Session_Abstract.
>=20
>     Zend_View would likely become Zend\View\PhpEngine, as it's a view
>     engine that utilizes PHP. But the basic idea is that it now moves
>     underneath the Zend\View namespace -- and that's what will happen t=
o
>     other components as well.
>=20
>     We'll have to discuss these on a case by case instance. As more are
>     moved over, we'll likely get some emerging idioms to draw upon.
>=20
>=20
>     > On Fri, Apr 10, 2009 at 11:24 AM, Matthew Weier O'Phinney <
>     [email-masked]>
>     > wrote:
>     >
>     > =A0 =A0 Greetings, all --
>     >
>     > =A0 =A0 Below is a proposal I am making to modify the Zend Framew=
ork Coding
>     > =A0 =A0 Standards conventions for the naming of Interfaces and Ab=
stract
>     classes.
>     >
>     > =A0 =A0 This decision is basically already made, but I'd apprecia=
te any
>     feedback
>     > =A0 =A0 that you may have on the matter.
>     >
>     > =A0 =A0 Thanks!
>     >
>     > =A0 =A0 The problem
>     > =A0 =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>     > =A0 =A0 PHP 5.3 introduces namespaces to the PHP language. While =
this won't
>     have an
>     > =A0 =A0 impact much on userland code, it will have an impact on l=
ibrary and
>     > =A0 =A0 framework
>     > =A0 =A0 code, as it provides a useful paradigm for organizing com=
ponents as
>     well as
>     > =A0 =A0 simplifying syntax. Instead of having to say things like:
>     >
>     > =A0 =A0 =A0 =A0$analyzer =3D new
>     Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum();
>     >
>     > =A0 =A0 we can instead do something like this:
>     >
>     > =A0 =A0 =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
>     >
>     > =A0 =A0 =A0 =A0$analyzer =3D new Common_TextNum();
>     >
>     > =A0 =A0 or even:
>     >
>     > =A0 =A0 =A0 =A0namespace Zend\Search\Lucene\Analysis\Analyzer;
>     >
>     > =A0 =A0 =A0 =A0class Common_TextNum extends Common
>     > =A0 =A0 =A0 =A0{
>     > =A0 =A0 =A0 =A0}
>     >
>     > =A0 =A0 The problem that arises for Zend Framework has to do with=
 how we name
>     > =A0 =A0 abstract
>     > =A0 =A0 classes and interfaces. Currently, the final segment of s=
uch classes
>     are
>     > =A0 =A0 expected to end with _Abstract and _Interface, respective=
ly. This
>     will not
>     > =A0 =A0 work
>     > =A0 =A0 when we migrate to utilize namespaces, for two reasons.
>     >
>     > =A0 =A0 First, and most obviously, 'abstract' and 'interface' are=
 reserved
>     PHP
>     > =A0 =A0 keywords.
>     > =A0 =A0 As such, in situations such as the following:
>     >
>     > =A0 =A0 =A0 =A0namespace Zend\Controller\Request;
>     >
>     > =A0 =A0 =A0 =A0class Abstract
>     > =A0 =A0 =A0 =A0{
>     > =A0 =A0 =A0 =A0}
>     >
>     > =A0 =A0 =A0 =A0// or:
>     >
>     > =A0 =A0 =A0 =A0namespace Zend\Controller\Dispatcher;
>     >
>     > =A0 =A0 =A0 =A0interface Interface
>     > =A0 =A0 =A0 =A0{
>     > =A0 =A0 =A0 =A0}
>     >
>     > =A0 =A0 we'll run into issues.
>     >
>     > =A0 =A0 Second, and less obvious, is that perhaps the easiest sol=
ution breaks
>     one
>     > =A0 =A0 of the
>     > =A0 =A0 key principles of namespaces (which are designed to help =
encapsulate
>     > =A0 =A0 components). This one's harder to explain, so let's look =
at examples.
>     > =A0 =A0 Consider a
>     > =A0 =A0 component such as Zend_Controller_Request. The simplest s=
olution
>     would be
>     > =A0 =A0 to
>     > =A0 =A0 name the abstract class or interface Zend\Controller\Requ=
est, and
>     then have
>     > =A0 =A0 the
>     > =A0 =A0 various concrete implementations under that namespace:
>     >
>     > =A0 =A0 =A0 =A0namespace Zend\Controller;
>     >
>     > =A0 =A0 =A0 =A0interface Request
>     > =A0 =A0 =A0 =A0{
>     > =A0 =A0 =A0 =A0}
>     >
>     > =A0 =A0 =A0 =A0// and concrete ones:
>     >
>     > =A0 =A0 =A0 =A0namespace Zend\Controller\Request;
>     >
>     > =A0 =A0 =A0 =A0class Http
>     > =A0 =A0 =A0 =A0{
>     > =A0 =A0 =A0 =A0}
>     >
>     > =A0 =A0 What's the problem here? The interface is not in the same=
 namespace
>     as the
>     > =A0 =A0 concrete implementations.
>     >
>     > =A0 =A0 Potential solutions and recommendation
>     > =A0 =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>     > =A0 =A0 So, how should Zend Framework "solve" these issues? A num=
ber of
>     proposals
>     > =A0 =A0 and
>     > =A0 =A0 recommendations have been floated around, both within ZF =
circles and
>     in the
>     > =A0 =A0 greater PHP community.
>     >
>     > =A0 =A0 Considerations include:
>     >
>     > =A0 =A0 =A0* Avoiding the use of PHP reserved keywords (already n=
oted).
>     > =A0 =A0 =A0* Avoiding Hungarian Notation (i.e., having the name o=
r a portion of
>     the
>     > =A0 =A0 name
>     > =A0 =A0 =A0 describe its type -- which, to a degree, the current =
naming
>     conventions
>     > =A0 =A0 =A0 already violate). (See http://en.wikipedia.org/wiki/
>     Hungarian_Notation,
>     > =A0 =A0 the
>     > =A0 =A0 =A0 sections "Disadvantages of Systems Hungarian" and "No=
table
>     Opinions" for
>     > =A0 =A0 some
>     > =A0 =A0 =A0 of the arguments against using Hungarian Notation.)
>     >
>     > =A0 =A0 Approaches that have been considered include:
>     >
>     > =A0 =A0 =A0* Using 'I' to prefix interfaces. This derives from st=
andards in
>     other
>     > =A0 =A0 =A0 programming languages (.Net and python, in particular=
). This is
>     just
>     > =A0 =A0 another
>     > =A0 =A0 =A0 form of Hungarian Notation, however.
>     >
>     > =A0 =A0 =A0* Using "Interface" or "Abstract" as a class name suff=
ix:
>     > =A0 =A0 RequestInterface,
>     > =A0 =A0 =A0 RequestAbstract. Again, however this is Hungarian Not=
ation.
>     >
>     > =A0 =A0 =A0* Using the term "Base" for abstract classes: BaseRequ=
est,
>     RequestBase,
>     > =A0 =A0 Base.
>     > =A0 =A0 =A0 This is just substituting the word Base for Abstract,=
 however, and
>     is
>     > =A0 =A0 really
>     > =A0 =A0 =A0 not much different than the above.
>     >
>     > =A0 =A0 =A0* Use generic, descriptive names indicative of functio=
nality or
>     behavior.
>     > =A0 =A0 As
>     > =A0 =A0 =A0 examples from the SPL, "Countable", "Iterator", "Arra=
yObject".
>     >
>     > =A0 =A0 My recommendation is to use the latter, as it solves all
>     considerations. It
>     > =A0 =A0 will
>     > =A0 =A0 take more thought when naming, but will ensure that compo=
nents can
>     live in
>     > =A0 =A0 a
>     > =A0 =A0 self-contained namespace, do not use reserved keywords, a=
nd avoid
>     Hungarian
>     > =A0 =A0 Notation.
>     >
>     > =A0 =A0 Plan for implementation
>     > =A0 =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>     > =A0 =A0 I recommend that the Coding Standards documentation be up=
dated to
>     reflect
>     > =A0 =A0 this
>     > =A0 =A0 approach.
>     >
>     > =A0 =A0 All new components going into 1.8 and onwards should adop=
t these
>     standards.
>     > =A0 =A0 In
>     > =A0 =A0 releases 1.9 and forward, we will begin migrating existin=
g interfaces
>     /
>     > =A0 =A0 abstract
>     > =A0 =A0 classe. First, new classes/interfaces will be created tha=
t follow
>     these
>     > =A0 =A0 conventions and which extend the originals; later, any ty=
pe-hinting
>     based
>     > =A0 =A0 on the
>     > =A0 =A0 original class/interface names will be updated to point t=
o the new
>     names;
>     > =A0 =A0 and
>     > =A0 =A0 finally, in 2.0, we will remove the old interfaces/abstra=
ct classes
>     > =A0 =A0 entirely.
>     >
>     > =A0 =A0 --
>     > =A0 =A0 Matthew Weier O'Phinney
>     > =A0 =A0 Software Architect =A0 =A0 =A0| [email-masked]
>     > =A0 =A0 Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend=
.com/
>     >
>     >
>=20
>     --
>     Matthew Weier O'Phinney
>     Software Architect =A0 =A0 =A0| [email-masked]
>     Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>=20
>=20

--=20
Matthew Weier O'Phinney
Software Architect      | [email-masked]
Zend Framework          | http://framework.zend.com/

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 24 Feb 2010 18:05:49 -0500
From: Matthew Weier O'Phinney <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [zf-contributors] ZF 2.0 development begins!

Hey, all --

Those of you paying attention to the SVN commits will have noticed that
I just created a new branch, development-2.0. This is a new branch
intended for development of ZF 2.0.

    http://framework.zend.com/svn/framework/standard/branches/development-2.0

Initially, we will be working on the following tasks:

 * Stripping require_once calls
 * Updating the test suite:
   * Removing the AllTests suites (these are not necessary with newer
     versions of PHPUnit, and we have already established @group
     annotations throughout the framework)
   * Usage of TestHelper.php as a PHPUnit bootstrap; this will allow
     stripping out the require_once calls in each test class file.
 * Conversion to namespaces. This will be automated at first, but will
   then shift to manual changes
 * Testing of alternate plugin systems. I'm aiming for explicitness over
   magic in ZF 2.0, as this will give us huge improvements with
   performance, and hopefully make "grokking" the plugin system easier.

For the initial development, I'm trying to (a) gauge what works, and (b)
get a good sense for the amount of work ahead, so I can estimate a
release date. This latter will help determine if we should release a
1.11 release with new features between now and 2.0, or go straight to
2.0. As such, I'd like to ask that you refrain from working on
refactoring/rewriting components in the 2.0 branch for the time being,
until we've completed the tasks above; we may be reverting the branch on
occasion when we have failed experiments, or when we determine
particular approaches will be too expensive in terms of time or
resources.

I also am looking at infrastructure changes to help with the development
of 2.0; in particular, we're weighing whether to stick with Subversion,
or convert to Git. For this question, I'd really like input from all of
you, and have setup a page to track comments:

    http://framework.zend.com/wiki/pages/viewpage.action?pageId=20873259

Please let us know your opinions.

Looking forward to hearing from all of you as we start work on 2.0!

-- 
Matthew Weier O'Phinney
Project Lead            | [email-masked]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Wed, 10 Feb 2010 01:53:59 +0100
From: [email-masked]
To: [email-masked]
Subject: [zf-contributors] Zend_Mail

Hi,

in the roadmap for 2.0 you called for participation in the discussion, 
so here are my thoughts for Zend_Mail. First at all, the most important 
thing is to complete the existing code. For instance, in the imap 
component there are many features in the api but marked "not 
implemented". I'm trying to write an email webclient and found many 
things which just aren't implemented. Things like search in imap and 
fetching only contents parts of emails instead of all, aren't working.
I also think, that content encoding should be integrated automatically.

To keep it short, at the moment the imap layer in zend is only (too) basic.
I would like to help the Zend_Mail maintainer (whoever that is) and hear 
your thoughts.

Regards,
Otto

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
To: <[email-masked]>
Date: Sat, 23 Jan 2010 00:20:21 +0100
From: Benjamin Eberlei <[email-masked]>
Subject: Re: [zf-contributors]
	=?UTF-8?Q?Zend=5FDate=20=26=20build-in=20class=20Da?=
	=?UTF-8?Q?teTime?=

PHP 5.2.x DateTime was very limited in functionality and supports
only a very short total time period. Zend_Date has much more powers
in this regard, which was the reason it was included.

however with ZF 2.0 moving to php 5.3 and this issues being adressed
in DateTime (and many others) i would really like to see Zend_Date being
stripped completly to use DateTime and only extend it for localized date
formatting.

One major pro argument for this are performance reasons I guess, since
Zend_Date is not exactly the fastest code out there (compared to
DateTime).

greetings,
Benjamin

On Fri, 22 Jan 2010 23:16:02 +0100, Marc Bennewitz
<[email-masked]> wrote:
> Hi all,
>=20
> Does is matter that Zend_Date doesn't extends the build-in DateTime
class ?
> -> The DateTime class is available since PHP 5.2.0 and ZF require PHP
> 5.2.4.
>=20
> It would be very nice because than Zend_Date would be compatible to
> other php libraries using DateTime and within ZF tests like the
> following can simplify:
>=20
> if ($date instanceof Zend_Date_DateObject) {
>     $timestamp =3D $date->getUnixTimestamp();
> } elseif ($date instanceof DateTime) {
>     $timestamp =3D $date->getTimestamp();
> } else {
>     $timestamp =3D (float)$date;
> }
>=20
> Greetings,
> Marc

nFrom nobody Wed Apr  7 08:46:20 2010
Mailing-List: contact [email-masked]; run by ezmlm
Date: Tue, 16 Feb 2010 13:15:36 +0100
From: Pieter Kokx <[email-masked]>
To: [email-masked], "ZF Contributors" <[email-masked]>
Subject: [zf-contributors] Zend_Db_Schema is Ready for Review

Hi,

I'm glad to announce that the Zend_Db_Schema proposal is Ready for
Review. All feedback is welcome.

http://framework.zend.com/wiki/display/ZFPROP/Zend_Db_Schema+-+Pieter+Kokx

-- 
Regards,

Pieter Kokx
PHP Developer
Zend Framework developer

n