RE: [fw-general] CakePHP vs. ZendFramework
Andrés Robinet wrote: Thats very easy to answer but first we should all agree about Windows vs. Linux, Coke vs. Pepsi, Alien vs. Predator and Freddy vs. Jason Linux,Coke,Predator,Freddy Next question please. -- View this message in context: http://www.nabble.com/CakePHP-vs.-ZendFramework-tp15619408s16154p15906940.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
Don't take this the wrong way but these casual massive changes to the way
existing code works is the reason why I stopped using Zend_Db back in the .8
days. By taking away the array imploding functionality you have just broken
a considerable amount of existing code. Code written in accordance with the
published documentation.
Your use case rational: where(price ? and price = ?, array(2, 10));
can already be handled by calling where twice.
Did you talk to anybody before deciding to break existing behavior? If I
was still using Zend_Db then I'd be pretty upset to have my queries broken
without warning and for no particular reason. Especially since it appears
you plan on delivering these last minute changes without offering a useful
alternative.
Art
Thomas Weidner-2 wrote:
Shekar,
to get my snippet working with previous versions you would just have to
add
a version check...
if (Zend_Version::compareVersions('1.0.2') 0) {
// change where
}
or you wait for the issue to be solved...
1.0.4 I think as in 4 days the new release comes out.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 11:02 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
I encourage you to test the where() method with v1.0.2 and see the
results -
it generates SQL imploding all the array values into a single placeholder
as
expected. The documentation used to have this usage listed but now it
seems
to have been removed. The code snipped you gave generated the following
SQL
with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome
but
I
thought they would be backwards compatible - I had to revert to 1.0.2 :(
The old code used to be generic and would apply to both - a normal where
clause with a boolean operator or an IN operator because it used to
implode
the array into a list of values to replace a single placeholder but the
new
enhancements need IN-operators handled differently using arrays and
multiple
placeholders. I guess having a separate in() function for such
expressions
is more ideal and desired at the component level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I did my commit.
Actually, giving an array as input would result in each single
placeholder
to be replaced.
where(price ? and price = ?, array(2, 10));
becomes
where (price 2 and price = 10)
This is the reason why the automatic imploding does not work anymore.
Principially there are several ways:
You could for example do the following:
$array = array(2,10,14,20);
$addwhere = ;
for($i = 1; $i count($array); ++$i) {
$addwhere .= , ?;
}
$where = price IN (?. $addwhere.);
$db-where($where, $array);
In my eyes it would be better to have a own IN function avaiable for
such
clauses.
I am actually also working on a BEWTEEN function which adds between to
be
avaiable.
So eighter you use a the codesnippet I gave you or you add a new issue
for
creating a IN function which handles the IN within the where clause.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 8:28 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
This feature of imploding an array of values into a single
place-holder
was
there from the the days of ZF v0.1.5 or earlier. My code was working
fine
all these days. There were code examples in the documentation that
showed
how an array would be imploded into the SQL using where(). I even
created
an
issue in the past to avoid quoting numeric values in the resulting
SQL's
array (look for the issue that reads: quote() quotes numeric values
a
bug
that was attributed to PDO). I just did a diff on Select.php between
the
current SVN and 1.0.2 and noticed that where() method actually invokes
and
delegates to _where() in the current SVN whereas there is no _where()
method
in 1.0.2. My same code with ZF 1.0.2 works fine as expected but not
with
the
latest SVN update.
If this is not supported, what's the syntax for the expected SQL? I
need
to
generate a where clause as under:
WHERE status IN ( 'A', 'I' )
Thanks,
On 11/20/07, Thomas Weidner [EMAIL
Re: [fw-general] Zend_Db_Select::where() malfunction
Zend 0.8.0 had the use of where IN (?) array documented. As well as previous
versions.
Zend 0.9.0 did not have it documented
Zend 0.9.1 was the first release with Zend_Db_Select unit test cases and, as
you say, did not have an array test or any tests with multiple ? place
holders
Zend 1.0.2 Zend_Db_Select source code has
/**
* Adds a WHERE condition to the query by AND.
*
* If a value is passed as the second param, it will be quoted
* and replaced into the condition wherever a question-mark
* appears. Array values are quoted and comma-separated.
I'm certainly not asking you to roll back all your changes. But is a point
release really the best time for something like this?
Perhaps, as a compromise, you could count the number of ? place holders and,
if 1, then keep the old behavior.
Thomas Weidner-2 wrote:
Art,
as I said in past we reviewed what was written within the documentation
and
within the testbed.
The usecases did not brake anyone of the behaviour mentioned there.
Then we looked over the opened issues and discussed about the additional
usecases we want to support.
This mentioned usecase with one array integrated in one placeholder is
actually not supported and from my understanding of the documentation it
was
not in the past.
The change itself was discussed within the dev team and with simon.
I was just the one who made the work.
If this is problematic I would also accept to reject my help and let all
Zend_Db issues as they were before.
I would be willing to redo my changes, delete the new features already
done
and not implement the additional features which are already issued.
Please ask darby and simon how we should behave.
It would be nice if you give me the related documentation with the example
or text where you found the mentioned array behaviour.
Just give file and svn to check for us where we oversee this usecase.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Art Hundiak [EMAIL PROTECTED]
To: fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 4:18 PM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
Don't take this the wrong way but these casual massive changes to the way
existing code works is the reason why I stopped using Zend_Db back in the
.8
days. By taking away the array imploding functionality you have just
broken
a considerable amount of existing code. Code written in accordance with
the
published documentation.
Your use case rational: where(price ? and price = ?, array(2, 10));
can already be handled by calling where twice.
Did you talk to anybody before deciding to break existing behavior? If I
was still using Zend_Db then I'd be pretty upset to have my queries
broken
without warning and for no particular reason. Especially since it
appears
you plan on delivering these last minute changes without offering a
useful
alternative.
Art
Thomas Weidner-2 wrote:
Shekar,
to get my snippet working with previous versions you would just have to
add
a version check...
if (Zend_Version::compareVersions('1.0.2') 0) {
// change where
}
or you wait for the issue to be solved...
1.0.4 I think as in 4 days the new release comes out.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 11:02 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
I encourage you to test the where() method with v1.0.2 and see the
results -
it generates SQL imploding all the array values into a single
placeholder
as
expected. The documentation used to have this usage listed but now it
seems
to have been removed. The code snipped you gave generated the following
SQL
with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome
but
I
thought they would be backwards compatible - I had to revert to 1.0.2
:(
The old code used to be generic and would apply to both - a normal
where
clause with a boolean operator or an IN operator because it used to
implode
the array into a list of values to replace a single placeholder but the
new
enhancements need IN-operators handled differently using arrays and
multiple
placeholders. I guess having a separate in() function for such
expressions
is more ideal and desired at the component level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I
Re: [fw-general] Separation of Public/Admin
Pretty much the same way Symfony does it. project ...model (database models used by all apps withing a project) ...apps ..admin ..public I use a config file for the project as well as second config file for each application Greg Freeman wrote: Hello, I have been using symfony for some time and it has helped my productivity a lot. I am really interested in giving ZF a go in an upcoming project. I have used ZF components before like lucene (fantastic by the way). One thing I am used too in symfony is the separation of applications (i.e public frontend / admin backend). How do you achieve this in ZF? I have only read about module separation not application separation. Thank You! Btw thanks to Matthew Weier O'Phinney for the great webinar on zend controllers - very informative. -- View this message in context: http://www.nabble.com/Separation-of-Public-Admin-tf4586595s16154.html#a13176731 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Db_Table_Row: underscore_words to camelCaps conversion
The camelCaps stuff has been removed. Might want to file an issue concerning the documentation. Perhaps read through the rest of it carefully and see if any other mention of camels exist and then list them all. Ivan Ruiz Gallego-2 wrote: Hello, From the manual (http://framework.zend.com/manual/en/zend.db.table.row.html): Next, retrieve one record from the database using Zend_Db_Table::find() with a single key, or by using Zend_Db_Table::fetchRow(). The returned result will be a Zend_Db_Table_Row object where each property in the object is a camelCaps name mapped to an underscore_words column name from the table. E.g., first_name in the table will become firstName in the object properties This is also the behavior I expected. Now I am using ZF 0.9.1, but I am a very happy user of ZF since 0.1.0. I have a simple load method. Surprisingly, the conversion between underscore_words (table field folder_id) and camelCaps (object attribute folderId) does not happen, i.e. the Zend_Db_Table_Row object has a property folder_id, but not folderId. Is the former behavior now something that has to be explicitly configured? Or is this former behavior simply not present in ZF 0.9.1? Thank you very much. Best regards, Ivan. -- Loglan GmbH Ivan Ruiz Gallego Binzmühlestrasse 210 8050 Zürich Switzerland Office +41 44 310 19 20 Mobile +41 76 321 23 68 Net www.loglan.net -- View this message in context: http://www.nabble.com/Zend_Db_Table_Row%3A-%22underscore_words%22-to-%22camelCaps%22-conversion-tf3478750s16154.html#a9713896 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Controller and View Question
I use method A and extend the View class to reduce the tedious code.
class Proj_View extends Zend_View
{
protected $tplPage= 'MasterPageTpl'; // Master layout
protected $tplTitle = 'Project View'; // Title set in individual view
protected $tplContent = 'HomeIndexTpl'; // Content template
...
function renderx()
{
$this-content = $this-render($this-tplContent); // Do content
first
return $this-render($this-tplPage); // The the master layout
}
}
Simplistic but functional enough for me.
Ralph Schindler wrote:
Hey group,
I am curious how everyone implements common headers and footers
within a given application. As I see it there are two methods:
a) include the header and footer in each view script via the
$this-render(..) routine.
b) use Zend_Controller Plugins to write to the view a standard header
and footer to the view body at preDispatch() postDispatch() /
preRouteStartup / postRouteStartup times.
--
View this message in context:
http://www.nabble.com/Controller-and-View-Question-tf3462561s16154.html#a9671725
Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] $db-setRowClass $db-setRowsetClass
Excellent. Kept hoping someone would say Hey you dummy, the tests are right here. Thanks for catching that bug, Art. For the record, there *are* unit tests for Zend_Db_Table/Row/Rowset. The code coverage is 68%. Look in zf-home/tests/Zend/Db/Adapter/Common.php, there are 37 test functions matching testTable*. I wish you would not say that there are no tests for these classes. It is a false statement. It is true that the line containing the bug was not covered by unit tests. But it is an exaggeration to say that there are no tests covering the Table/Row classes. Regards, Bill Karwin -Original Message- From: Art Hundiak [mailto:[EMAIL PROTECTED] Almost as though the code was released without testing. Which I guess is consistent with the fact that there are no DB_Table/Row tests in the delivered version.
RE: [fw-general] Zend_Db_Table_Row __get()
Basic problem is that the pdo adapter has:
// force names to lower case
$this-_connection-setAttribute(PDO::ATTR_CASE,
PDO::CASE_LOWER);
You will have to figure out how to change it to CASE_NATURAL. Even then I
suspect you might have trouble with case sensitivity.
I myself rather liked the camel case conversion. It being dropped is one
of the reasons I gave up on Zend_Db.
It appears that all column preparation has been removed on each row.
0.8 Usage:
CREATE TABLE `accounts` (
`id` int(11) NOT NULL auto_increment,
`date_entered` datetime default NULL,
`date_modified` datetime default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
foreach($this-account as $account)
{
echo $account-dateModified;
}
Current 0.9 Usage: (untested)
foreach($this-account as $account)
{
echo $account-date_modified;
}
I never liked the camel-casing. I found it confusing. I like the 0.9 usage
better because I know exactly what to expect. The camel-casing limited
system predictability. (This can of course be argued both ways).
Bug? Feature?
-Original Message-
From: Aaron Egaas [mailto:[EMAIL PROTECTED]
Sent: March 19, 2007 10:26 AM
To: fw-general@lists.zend.com
Subject: [fw-general] Zend_Db_Table_Row __get()
Hello,
Prior to 0.9, I was using underscored field names in my MySQL database and
relying on Zend_Db's inflector to produce nice Camel-cased field names
within the Zend framework. Since 0.9 with the inflector gone, I switched
my
field name in the database to camel case so I didn't have to refactor a
lot
of code. Unforunately I think I found a bug when I did this.
All over my app I get exceptions saying the field (jobId for example)
isn't
found! I dumped out the Db_Row and all the fieldnames have been lower
cased.
I'm using MySQL's PDO. Anyone know whats causing my plight?
-Aaron Egaas
--
View this message in context:
http://www.nabble.com/Zend_Db_Table_Row-__get%28%29-tf3428196s16154.html#a95
55537
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] RE: Zend_Db_Table_Row __get()
I did say that changing it might cause more problems. And sure enough it
appears that other components assume column names are lower case. So
basically I don't think you can have mixed case column names.
Funny thing is that someone from Zend just committed this change to svn.
Wonder if they ran the unit tests before hand? Wonder if we even have
tests for the table object? Not in the delivery package.
I tried this solution, modifiying /Zend/Db/Pdo/Abstract line 95:
// force names to lower case
$this-_connection-setAttribute(PDO::ATTR_CASE,
PDO::CASE_LOWER);
to
// force names to lower case
$this-_connection-setAttribute(PDO::ATTR_CASE,
PDO::CASE_NATURAL);
and now the app completely crashes with many notices like:
Notice: Undefined index: field in
/../library/Zend/Db/Adapter/Pdo/Mysql.php
on line 139
Notice: Undefined index: field in
/../library/Zend/Db/Adapter/Pdo/Mysql.php
on line 142
Notice: Undefined index: type in /../library/Zend/Db/Adapter/Pdo/Mysql.php
on line 144
Notice: Undefined index: default in
/../library/Zend/Db/Adapter/Pdo/Mysql.php on line 145
Notice: Undefined index: null in /../library/Zend/Db/Adapter/Pdo/Mysql.php
on line 146
Notice: Undefined index: key in /../library/Zend/Db/Adapter/Pdo/Mysql.php
on
line 151
I looked it up and its the describeTable function within MySQL's extension
of the PDO. Any ideas?
Art Hundiak wrote:
Basic problem is that the pdo adapter has:
// force names to lower case
$this-_connection-setAttribute(PDO::ATTR_CASE,
PDO::CASE_LOWER);
You will have to figure out how to change it to CASE_NATURAL. Even then
I
suspect you might have trouble with case sensitivity.
I myself rather liked the camel case conversion. It being dropped is
one
of the reasons I gave up on Zend_Db.
It appears that all column preparation has been removed on each row.
0.8 Usage:
CREATE TABLE `accounts` (
`id` int(11) NOT NULL auto_increment,
`date_entered` datetime default NULL,
`date_modified` datetime default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
foreach($this-account as $account)
{
echo $account-dateModified;
}
Current 0.9 Usage: (untested)
foreach($this-account as $account)
{
echo $account-date_modified;
}
I never liked the camel-casing. I found it confusing. I like the 0.9
usage
better because I know exactly what to expect. The camel-casing limited
system predictability. (This can of course be argued both ways).
Bug? Feature?
-Original Message-
From: Aaron Egaas [mailto:[EMAIL PROTECTED]
Sent: March 19, 2007 10:26 AM
To: fw-general@lists.zend.com
Subject: [fw-general] Zend_Db_Table_Row __get()
Hello,
Prior to 0.9, I was using underscored field names in my MySQL database
and
relying on Zend_Db's inflector to produce nice Camel-cased field names
within the Zend framework. Since 0.9 with the inflector gone, I
switched
my
field name in the database to camel case so I didn't have to refactor a
lot
of code. Unforunately I think I found a bug when I did this.
All over my app I get exceptions saying the field (jobId for example)
isn't
found! I dumped out the Db_Row and all the fieldnames have been lower
cased.
I'm using MySQL's PDO. Anyone know whats causing my plight?
-Aaron Egaas
--
View this message in context:
http://www.nabble.com/Zend_Db_Table_Row-__get%28%29-tf3428196s16154.html#a95
55537
Sent from the Zend Framework mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/Zend_Db_Table_Row-__get%28%29-tf3428196s16154.html#a9556665
Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] $db-setRowClass $db-setRowsetClass
In Zend_Db_Table_Abstract::fetchAll() we have
$data = array(
'table'= $this,
'data' = $this-_fetch('All', $where, $order, $count,
$offset),
'rowclass' = $this-_rowClass
);
return new $this-_rowsetClass($data);
And in Zend_Db_Table_Rowset_Abstract::__construct() we have:
if (isset($config['rowClass'])) {
$this-_rowClass = $config['rowClass'];
}
Almost as though the code was released without testing. Which I guess is
consistent with the fact that there are no DB_Table/Row tests in the
delivered version.
Hi Simon,
Yup, setting protected $_rowClass = 'Account'; does work. However, I plan
on
lazy loading a lot of my definitions so I can do something like:
class Accounts extends Custom_Db_Table_Which_Extends_Zend_Db_Table
implements Custom_Action_Insert_Delete_Authorize
{
public function _setup($config = array())
{
$this-_name = __CLASS__;
$this-setRowClass(
Utility_String_Ucfirst::returnString(
Utility_String_Inflector_Singularize::returnString(
$this-_name)));
parent::_setup($config);
}
}
Really it's six in one and half a dozen in the other, just a personal
preference, seeing how far I can push ZF. Unfortunately, this method
didn't
work from my initial tests, bringing us to the problem at hand.
Alas, I do need the custom rowset. I have some methods on the entire
resultset that I'd like to use in the future. (For instance, pagination
utilizing view helpers).
I'd really like if you (or someone) can poke around and see what's going
wrong, if anything. Otherwise my experience during my upgrade has been
very
positive.
Thanks! Hope to hear from you soon!
-Ryan
_
From: Simon Mundy [mailto:[EMAIL PROTECTED]
Sent: March 19, 2007 2:35 PM
To: Ryan Brooks
Cc: fw-general@lists.zend.com
Subject: Re: [fw-general] $db-setRowClass $db-setRowsetClass
Hi Ryan
I had a quick look at your table/row definitions.
This will work:-
class Accounts extends Zend_Db_Table
{
protected $_name = 'accounts';
protected $_rowClass = 'Account';
}
You don't need the extra Rowset definition if there's no specific
functionality you need to add - in most cases the default rowSet class is
adequate.
What puzzles me is that your '$this-setRowClass('Account')' _should_ have
worked. I'll do some digging later to see if anything is awry and post a
JIRA issue if it turns out to be the case.
Cheers
Update:
Now I know I've missed something.
In my debugging process, here's what I did.
Open: Zend/DB/Table/Rowset/Abstract.php
Goto Line: 71
Replace Value of: protected $_rowClass = 'Zend_Db_Table_Row'
With: protected $_rowClass = 'Account'
Have access to Account-helloWorld();
I'll keep digging, I seem to be missing a step along the way.
-Ryan
PS: Undo changes, save. ;)
--
Simon Mundy | Director | PEPTOLAB
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124
http://www.peptolab.com
[fw-general] Writing Zend Article Site?
There are a number of fine Zend Framework related articles and tutorials on the web. I'm thinking about adding to the collection but am too lazy to setup and admin my own wiki type site. Does anyone know a good site where they will let you create a multi-page article/document with code syntax highlighting?
Re: [fw-general] Zend_View, reference inside helpers
Yep. Think they really should have a separate template renderer class. But what they do have seems to work well enough as long as tweaking is not required. Art Hundiak wrote: Be nice if we could just extend the view class and tweak it but someone went 'private' happy when they wrote the code. Actually private variables are there for a reason. And it's pretty clever. They're protecting internal properties from being accessed directly form the view scripts. But it makes subclassing a hell at the same time. -- Martel Valgoerad aka Michal Minicki | [EMAIL PROTECTED] | http://aie.pl/martel.asc =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Idleness is not doing nothing. Idleness is being free to do anything. -- Floyd Dell
Re: [fw-general] DB Table
Ian,
Might be better off just building a query with Zend_Db_Select. The manual
has examples. Be aware that the .8 version of Zend_Db_Select is basically
non-functional so use the .7 version.
-- Ian Warner [EMAIL PROTECTED] wrote
(on Thursday, 08 March 2007, 05:56 PM -):
That would be why then :)
Been pulling my hair out for quite a while to solve this.
So it is basically not possible to do a COUNT(*) etc or any
functionality
with the column selects
Well, it is possible, just not using the class's find() and fetchAll()
methods.
I have methods like the following in many of my Zend_Db_Table classes:
public function fetchInfo($id)
{
$select = $this-select();
$select-from($this-_name, array('id', 'username', 'email'))
-where('id = ?', $id);
$row = $this-getAdapter()-fetchRow($select);
return $row;
}
You don't end up with Zend_Db_TableRow|set results, but you do end up
getting the exact columns you desire -- and you can use constructs like
COUNT(*) in your from clause in your select object. I've found
Zend_Db_Table + Zend_Db_Select to be a very flexible, powerful
combination.
-Original Message-
From: Bill Karwin [mailto:[EMAIL PROTECTED]
Sent: 08 March 2007 17:52
To: Ian Warner; Zend Framework General
Subject: RE: [fw-general] DB Table
From: Ian Warner [mailto:[EMAIL PROTECTED]
Now I want to be able to adjust what columns are selected I cannot
see
this in the DB table code or in the documentation.
Currently Zend_Db_Table selects all columns from the table.
It is currently a feature request to allow the app to specify which
columns it fetches. This is not implemented yet.
http://framework.zend.com/issues/browse/ZF-694
To be honest, I would have to say that it is not likely to be
implemented in the next release of Zend_Db.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend.php proposal
Almost seems like Zend_Registry is being designed using a mailing list thread. I thought there was supposed to be a proposal process followed by a review process then some incubator code and testing. Oops. Wait a second. we did have a proposal. It was reviewed and approved. And code was checked into the incubator. But then some deleted it. Very sad. In any event, the attached files match roughly 99% of what has been discussed on this thread. Maybe they will save someone some typing. Registry.php Description: Binary data
Re: [fw-general] Zend.php proposal
E is good. Would suggest that Zend::dump be moved to a Zend_Debug class instead of Zend_Log. Logging and debugging are different concepts. But it's a minor point. I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 If Solution E is acceptable, I move that we proceed with that implementation. We need to implement the change (including updating other components, unit tests, and docs) by the code-freeze or else we will live with the current Zend.php! Regards, Bill Karwin
Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
although that would add one line of code (require) to a ZF bootstrap for those not using autoload. Is the use of autoload really the core issue here? I kept trying to understand the comments about needing additional require statement if the Zend class was split. Are there really people using the framework without autoload? And if so then would adding one or two more requires be a big deal for an app that already has 20 or 30 in their bootstrap file? How about we split the Zend methods into individual classes but continue to deliver a Zend class which simply passes on the methods to the correct classes? And then perhaps drop it later on once all the existing applications and tutorials get updated. -- View this message in context: http://www.nabble.com/Request-for-feedback%3A-moving-Zend.php-to-Zend-Zend.php-tf3290016s16154.html#a9239052 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
Really no need to tell if a given name represents a package or not. Zend ..Filter Filter.php contains Zend_Filter_Filter Alpha.php contains Zend_Filter_Alpha So the only change is the name of the top level class in a package. The autoload routine remains unchanged. And of course if there was a module that was more or less independent from the other filter modules (perhaps some code for a specific language) then you could make is a subpackage. It really does make sense and except for doubling up some of the top level class names has no impact on the current design. Stanislav Malyshev wrote: The problem is that in Zend/ directory there are a lot of php files: Ok, there is. Why it is a problem though? It would be much better to move them to: Acl/Acl.php Ok, and Zend_Acl_Adapter would be in Acl/Adapter/Adapter.php or in Acl/Adapter.php? If the former - how it's not directory per file? If the latter, why Zend_Acl gets subdirectory and Zend_Acl_Adapter not and how one is to know that by the name? So this means that all package files would be in package directory. If u need only one package u take the package directory. How do I know Zend_Foo_Bar_Baz is a package or part of Zend_Foo_Bar package or part of Zend_Foo package? If file is in a directory - it is in package, and u know package name[directory name] How do I know the directory name? You seem to have different rules for packages and not packages but I fail to see how do you know the name is package or not. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- View this message in context: http://www.nabble.com/Request-for-feedback%3A-moving-Zend.php-to-Zend-Zend.php-tf3290016s16154.html#a9190465 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
+1 for moving Zend.php (and only Zend.php) down one level. +1 for cleaning Zend.php up and moving the methods into their proper locations before the 1.0 release after which it would really be difficult to make such changes. Yes it will be a pain to change existing apps for the .9 release. However, keep in mind that the entire Zend_Db system is being completely redesigned from scratch with little or no concern for backwards compatibility. App changes required to support the Zend changes will pale in comparison to those needed to support the new Zend_Db implementation. Hello, In all provided solutions by other frameworkers, I still find this solution the best one, at least for now. Ralph E's ideas were also very good, but some components would have to mature some further, before they would actually deserve to be a standalone component. For instance take Zend_Debug: do we really want a Zend_Debug class with only a single static method? In my opinion, if we would move Zend::debug to a standalone component, this would have to go through the standard proposal process, before any drastic changes are made. Guys we are almost reaching 0.9, and changes like those will do us more harm than good (at least in this stage). Simply moving Zend.php only level down will save us from all the hassle, and quick decision making, which isn't good anyways. One exception to the rule ... is that so bad? Our Dutch language has more exceptions than actual rules ... Best, Andries Seutens Bill Karwin schreef: Please take a look at http://framework.zend.com/issues/browse/ZF-958 We propose to move Zend.php to zf-home/library/Zend/Zend.php. The class name would continue to be 'Zend', and we're not suggesting changing any methods within the class. Therefore no usage of this class would change. The only change in your application would be that you need to change this: require_once 'Zend.php'; To this: require_once 'Zend/Zend.php'; Alternatively, you could add the 'Zend' directory to your include_path. The benefit of this change is to simplify integration of a Zend Framework tree in an application tree. You could use svn externals, for instance. The disadvantage is that it does not follow the ZF convention that class names always match the physical location of the class file. But this is the only class that needs to be an exception to this convention. I volunteer to make this change. I'll update other classes in the ZF tree. I'll write a note in the manual to tell users what they need to do. I'll write a docblock in Zend.php acknowledging that it is an exception to the class-to-location convention. If there are no strong objections, I'll make this change. Regards, Bill Karwin -- Andries Seutens http://andries.systray.be Gecontroleerd op virussen door de JOJO Secure Gateway.
[fw-general] Zend_Mail PHP 5.2.0
Has anyone tried Zend_Mail on a PHP 5.2.0 machine? A simple working app of mine stopped working after the host upgraded from 5.1.x The example from the manual generates: /usr/sbin/sendmail: unexpected response 501 to RCPT TO command Followed by an exception. Same code is working fine on a 5.1.6 machine. Thanks in advance
Re: [fw-general] Zend_Mail PHP 5.2.0
I'm actually using the default Sendmail.php transport. The exception
message does not contain any useful info since the php mail() function
only returns FALSE on failure.
Here is my test program. I replaced the real email addresses with xxx.com
and xxx894.org
$ cat email_test.php
?php
error_reporting(E_ALL);
require_once './config.php';
require_once 'Zend/Mail.php';
$mail = new Zend_Mail();
$mail-setBodyText('This is the text of the mail.');
$mail-setFrom('[EMAIL PROTECTED]', 'Art Hundiak');
$mail-addTo('[EMAIL PROTECTED]', 'Art Hundiak');
$mail-setSubject('TestSubject');
$mail-send();
/* -
* The actual php mail() seems to work
* using an example from the manual
*/
$to = '[EMAIL PROTECTED]';
$subject = 'the subject';
$message = 'hello';
$headers = 'From: [EMAIL PROTECTED]' . \r\n .
'Reply-To: [EMAIL PROTECTED]' . \r\n .
'X-Mailer: PHP/' . phpversion();
mail($to, $subject, $message, $headers);
?
And here is a Zend::dump($this) from inside of the transport object when
mail() fails.
(hathor.telana.com:ahundiak) /home/ahundiak/ws2007/osso2007/apps/mail
$ php email_test.php
/usr/sbin/sendmail: unexpected response 501 to RCPT TO command
object(Zend_Mail_Transport_Sendmail)#3 (10) {
[subject] = NULL
[EOL] = string(1)
[body] = string(29) This is the text of the mail.
[boundary] = string(0)
[header] = string(162) From: Art Hundiak [EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
[_headers:protected] = array(6) {
[From] = array(2) {
[0] = string(36) Art Hundiak [EMAIL PROTECTED]
[append] = bool(true)
}
[To] = array(2) {
[0] = string(33) Art Hundiak [EMAIL PROTECTED]
[append] = bool(true)
}
[Subject] = array(1) {
[0] = string(11) TestSubject
}
[Content-Type] = array(1) {
[0] = string(32) text/plain; charset=iso-8859-1
}
[Content-Transfer-Encoding] = array(1) {
[0] = string(16) quoted-printable
}
[Content-Disposition] = array(1) {
[0] = string(6) inline
}
}
[_isMultipart:protected] = bool(false)
[_mail:protected] = object(Zend_Mail)#1 (13) {
[_charset:protected] = string(10) iso-8859-1
[_headers:protected] = array(3) {
[From] = array(2) {
[0] = string(36) Art Hundiak [EMAIL PROTECTED]
[append] = bool(true)
}
[To] = array(2) {
[0] = string(33) Art Hundiak [EMAIL PROTECTED]
[append] = bool(true)
}
[Subject] = array(1) {
[0] = string(11) TestSubject
}
}
[_from:protected] = string(20) [EMAIL PROTECTED]
[_to:protected] = array(1) {
[0] = string(17) [EMAIL PROTECTED]
}
[_recipients:protected] = array(1) {
[[EMAIL PROTECTED]] = int(1)
}
[_returnPath:protected] = NULL
[_subject:protected] = string(11) TestSubject
[_bodyText:protected] = object(Zend_Mime_Part)#2 (10) {
[type] = string(10) text/plain
[encoding] = string(16) quoted-printable
[id] = NULL
[disposition] = string(6) inline
[filename] = NULL
[description] = NULL
[charset] = string(10) iso-8859-1
[boundary] = NULL
[_content:protected] = string(29) This is the text of the mail.
[_isStream:protected] = bool(false)
}
[_bodyHtml:protected] = bool(false)
[_mimeBoundary:protected] = NULL
[hasAttachments] = bool(false)
[_parts:protected] = array(0) {
}
[_mime:protected] = object(Zend_Mime)#4 (1) {
[_boundary:protected] = string(34)
=_514e84fd17a78051290527df8f4259f7
}
}
[_parts:protected] = array(1) {
[0] = object(Zend_Mime_Part)#2 (10) {
[type] = string(10) text/plain
[encoding] = string(16) quoted-printable
[id] = NULL
[disposition] = string(6) inline
[filename] = NULL
[description] = NULL
[charset] = string(10) iso-8859-1
[boundary] = NULL
[_content:protected] = string(29) This is the text of the mail.
[_isStream:protected] = bool(false)
}
}
[recipients] = string(33) Art Hundiak [EMAIL PROTECTED]
}
Does the exception contain an example of the SMTP command? A 501
means that the request is a bit screwy.
Perhaps if you could look at enabling the debug constant (line 44 of
Zend/Mail/Transport/Smtp.php) and it will display the transaction so
you can see what is going on and email the list with the results?
Would be happy to fix for you ASAP.
Cheers
Has anyone tried Zend_Mail on a PHP 5.2.0 machine? A simple
working app
of mine stopped working after the host upgraded from 5.1.x
The example from the manual generates:
/usr/sbin/sendmail: unexpected response 501 to RCPT TO command
Followed by an exception.
Same code is working fine on a 5.1.6 machine.
Thanks in advance
--
Simon Mundy | Director | PEPTOLAB
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice
