Of course people use them. No one is talking about removing those
methods. You would still have the dump, registry and loadClass methods
for your use -- but in separate classes.
The question is whether they should all be in a single common class that
is loaded every request. My point in my sur
On 3/1/07, Christopher Thompson <[EMAIL PROTECTED]> wrote:
I just did a quick survey to see what in Zend.php is used within the
framework. I note that Zend_Cache chose not to use Zend::loadClass. And
the controller code, which was the original user of this code, should
probably have its own spec
I just did a quick survey to see what in Zend.php is used within the
framework. I note that Zend_Cache chose not to use Zend::loadClass. And
the controller code, which was the original user of this code, should
probably have its own special purpose loader. In general, nothing in
Zend.php is rea
btw.: I am not using autoload.
"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.
"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
Matthew Ratzloff wrote:
The existing one [Zend_Registry] works perfectly well.
It uses __set() and __get(), and implements ArrayObject.
Thank you :) .. there was an amazing amount of debate over this for months,
before the current solution became accepted. I vastly prefer the new
Zend_Registr
Andi,
I am glad you and Bill are considering alternate solutions, but I honestly
find the "multiple classes in one file" method to be more confusing than
the current state of affairs. Premature optimization.
> We still believe having all the core functionality in one file is
> beneficial. While
Hey Ralf (Andi et al.),
You have been putting together some points that I've been trying to
make but have come short due to lack of patience in developing the ideas
more fully. I think we are on the same page.
Yes, I too think making a Zend.php class that has multiple layers of
unrelated f
> 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?
Got the idea u are asking about Zend class lo
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?
couse it is not strict package separation
It would be much better to move them to:
Acl/Acl.php
Ok, and Zend_Acl_Adapter would be in Acl/Adapter/Adapter.p
Keeping this functionality in one class makes sense to me. The main change
we'd need to make to our code is changing lines like:
$db = Zend::registry('db');
to:
$db = Zend_Registry::registry('db');
I guess I could suggest simplifying the register/registry method names since
the duplication of t
my +1 for Ralf
Having four classes in one file is even a bigger break of consistency than the
current solution, in my eyes.
Otherwise I totally agree with Andi's simplicity goal. I don't want to have
more than one require_once in my bootstrap. Zend/Core.php sounds good and
should have some basi
We could just go down the separation path. I'm just worried it's going
to be a PITA to require the various classes. It also doesn't give us a
centralized bootstrap if we require it down the road (I don't
expect all
to use the MVC).
I would have asked the same questions Rob already has but I w
Hi Andi and all others,
I am sorry but I think keeping four classes in one file is even worse
than the current Zend class. Sounds a bit like premature optimization.
Many framework beginners already have problems to understand the purpose
of the Zend class. I am afraid that with your approach confu
5 PM
> To: fw-general@lists.zend.com
> Subject: Re: [fw-general] Request for feedback: moving
> Zend.php to Zend/Zend.php
>
> I gotta agree with Christopher on this one.. I have zero
> intentions of using the 'Registry' in 80%+ of my projects.. I
> find that the controllers
Rob has very nicely broken down the use cases pretty much exactly as I
see them as well.
Rob Allen wrote:
Andi Gutmans wrote:
Hi Ralf and all,
Bill and I spent some time reviewing all the proposals and also
brainstorming on what we think is right for Zend Framework. Our
suggestion is very cl
Andi Gutmans wrote:
> Hi Ralf and all,
>
> Bill and I spent some time reviewing all the proposals and also
> brainstorming on what we think is right for Zend Framework. Our
> suggestion is very close to what Ralf is suggesting but with a few
> minor tweaks.
Good to see movement on this issue :)
uesday, February 27, 2007 10:15 PM
> To: fw-general@lists.zend.com
> Subject: Re: [fw-general] Request for feedback: moving
> Zend.php to Zend/Zend.php
>
> I gotta agree with Christopher on this one.. I have zero
> intentions of using the 'Registry' in 80%+ of my projec
won't matter. The overhead is per-file
not really per-class.
Andi
> -Original Message-
> From: Christopher Thompson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 27, 2007 9:56 PM
> Cc: fw-general@lists.zend.com
> Subject: Re: [fw-general] Request for feedback: m
Nick Lo wrote:
> I noticed a few comments to the effect that Zend.php makes a good entry
> point into the framework. I really don't see how this is the case. The
> entry point for anyone wanting to get a grasp on the framework is the
> bootstrap file not Zend.php.
I agree. To understand the MVC fr
I gotta agree with Christopher on this one.. I have zero intentions of
using the 'Registry' in 80%+ of my projects.. I find that the
controllers invoke params suit all my needs. As for debug, I simply
cant find any justification for loading that into production/runtime..
To reiterate a very i
ut only focus on bug fixes, and
improving documentation and unit tests.
Andi
-Original Message-
From: Ralf Eggert [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 1:58 AM
To: fw-general@lists.zend.com
Subject: Re: [fw-general] Request for feedback: moving
Zend.php to Ze
y 26, 2007 1:58 AM
> To: fw-general@lists.zend.com
> Subject: Re: [fw-general] Request for feedback: moving
> Zend.php to Zend/Zend.php
>
> Hi,
>
> I personally think that the proposed renaming of the Zend
> class to Zend_Framework is very misleading. I would expect
+1 (belated) to Ralf's suggestions.
Ralf Eggert wrote:
Hi,
I personally think that the proposed renaming of the Zend class to
Zend_Framework is very misleading. I would expect that a Zend_Framework
class will set up the whole framework and not be just a funny
conglomeration of methods who did
I noticed a few comments to the effect that Zend.php makes a good
entry point into the framework. I really don't see how this is the
case. The entry point for anyone wanting to get a grasp on the
framework is the bootstrap file not Zend.php.
If anything Zend.php is a confusing class that im
Right...
Don't forget the very essence of a framework. Yes, that is correct, a
framework, not a package repository. The framework will always be
released as a "whole", not in separated packages.
Current naming conventions are just fine. It's just Zend.php that could
use some reorganisation,
I'd prefer Zend_Filtered_Filthy_Fill_Filter_Filter_Filter !
This would make life so much easier.
To cache a cache may also be more efficient, who knows. I'd definitely use
Zend_Cache_Cache. We also do zip our jpegs, right?
Stanislav Malyshev wrote:
>> Really no need to tell if a given name repre
Zend_Acl_Role => Zend_Acl_Role_Role
Zend_Acl_Resource => Zend_Acl_Resource_Resource
Zend_Cache => Zend_Cache_Cache
That's really no good... What should Cache-Cache mean?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
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
Zend_Filter_Filter? So instead of Zend_Json we'd have Zend_Json_Json? I
don't like it at all.
It really does make sense and
I don't quite see the point of this at all.
How is a Zend_Cache_Cache more useful than a Zend_Cache? It reduced
the clarity of a component name if you start adding unnecessary
suffixes to it.
It seems the only benefit here is to 'clean up' the core Zend folder
and I don't see that as much
> Here are a few more examples of renaming the top-level class/sub-class
> names:
>
> Zend_Acl_Role => Zend_Acl_Role_Role
> Zend_Acl_Resource => Zend_Acl_Resource_Resource
> Zend_Cache => Zend_Cache_Cache
> Zend_Cache_Backend => Zend_Cache_Cache_Backend_Backend
> Zen
Here are a few more examples of renaming the top-level class/sub-class
names:
Zend_Acl_Role => Zend_Acl_Role_Role
Zend_Acl_Resource => Zend_Acl_Resource_Resource
Zend_Cache => Zend_Cache_Cache
Zend_Cache_Backend => Zend_Cache_Cache_Backend_Backend
Zend_Db
Even if not everyone wants the features below, certainly many developers
will implement similar capabilities, if not found in the ZF. My
intention behind http://framework.zend.com/wiki/x/j1 is merely to find a
mutually-agreeable way to support the possibility of adding
*utility-like* features
Oops! I agree - the code in Zend.php could be split up into specialized
components and obsolete code could be eliminated. I just over-looked the
earlier discussions on this thread while posting my message.
On 2/27/07, Matthew Ratzloff <[EMAIL PROTECTED]> wrote:
> For what it's worth, it is i
> For what it's worth, it is ideal to retain the Zend.php instead of
> splitting it up so the framework could build more utility functions into
> it in future - that does not fit anywhere. How about renaming it to
> Zend_Util, instead?
I can't imagine any utility methods that would be needed that
Yes, this reduces the clutter in the Zend folder and improves
file-organization.
And Zend.php could be renamed to Core.php or Main.php and moved into Zend
folder with Zend_Core/Zend_Main class in it. Alternatively, Zend.php can be
safely moved into Zend folder (without any exceptions) and that fi
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 th
Nico Edtinger wrote:
[27.02.2007 19:04] Tautvydas Andrikys wrote:
So this means that all package files would be in package directory.
If u need only one package u take the package directory.
Won't work. The unit that you call packages are not (always)
independent and just because some files
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
[27.02.2007 19:04] Tautvydas Andrikys wrote:
So this means that all package files would be in package directory.
If u need only one package u take the package directory.
Won't work. The unit that you call packages are not (always)
independent and just because some files are in one directory
Tautvydas Andrikys wrote:
If Alpha would be in differenet package it would be moved to that
package directory
How I know by its name if it's a package or not?
If file is in a directory - it is in package, and u know package
name[directory name]
I don't becoming a PEAR-like repository
Stanislav Malyshev wrote:
why we need to repeat Zend_Filter twice?
Zend_Filter would not be repeated twice. Zend/Zend_Filter.php would
be moved to Zend/Filter/Zend_Filter.php
I clearly see Zend and Filter repeated twice right in front of me. Do
you?
oh u mean file name repeat :) i dont think
Ya, sorry, my mistake[too much use of __autoload :)]
Shekar C Reddy wrote:
Hi Tautvydas,
You are confusing Stanislav with the mis-typed file-names:
Zend/Filter.php => Zend/Filter/Filter.php [not: Zend_Filter.php,
Zend_Filter is the name of the class]
Zend/Filter/Filter/Alnum.php [no change
why we need to repeat Zend_Filter twice?
Zend_Filter would not be repeated twice. Zend/Zend_Filter.php would be
moved to Zend/Filter/Zend_Filter.php
I clearly see Zend and Filter repeated twice right in front of me. Do you?
Every package would be strictly separated. Now all packages are mixed
Hi Tautvydas,
You are confusing Stanislav with the mis-typed file-names:
Zend/Filter.php => Zend/Filter/Filter.php [not: Zend_Filter.php, Zend_Filter
is the name of the class]
Zend/Filter/Filter/Alnum.php [no change, couse it is same package]
Zend/Filter/Filter/Alpha.php [no change, couse it is
Perhaps moving Zend.php to Zend/Core.php as-is AND making new classes to
replace it is the better solution.
We can make the move from Zend to Zend_Core and people can easily do a
global search-replace to handle it.
Once Zend_Core is in the framework, you can basically turn each of it's
functions
U misunderstood me. Not every class gets its own directory, but every
package gets its own directory.
Now every package has its own directory and one file in parent
directory, so i offer to move all files to package directory:
Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
Zend/Filter/Zen
Yeah I agree with Stanislav - the thinking behind the original
request was just to tuck the Zend.php file away, not the whole
framework.
The PEAR-like directory structure works pretty well as-is and I'd
daresay most people can get to grips with it quickly.
I'd be happy moving Zend.php ->
Now every package has its own directory and one file in parent
directory, so i offer to move all files to package directory:
Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
Zend/Filter/Zend_Filter_Alnum.php [no change, couse it is same package]
Zend/Filter/Zend_Filter_Alpha.php [no change, co
So:
Zend/Db.php => Zend/Db/Db.php,
Zend/Db/Table.php => Zend/Db/Table/Table.php
So each class gets its own directory or what? Doesn't make much sense to
me. Do I miss something?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Massive -1 on this unless we decided to tackle some issues that have
been raised in the past:
I don't see much of a problem with Zend class doing a number of
functions. It's an utility class so it does a number of things, but
having class for each of these functions would not really do much us
I agree completely with Ralf, Simon, Matt R, and others regarding
eliminating the current Zend.php class and splitting it up to achieve
the flexibility and clarity the ZF has become famous for. In fact, I was
pushing for something similar to this in an uncommitted version
pre-0.7. Bill and I b
+1 with Ralf too.
One note: maybe not a Zend_Loader class, but a Zend_File class, in fact
mehtods like loadFile(), isReadable() and loadClass() sounds after files.
Rest Regards,
Waldemar
Ralf Eggert schrieb:
> Hi,
>
> I personally think that the proposed renaming of the Zend class to
> Zend_Fr
Ralf,
I cannot agree with you and Ralph more.
Drop Zend.php altogether. Finalize Zend_Registry and move to the core.
Create Zend/Debug.php and Zend/Loader.php by moving the corresponding
methods into them, and keep those methods static. Let Zend_Environment
handle version checking--that's what
+1 with Ralf,
ZF is designed to be used as a component system, so why not drop Zend.php if
this is realistic to do so for 0.9. The minor changes required to our files
is quite worth it.
best wishes,
Simon
Request for feedback: moving Zend.php to Zend/Zend.php
I agree with what Ralph and now many others are saying. +1. I'm a newbie, and
like most programmers, do better with things that are logical and intuitive.
The Zend class was a bit of a mystery to me until I read this discussion. A
class named Ze
I agree with what Ralph and now many others are saying. +1. I'm a newbie, and
like most programmers, do better with things that are logical and intuitive.
The Zend class was a bit of a mystery to me until I read this discussion. A
class named Zend meant nothing except that it was required to make
+1 to this
I really do not understand why a simple command like this
svn co http://framework.zend.com/svn/framework/trunk/library ZendFramework
or a svn:externals property like
ZendFramework http://framework.zend.com/svn/framework/trunk/library
seems to be so problematic for you guys...
Le lundi
+1 on renaming Zend.php to Zend/xxx.php
(I'd go with Zend_Core)
On 2/26/07, Ramon de la Fuente <[EMAIL PROTECTED]> wrote:
My 2cents..
I think removing Zend.php from the main directory would make the whole
structure more daunting from the point of view of a "beginner". That
"first" file is a v
-1 on all accounts.
I've only read a couple of reasons to do this and none of them are
particularly compelling:
1) Sub-optimal performance
- Only in the most extreme cases will this make any difference. In most
cases, the time to search n more directories in the path to find a file
won't result
+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
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
-1 on all accounts, leave it where it is.
Is it really that difficult to have your 'libs' folder seperated out
by what it is? Mine looks as follows:
libs/lib-pear
libs/lib-zend
libs/lib-vlx
libs/lib-am
with lib-zend being svn:externals to a specific revision, and lib-
vlx, and lib-am being
Shuffling the files one level down - sounds good to me.
On 2/26/07, Tautvydas Andrikys <[EMAIL PROTECTED]> wrote:
Hi,
I think the best solution would be to change naming conventions, so that
the main class of a package would be in package directory, like in Java.
And as Ralf suggested class
After reading the other mails:
+0 moving Zend.php - I'd use a Makefile and not svn:external
-1 renaming the class - this class is the difference between a
library and a framework
-0.8 splitting it - same as above
nico
[26.02.2007 00:27] Bill Karwin wrote:
Please take a look at http://f
Hi,
I think the best solution would be to change naming conventions, so that
the main class of a package would be in package directory, like in Java.
And as Ralf suggested class Zend could be removed.
So:
Zend/Db.php => Zend/Db/Db.php,
Zend/Db/Table.php => Zend/Db/Table/Table.php
...
This way
-- Ralf Eggert <[EMAIL PROTECTED]> wrote
(on Monday, 26 February 2007, 10:58 AM +0100):
> - drop Zend::exception() and Zend::loadInterface()
Just a note: Zend::loadInterface() has been deprecated for several
releases and throws an exception (I do have a proposal on the table to
make Zend::loadClas
Here's my +1 for Ralf's proposal!
Actually, I liked the way of using an entry class. But I just liked it as there
were not enough real-world examples around at the time I started to work with
ZF 0.1.5. For a beginner a Zend class entry point definitely makes sense. It's
always nice to "have som
ALthough it's still currently 'to do', the following will work as of 0.9
$environment = new Zend_Environment(new Zend_Environment_Core
('framework'));
if ($environment->framework->isVersion('0.9')) {
}
- the only method I am not sure about yet is Zend::compareVersion()
but
I bet
On 26/02/07, Andrew Yager <[EMAIL PROTECTED]> wrote:
Hi All,
On 26/02/2007, at 8:58 PM, Ralf Eggert wrote:
> I personally think that the proposed renaming of the Zend class to
> Zend_Framework is very misleading. I would expect that a
> Zend_Framework
> class will set up the whole framework and
Hi All,
On 26/02/2007, at 8:58 PM, Ralf Eggert wrote:
I personally think that the proposed renaming of the Zend class to
Zend_Framework is very misleading. I would expect that a
Zend_Framework
class will set up the whole framework and not be just a funny
conglomeration of methods who did not
Hi,
I personally think that the proposed renaming of the Zend class to
Zend_Framework is very misleading. I would expect that a Zend_Framework
class will set up the whole framework and not be just a funny
conglomeration of methods who did not find their way to a proper component.
Here are my sugg
We propose to move Zend.php to /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 disadvantage is that it does not follow the ZF convention that
class
names
My 2cents..
I think removing Zend.php from the main directory would make the whole
structure more daunting from the point of view of a "beginner". That
"first" file is a very easy step to mentally start grasping the
framework structure.
Also, breaking the naming convention in the very first fi
Ah i found what i am searching for :)
If we change Zend to something else I think we have to fix these issues:
- http://framework.zend.com/issues/browse/ZF-944
- http://framework.zend.com/issues/browse/ZF-945
- http://framework.zend.com/issues/browse/ZF-946
- http://framework.zend.com/issues/bro
I don´t like it. To remain to the naming conventions you have to rename
Zend to something else. It is a major change which can crash very much
applications. Okay the framework is not final but I think it is a to big
change.
-- Jan
Please take a look at http://framework.zend.com/issues/browse
Ralph Schindler wrote:
> 1) Zend class is very schizophrenic when it comes to its duty.
> a) it does loading of things which are possibly better suited
> for a Zend_Loader
> b) it does registry tasks that could better be implemented as
> static get/set/has/remove method
Bill Karwin wrote:
> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to /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
>
Bill Karwin wrote:
Please take a look at http://framework.zend.com/issues/browse/ZF-958
We propose to move Zend.php to /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 chan
On 2/26/07, Kevin McArthur <[EMAIL PROTECTED]> wrote:
Bill,
> 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.
This brings up the question on whether this is how we want to recommend
the
deplo
I'm sold on strictly the easier svn:externals.
On 2/25/07, Bill Karwin <[EMAIL PROTECTED]> wrote:
Please take a look at http://framework.zend.com/issues/browse/ZF-958
We propose to move Zend.php to /library/Zend/Zend.php. The
class name would continue to be 'Zend', and we're not suggesting
ch
with only a Zend directory?
Kevin McArthur
- Original Message -
From: "Bill Karwin" <[EMAIL PROTECTED]>
To:
Sent: Sunday, February 25, 2007 4:27 PM
Subject: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
Please take a look at http://framework.zen
On 2/26/07, Shekar C Reddy <[EMAIL PROTECTED]> wrote:
Bill,
I guess this was discussed earlier and much desired. However, to work
around the exception, could we look into renaming the Zend class to
something like: Zend_Main or Zend_Public or Zend_Shared or Zend_Common or
Zend_General or Zend_Ba
I like this idea.
Shekar C Reddy <[EMAIL PROTECTED]> wrote: Bill,
I guess this was discussed earlier and much desired. However, to work around
the exception, could we look into renaming the Zend class to something like:
Zend_Main or Zend_Public or Zend_Shared or Zend_Common or Zend_General
Bill,
I guess this was discussed earlier and much desired. However, to work around
the exception, could we look into renaming the Zend class to something like:
Zend_Main or Zend_Public or Zend_Shared or Zend_Common or Zend_General or
Zend_Base or Zend_Core or Zend_Standard... so the name of the f
Please take a look at http://framework.zend.com/issues/browse/ZF-958
We propose to move Zend.php to /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
86 matches
Mail list logo
