Re: [fw-general] Zend_Amf_Server authentication
Hi! Zend_Amf_Server performs authentication only if it receives AMF CREDENTIALS_HEADER. So if my Flash app doesn't send the CREDENTIALS_HEADER it gets access to all server methods. Authentication that can be turned off by the cliet, makes no sense to me. Please explain why is it implemented this way. I think there's a confusion between authentication and authorization. Authentication checks that you are who you say you are. Authorization checks that you (with you provided by authentication) are allowed to do certain things. So, if you have some methods that are not allowed for unauthenticated user, he will be denied permission to run them. Zend_AMf does authorization through ACLs, see Authentication part in http://framework.zend.com/manual/en/zend.amf.server.html where it describes setAcl() method. So, there's two things to clarify: 1. If you didn't provide any credentials, there's nothing to authorize 2. That doesn't automatically makes you ineligible to access methods - ACL defines that. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com
Re: [fw-general] Zend_Amf on IIS
Hi! When I do the same thing with it being hosted on IIS the browser tries to download the file. If I download the file the Zend AMF Server is in it, This doesn't look like something to do with AMF... Do other PHP scripts work? It looks like your IIS is not configured correctly to handle PHP files. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com
Re: [fw-general] Amazon S3 stream wrapper
Hi! I am using AWS S3 via stream wrapper (which is great piece of code), and it works nicely with fopen/fwrite functions. However, objects added are all private, is there any way I can update ACL for object and still use streams? I guess stream API needs to support additional headers on object creation. Could you add a feature request to issue tracker for it? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com
Re: [fw-general] Zend_Captcha
Hi! Out of curiosity i just need to know if the PNGs created by Zend_Captcha gets deleted after expiration or later on. I just noticed this files can grow in immensely in number on the server and hence populate unnecessary space. Is there a way of configuring the component such that it deletes expired or used captcha images? Yes, image captcha has option expiration (default 600, in seconds) which controls how long the captcha files live, and option gcFreq which controls how often cleanup is run (default is 10 which means 1 of 10 captchas created will run cleanup cycle). -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com
Re: [fw-general] ZF application optimizations (and speedup)
Hi! Actually... loadClass() already does that. The issue is in the userland code -- if they do a require_once or include_once in userland *after* we've already loaded the class in the autoloader using simply include, that will trigger the error. That's what I was getting at. That said, AFAIK include_once does not include file previously included by include/require. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] zf-contributor list has been created!
Hi! Howdy all, the zf-contributor list has been created. Please send a mail to [EMAIL PROTECTED] to subscribe. The correct address is [EMAIL PROTECTED] I verified that it works. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Zend_Form_Element_Hash, Salt and AJAX
Hi! Salt How is the salt ment to be used? The salt is used in generating session namespace name for the element. So the name used is composed of (class name, salt, element name). That means if you have two hash elements on the same page with the same name (e.g. in different forms), they should have different salts otherwise they'll end up using same session storage. It may be useful to have different salts for elements with the same name even when they are not on the same page, but this is less important since hash stored in session is transient - i.e. it will be removed as soon as used up. Still, if there's a possibility of two hashes existing at the same time with same names, it may make sense for them to have different salts. What is the best practice when using the salt so that: - The salt of 2 forms on different pages do not collide If it's different page it shouldn't matter too much even if they collide, since the hash is transient - once form is submitted, the hash expires, so different page would not infringe on it, unless you have situation like pages loaded in frames, etc. Then maybe using module+controller or URI as salt would be fine, if you don't want to worry too much about inventing unique names. Don't choose it too long since it's used as key in session, so it's stored there too :) - The same form can be rendered 2 times (and usable on more that one browser window at a time)? Well, here it might be a problem, since right now hash element is built so that it stores only one token. You can give different salts, but you'd have to know which window has which salt. It can be done, e.g. by having another element storing the right salt, even though it doesn't seem the nicest way to build it... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Moved: Framework Security ( Was Re: [fw-general] Zend_Validate_Ip )
Hi! How is the project going to respond to a validator that is letting tainted information into applications. Maybe Matthew, as architect, can respond on what Zend is doing to address this and other security disclosures with the framework? It looks like a bug. Do you have some patch and maybe test example for it? If not, could you submit a bug to issue tracker? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
[fw-general] mailing list problems
Hi! Since our mailing lists are hosted at ThePlanet, which recently experienced major downtime event (http://service-update.theplanet.com/), we had some problems with Framework mailing lists. While the list server itself was not affected, the DNS servers it is using were, so it could not process mails normally. Because of that, some emails from the lists located at lists.zend.com and sent on June 1th and 2th could be delayed and some even gone missing. So if you have sent mail to the list on June 1th or 2th and didn't see it on the list after reasonable time, it might be good idea to resend it. Right now the lists should work normally. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Zend Loader performance - benchmark
Hi! I was thinking about this after the earlier discussions and was wondering what people thought about phar? Would this improve performance if you really needed it? phar is a bit more complicated story... We'll be doing some work on performance-testing phar too, but that'll take some time. From what I understand, phar just stabilized and acquired the features it needed to be able to run with frameworks like ZF, and I'm not sure yet how bytecode caching solutions work with it. But we definitely intend to address this topic, now that phar looks like it's ready for the prime time. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Zend Loader performance - benchmark
Hi! I've run a benchmark loading 725 framework class files on 5.2 and 5.3 with and without bytecode caching. The benchmark uses list of 725 Framework classes and loads them one by one, via require_once and via Zend_Loader::loadClass. You can see the files here: http://random-bits-of.info/fw-tests/ OK, so here's the results: Without bytecode cache: require_once Zend_Loader php5.24.42 4.42 php5.34.96 4.97 With bytecode cache: require_once Zend_Loader php5.263.04 56.62 php5.361.28 55.52 Numbers are requests per second (more is better). Bytecode cache used in the benchmark is Zend's one, not APC. Conclusions from this would be: 0. It is *very* important to understand that it is a narrow-point benchmark that tests only one function in one specific way. Please do not draw conclusions on behavior of whole applications based only on this benchmark. 1. You *do* want to use bytecode caching. You won't get 15x performance on any real application, but it does speed up loading very significantly. 2. Without bytecode caching, it doesn't matter if you use require_once or Loader - both are equally slow :) 3. With bytecode caching, Loader has some overhead - explanation for this is that with file accesses eliminated, require_once of course has little left, while Loader still does a couple of function calls. But on real-life apps it'd probably be very small, provided that it's about 10% even on loading-only huge-class-list benchmark, and your application probably does something useful instead of loading 700+ framework classes :) 4. 5.3 is still a moving target, to don't put too much stake in current benchmark results for 5.3, they probably will be different by the time 5.3 is in release cycle (hopefully, better :) If you have more questions on this, please ask. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Re: 1.5.0 Zend_Loader, auto load and non-existent classes
I tend to agree that the autoloader function should not produce errors, Does it produce error or warning? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Re: 1.5.0 Zend_Loader, auto load and non-existent classes
Depends on the situation. For example, if you autoload with Zend_Loader a class for which the file does not exist, include_once emits a warning. If the file exists, and it contains a parse error, it is not suppressed and the fatal error is handled in the normal PHP way. It's also possible I think we can omit (maybe based on configuration) the warning when file not found, but the error is OK. that user code contains something that generates other warnings or errors, and these are neither suppressed nor caught using a custom error handler. This is OK too. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Caching of MVC and other ZF components
Yes and no. Rasmus Lerdorf has explained (http://pooteeweet.org/blog/538) that opcode caching is a compile-time optimization. Runtime inclusion of code happens after compile-time is past, and therefore cannot use the opcode cache. This is not correct. Each file is compiled by the engine separately, so include can and are benefiting from opcode caching. Now, there are certain uses of certain things like inheritance that make certain opcode caches not cache these files. For APC story read here: http://t3.dotgnu.info/blog/php/demystifying-autofilter.html though it definitely does not apply to other solutions, e.g. Zend Platform. However, any runtime require_once is resolved too late to benefit from the opcode cache. For example, loading classes in a function, loading classes depending on a PHP variable, and use of autoload. The code has to be fetched from the filesystem at runtime and compiled on the fly. It's as if you aren't using an opcode cache solution. Autoload does benefit from opcode caching, as would most instances of loading classes from functions, etc. However, some things - like conditional definition of classes depending on variables etc. may not work correctly with opcode caches, and lead some of them - e.g. APC - to avoid caching those files. BTW, we plan to solve these problems in 5.3 - so that all opcode caches (that would bother to use the new stuff of course ;) will be able to cache all files in 5.3+, regardless of how and when and in which way they were included. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Caching of MVC and other ZF components
Thanks for the correction, Stas. Is the explanation attributed to Rasmus in that blog out of date, talking about an older version of PHP APC? Or is I think he was talking about autofilter, though I can't be sure. And by not caching I think he meant that defining classes/functions is not cached but left as opcodes (if you don't know the difference then probably you shouldn't care too much about it :) Will that be for Zend Platform's opcode cache only, or will it also help APC and Xcache? That would be for any opcode cache that will be willing to use it. We do not aim it specifically for Platform, but intend to make it as generic as we can. Of course, provided we indeed succeed in making it - we are in progress right now. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Zend_Form now in core!
I'm happy to report that Zend_Form is now in core! This means you will Great work! -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] ZF-2019 - Http_Client-setHeaders() in non-strict mode
Currently we throw exceptions when non-RFC-compliant HTTP headers are passed to the setHeaders() method. Following ZF-2019 I did some thinking, and it seems there is a good reason to allow a non-strict mode in which users could add their own headers. What I propose doing is one of the following: 1. Add a configuration option (strict) to the HTTP Client object (passed in the constructor or using setConfig()). This option will be set to true by default - but if set to false, will allow setting non-strict headers and possibly override some other RFC-compliance tests. I think this is the best option. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] How ZF works with PHP6 and are there any news on the subject?
Do you have any recent news about new PHP version? I searched a little, but everything I find is Minutes PHP Developers Meeting, dated November 11th and 12th, 2005. If you mean PHP 6, it's being developed, new things getting added - namespaces, ICU module, etc. but release date is probably not this year :) As for PHP 5, 5.2.4 is on the way and next one would probably be 5.3 with a bunch of interesting additions. You may want to look here: http://oss.backendmedia.com/HomePage for some progress reports. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] no php closing tag?
After going through the docs I realized that the examples with no end ? was not a typo. Is that for every php script that uses in the framework or just the framework classes? Will something bad happen if you do use '?' ? How did that design decision come about? Nothing bad happens if you use ?. However, if you use ? and after it put some whitespace, something bad does happen - this whitespace gets output, and it might be output in wrong place at the wrong time. Since closing ? is not required and anyway nothing is going to happen after ?, many people omit it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] ZF website updates
Thanks again to everyone who worked so hard on the ZF 1.0 release. We did it! Thanks for all the congratulations and well wishes. Congratulations! And good work everybody who made it happen! It's a big step. And the new site is even better :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [fw-general] Is there a way to disable echo, print inside a method
the problem is while working in a team... the programmers instead of displaying the data through template they have a habit of echoing from the method itself... have to trace where are all those crazy echosss . so it has been a lil pain in ass ... You can't really disable echo/print but you could set output buffering so you capture everything echo'ed/print'ed and then you can decide what to do with it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] New Proposal: Zend_S3
How does the development process work for a proposal to become part of the library? Usually it gets evaluated (as for how useful it would be for Framework users, should we do it, etc.), discussed (as for is this the right way to do it) and then confirmed or not confirmed, if confirmed, then it can be put into the incubator and then eventually become part of the core Framework. Here is it described in detail (with a nice picture too :): http://framework.zend.com/wiki/display/ZFPROP/Zend+Framework+Proposal+Process+Detail Since right now 1.0 release is very close, I guess it might take a bit more time until new proposals are reviewed, since people are concentrating on getting 1.0 out. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Re: [PHP-DEV] Re: [fw-general] Re: [PHP-DEV] ZF 0.8.0 Unit Tests behaving different on PHP 5.2.1 and PHP 5.2.2-dev
?php $a = 69; $b = $a.; printf(%d, $a); echo \n; printf(%d, $b); echo \n; ? PHP 5.2.1: -1689934592 2147483647 PHP 5.2.2: -1689934592 6 Huh, that's a strange thing. Why it happens? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
I think static ::get('foo') and ::set('foo', 'bar') methods are acceptable
compromises, but get() really shouldn't replace getInstance(). It
I'm OK with this.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
We really need to finish this discussion in order to have enough time to implement the changes before the code-freeze. I think we're virtually finished. To summarize: Looks OK to me. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
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 I'm not sure I understand - what I'm supposed to do now instead of Zend::dump? Also, I think that: $registry = Zend_Registry::getInstance(); $registry['key'] = 'value'; is better than: Zend::regiser(key, value) There should be some shortcuts. E.g. something like Zend_Registry::put($key, $value) and Zend_Registry::get($key) so you don't have to do getInstance each time. Also, what would become to Zend::initRegistry? Also, if we do loader class, I think it would be a good idea to interface with spl_autoload etc. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
Regarding static accessors for the special instance stored in a static variable, they can easily be added using a subclass of Zend_Registry. I'm in favor of keeping Zend_Registry as light as possible. Everything can be added. But we want our classes to be simple to use as they are, not some assembly required, do we? So why not make extra step towards the user and give people tools for working conveniently with their classes and not have everybody to rewrite these additions by themselves each time? That's would be the scenario 90% of the users would be doing anyway, so why not make it easy? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
I'm not sure I understand - what I'm supposed to do now instead of
Zend::dump?
I had in mind using the new Zend_Log class. First set up a logger:
$log = new Zend_Log(new Zend_Log_Writer_Debug('php://stdout'));
You only have to set that up once, if you store the $log object
somewhere that is accessible throughout your app.
Then you can dump a variable anytime like this:
$log-debug( $myObject );
I really don't think that's a good replacement for Zend::dump. I used it
for print-debugging a lot since it's better that var_dump and as easy as
var_dump. Now you propose to kill it and replace with two-stage
constructor and carrying over the object which I really don't need. It's
not simple. It's not easy. Zend::dump is *easy*, having two-level ctor
and additional object is *complex*. I don't like the direction we are
moving in - it's definitely looks like what I don't like in Java - you
have to do a lot of actions before you get result and care for a lot of
classes which you really don't want to know to do a simplest thing like
output debug value. I don't want to learn about log writers and
interfaces and loggin infrastructure and php://stdout and stuff just to
do a simple debug-print.
Yes, I agree. I always have to think for a split-second about which one
sets and which one gets. :-) I will be happy to see register() and
registry() become deprecated.
OK, make it get() and put() - but it should be *easy*. It should not
require knowing about singletons and instances. The concept of putting
and getting variable in registry is simple, so should be acting on this
concept in framework. If you want to do complex stuff (like having
multiple registries) then it can be complex, but easy actions should be
done by easy code. That's why we have SimpleXML - that's why we should
have SimpleRegistry and SimpleDump :)
You don't have to use getInstance() each time. If you have an object of
type Zend_Registry, just use the array notation. You are not required
I don't want to have object of type Zend_Registry - I want just global
access to registry, like I had with Zend::register(). How I do it with
Zend_Registry?
to use the default static instance of the registry. You can create an
I *want* to use it. Actually, in 90% of use cases I don't care it all
how many objects there are and what they are - I just want to put stuff
there and get stuff from there. I don't want to know how it is implemented.
instance of a Zend_Registry object and put it anywhere you want -- even
a global variable:
// in bootstrap:
$globalReg = new Zend_Registry();
// anywhere in application:
$globalReg['key'] = 'value';
Errr? So we went all this long way with registry - only to get back to
global variables? If I wanted global variables, why would I need
Framework anyway? What's the added value there?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
What if we included the subclass in the box? Both the old and the new are designed to work smoothly with subclasses. I'm not sure I understand why we would need two classes - why is it better than having once class? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
Anyway, you only need to instantiate the object once in each controller's
init() method.
public function init()
{
$this-_registry = Zend_Registry::getInstance();
// Or $this-_registry = $this-getInvokeArg('registry');
}
Here you make assumption that I use MVC and implement init() methods for
controllers. But many of the uesers would do neither, and using MVC
should not be related to using registry. Registry should be easy to use
with or without MVC. Using getInstance() requires you to know that
Registry is a singleton which is working in certain way. It is the
knowledge that in most cases you do not need.
No one's suggesting using a global variable, only that it is possible to
Well, I distinctly remember an email where somebody *was* suggesting
using global variable ;)
use Zend_Registry in many different ways. I prefer to pass it as an
invocation argument to the front controller, which makes it available to
all actions. Most others probably prefer the Singleton interface.
Again, you assume everybody uses MVC with front controller and everybody
knows what Singleton is and prefers to use it. I don't see how any of
these things should be prerequisite for using the registry.
You mentioned that new users will find the Singleton pattern confusing.
No, I don't think they should get even to finding Singleton pattern
*anything*. They don't need to know about it's existence. They shouldn't
be bothered by it.
If someone isn't familiar with basic design patterns, they'll probably
find the internals of most of the components in the framework confusing or
mysterious. For example, the front controller (it uses a Singleton as
The we already lost the game and should return to the design stage,
because deep knowledge of design patterns as the prerequisite for using
any framework is totally unacceptable if we talking about PHP target
audience. It can help you do advanced stuff, but it should not be
required. Basic usage should be - *extremely simple*.
Fortunately, I disagree with that assumption - most interfaces in
framework do not require knowledge of design patterns, unless these very
interfaces are done with purpose of implementing those patterns (like
MVC) and unless you want to do advanced stuff that requires in-depth
understanding of how Framework components are implemented. You don't
need any patterns to use Zend_Feed or Zend_Db - you just instantiate the
class and use it. We should keep it that way.
well). But just because users might not understand the internals doesn't
mean they can't use it. That's what the manual is for.
In the case of over-designed interfaces - they have to. Framework should
be so easy to use that you don't really need to read the manual for at
least basic usage - just to look at a couple of the examples and be
intuitively ready to use it without even diving into the details. Of
course, it is not always possible - if you talk about complex stuff. But
trivial stuff should stay trivial.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
Current way in Zend.php / Zend_Registry.php:
$registry = Zend::registry();
$registry = Zend_Registry::getInstance();
I like first one more, since it doesn't bother me with unneeded
knowledge about instances.
Alternative new way:
Zend_Registry::set($key, $value);
Zedn_Registry::get($key);
Same here. Of course, if we had class getters/setters it would be even
cooler, but unfortunately you can't do Zend_Registry::$key = $value yet
:) AFAIK. I'd still prefer put() to set(), but this is not that important.
With the above get(), the current instance method version of get() in
the proposal is replaced with a method that only works on the global
registry stored in the static class variable. Instance methods for
accessors remain the same as for ArrayObject (i.e. inherited as they are
now in Registry.php).
We can keep the getInstance() if you wish for those who love patterns
and singletons, but this should not be the only way. What I mean is:
static public function put($key, $value) {
$me = self::getInstance();
$me[$key] = $value;
}
etc.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
So it is the name getInstance() that is so off-putting? Well, that and having to use it each time I need the registry. Actually, the latter - if I have get/put, I could live with getInstance for advanced stuff. That sounds fine to me. As long as it's not called register() and registry()! OK with me. I think get/put is better than register/registry anyway :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
Which would be great, but it doesn't work. Actually I don't see why you need non-static get if you already have array and object syntax working. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
OK with me. Only point is we need to ensure we don't get strange result
with call to get($foo) when $foo is not defined or defined to some
strange value. But actually if you give me get/set I can tolerate
getInstance too. :)
I'm not in favor of this; aliases that offer no difference in
functionality or usability are not consistent with the goal of
protecting users from excessive choices.
But now that we think of the get() method as static-only, as Stas points
out there is no need to call it on an object, then get() with no
arguments is actually equivalent to getInstance(). The getInstance()
method doesn't need to be public at all.
So the usage to get the default static registry is:
$r = Zend_Registry::get();
These three are equivalent:
Zend_Registry::get('foo')
$r-offsetGet('foo');
$r['foo'];
These three are equivalent:
Zend_Registry::set('foo', 'bar')
$r-offsetSet('foo', 'bar)
$r['foo'] = 'bar';
The old Zend::initRegistry('classname') method is a bit more clearly
named:
Zend_Registry::setClassName('classname')
This is needed only by people who want to use a subclass as the static
registry instance.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
I don't mind it being Zend_Debug::dump(), but I don't want people to believe that the Debug class will contain methods to set breakpoints, monitor variables, perform traces, generate code profiling reports, or No, I in no way want this stuff. It doesn't belong to framework realm. I just want to have the ad-hoc methods intact :) Like dump, maybe some better backtrace later, but nothing more. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Request for feedback: moving Zend.php to Zend/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, couse it is same package] Zend/Filter/Zend_Filter_Digits.php [no change, couse it is same package] why we need to repeat Zend_Filter twice? What good would it make? And how we know Zend and Filter get its own directory but Alpha does not? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
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 up in Zend directory. And this solution is time tested in Java, where each I don't really udnerstand what do you mean by mixed up. They reside in Zend directory, because that's where framework is. It's intended to be so, what's the problem in it? 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? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
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/
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 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 except for doubling up some of the top level class names has no impact on the current design. I'm afraid Zend_Filter_Filter doesn't make any sense to me. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
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 use - these functions are too small for a class, they are utilities - so nothing wrong with having utility class. Actually, a lot of OO libraries have a number of utility classes where they aggregate small functions. If Zend_Debug is going to have one dump function or even two - there's no much use of having such a class at all, Zend::dump is not worse and we already have it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
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/
Re: [fw-general] Using Zend_DB to connect to MSSQL Server using ODBC
For example, should this be based on PDO_ODBC? Or the native ODBC extension in PHP? Well, if we could have both it'd be nice ;) I'm not sure actually which one is more important - that depends on what is more widely used and what different features each of them has, etc. But I'm convinced we should have at least one of them for 1.0. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] PHP5 Security
First of all, I think it is important to note that this has nothing to do with security. Anyone who relies on OOP visibility features for any security is making a serious mistake, these are not security features and should not be used as such. From my understanding of OOP and class handling a private property must not be changed or visible from outside the class. And protected properties should only be visible and changeable from the own or an extended class. Yes, and it is - unless you employ some trickery outside of the context of OO. You shouldn't do that unless you know what you are doing. Changing and accessing private properties from everywhere outside the class object ?? Is this normal behaviour ?? No, it's not normal - this is why you have to employ non-normal code to achieve it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] PHP5 Security
You are right but the content of a private property will be manipulated and I think it is the same if you change a private property directly or the content of it. You are changing its state. It's definitely not like you change the property directly. It's more like you would store value in the database and then came with database editing tool and changed it, and then when loading it back you would be surprised that it had changed. If you break the abstraction, the assumptions coming with it won't work - so one more reason not to break it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] require_once include_once ?
Andrey Korolyov wrote: Why inf ZF you are using *_once in Zend::LoadClass and in ZF class files ? What about this link http://raa.livejournal.com/99409.html#cutid1 [sorry it written on russian with english quotes]. The difference between include and include_once is in only one point - that once should determine the full filename in order to check against the included files (to do the once part in case it was previously included :). Prior to the existence of the realpath cache, that cost system calls on each invocation - to find out the file real path, regardless of file being previously included and cached, but with realpath cache the picture should change - basically, after the file is cached and is in realpath cache, no extra system calls should be produced. The blog author (sorry, I didn't understand if it's your blog or not :) checked PHP 4.4.5 - you are welcome to check 5.2.0 or even better 5.2.1 RCs and see what happens. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
In my opinion, discussing adding autoloading at this stage rates as
premature optimisation. As someone else noted, we're making educated
autoloading is not an optimization. It's not a performance feature (it
can be more or less performing depending on how many classes you have,
how they are used and what do you compare to) but it is great
convenience feature that allows you to get rid of the ugly code like
if(!class_exists('Foo')) { require 'Foo.php'} once and for good.
The way I see it, autoloading is an optimisation. I know it can make
requiring/including easier, but how much easier? The ZF has most things
A lot easier. :) In any case, you don't pay for it if you don't use it.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
Unless the opcache is smart enough to optimize the if block you are never going to get the full benefit of the opcode cache as you are conditionally including files. Actually I don't see any reason why conditional include would hurt performance in any way - it shouldn't hurt compile-time binding and it shouldn't hurt any opcode cache that does per-file caching (and all those I know do that). -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
Because the require_once() is conditional, it's not actually seen as a straight forward include (you can't predict whether to require the file until that code block is executed). As a result, although the file is cached, the class/etc. in it are done so separate to the main code. Net result is that the cache is not as effective. In essence, autoloading Can you explain on that - do you mean that the cache you are talking about caches the whole sequence of the included files as a single block and needs to predict which files are included and which are not? Could you point to the opcode caches that act this way? IMO it's very wrong way for the opcode cache to act, but I'd like to know which ones do that. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
Is compile-time binding for class B done in script:
require('a.php');// defines class A
class B extends A { /*code*/ }
No, won't bind (unless some tool loads a.php in compile-time once it
parses 'require' - I don't know about any tools that do that, it's very
hard to do it IMHO) since require is run-time directive, so when parser
is considering class B extends A it doesn't yet know what A is.
require_once('a.php');// defines class A
class B extends A { /*code*/ }
Same as above. once here doesn't change anything.
Or only in:
class A { /*code*/ }
class B extends A { /*code*/ }
Here it would bind in compile-time, since A is known.
Also, this code would bind in compile-time in plain PHP:
require('a.php'); /* has class A {} */
require('b.php'); /* has class B extends A {} */
since the B require executes after the A require so that class A is
already known. However, with opcode cache it's more complicated since it
depends on how the particular cache works - with opcode cache there's
actually two compile times - one when script is compiled before caching
and one when engine wants to compile file but it's taken from the cache
- and when exactly B is bound is that case can depend on the particular
cache. I don't know what APC does in this case (probably Rasmus does ;)
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
Using __autoload and require_once basically destroys any advantage apc is likely to bring you. Mainly because you move the compilation sequence into mid-runtime land, where the engine stops execution and proceeds to compile stuff. I can't make any sense out of it, frankly. Unless APC is totally broken (which I believe it's not, otherwise we would know it before) it doesn't make any difference how you call require_once - from autoload or otherwise. Also, the phrase you move the compilation sequence into mid-runtime land doesn't make absolutely any sense, since any compilation in PHP is in mid-runtime land - all compilations besides top script are done by runtime engine executing include or require opcode, and the top script does virtually the same only without the actual opcode. I think what Rasmus is talking about is compile-time binding versus runtime binding, but it's not that big a difference (definitely not even close to destroying any advantage, since the advantage is because of the absence of the disk operations and not because of compile-time binding) and anyway it only comes into play if you, for example, inherit from autoloaded class (then compiler can't runtime-bind the inherited class) but if you use autoloading on new(), etc. it doesn't matter at all. Also, that has nothing to do with require_once - basically, for require_once the slowdown comes from having to resolve the full path of the file (since we should actually know the full true path to know to load it only opce) - realpath cache present in 5.2 should make it much cheaper. Anyway, even with require_once the benefits far outweigh the small speedup you are getting by using require and potentially saving realpath() call - unless you are running super-performance-critical site that you should positively squeeze out each and every single function call and system call even if it may make your code less stable and more ugly. Even then with realpath() cache you probably don't have any more to squeeze... -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
from autoloaded class (then compiler can't runtime-bind the inherited Read: can't compile-time bind the inherited class class) but if you use autoloading on new(), etc. it doesn't matter at all. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
binding) and anyway it only comes into play if you, for example, inherit
from autoloaded class (then compiler can't runtime-bind the inherited
class) but if you use autoloading on new(), etc. it doesn't matter at all.
Additionally, the non-autoloading example works better only in case like:
main.php:
include('a.php');
include('b.php');
a.php:
class Foo {}
b.php:
class Bar extends Foo{}
since by the time we get to b.php the engine already knows class Foo so
it can immediately derive class Bar. However, if you have this code:
main.php:
include('a.php');
class Bar extends Foo {}
then it doesn't make any difference since class Bar can not be bould
statically, autoload or not, since it needs include to run before it can
do the binding.
Summing up, unless you are *very* careful with *all* parts of your
application (and it is not simple to do it) and always keep track in
your mind of what engine knows in each and every include scenario, you
would have very hard time optimizing for always binding statically. I'd
propose to forget about it and just use the interfaces PHP provides
without trying to outsmart the engine.
I would propose to still explicitly include the classes we know we would
need (e.g. if you inherit from class or always use it, then do include
it) using require_once in system components, and provide strong autoload
mechanism so that the user could not bother with figuring out component
dependencies and could use things like new $class() without worrying too
much if that class is loaded.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
Arnaud Limbourg wrote: You can also have a build mechanism that removes all the require statement and move them to one file. That way you can load all the files you need up front, at least those you use the most. That definitely can be done, and for some sites it might be a good solution. Though it assumes you site requirements actually warrant the trouble and that most of applications on your site share the same set of used files. And of course you would have to rebuild the main file if you change some names or requirements or refactor, etc. - which is too easy to forget :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] ZF and Autoloading
I've seen lots of statements about using an autoloader interfering with byte code caches. Unfortunately, my understanding of byte code caching is limited. It would seem to me that it would cache the byte code from each file as a separate cache entry and the world would be right. But that's me with my rose colored glasses i suppose. As far as I know, autoloading works OK with bytecode caching. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Build Zend Framework, parse errors.
Based on these, in each case, the issue is with perfectly valid PHP using the 'array' type hint. As an example: protected function _setInvokeArgs(array $args = array()) It looks like Zend Guard is not currently compatible with valid PHP 5.1 syntax, or you're not using PHP = 5.1.0. If you *are*, please file a support ticket against Zend Guard so it can be corrected. Unfortunately, this is true - support for 5.1 features is lagging in Zend Guard. If you submit support request with the code sample it would help ensure that once 5.1 support is there, the code will be working. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Opcode cache [was: Shared server load times]
Arnaud Limbourg wrote: You might want to read this, that shoould give enough info :) http://pooteeweet.org/blog/538/ Frankly, I don't understand from this message what is the problem. I understand APC has some problem caching something (what?) and for some (not explained) reason it's slow but I couldn't understand why. So far it looks like some internal APC issue, unless I am missing something. Does anybody have more detailed explanation of why autoload would be bad? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Note: problem with fw-general list
Abu Hurayrah wrote: Thanks Bill. Did the entropy issue also affect new user registrations? See my message sent just a few minutes ago. Someone else mentioned their registration was delayed as well. All messages to the list - including new subscriptions - should be OK now. The server is a bit loaded now due to the backlog of the messages that weren't delivered, but once these are processed it should be fast again. If you didn't receive reply to the subscription message in a couple of hours, try subscribing again, if it still didn't work - then probably something else is wrong, drop me a note then with the email you tried to subscribe, I will check what's up. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Configuring Zend Framework with IIS
I was recently facing an issue while configuring Zend Framework with IIS. I was searching for an apache style mod-rewrite property in IIS but was unable to find any such thing. So, my question is, how can we There's no standard rewrite engine for IIS but there are third-party modules, e.g. ISAPI_Rewrite which IIRC also has free version. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
[fw-general] new backend for Zend_Cache
I've added a backend for Zend_Cache into Laboratory SVN under Zend/Cache/Backend and the proposal is here: http://framework.zend.com/wiki/x/TR If you have any comments or suggestions please tell.
Re: [fw-general] Please Welcome Bill Karwin to our team
Personally, I think the wiki is already better than http://framework.zend.com/manual I also think we can do a wiki to HTML that will look better than the existing pages. However, not everyone agrees with me, so we need to keep the wiki-to-docbook conversion working. I think wiki format has one serious downside - it's not meant for distribution. Also, I am not sure how easy it would be to automatically process it - e.g., taking PHP manual as example, there are tools that use PHP manual to automatically extract functions, classes, descriptions, etc. for various purposes. Docbook XML structure allows for that. Wiki most probably won't. So unless there are solutions for these two problems - distirubution and automatic processing - for wiki format, I would say it is worse than docbook format.
Re: [fw-general] Decision: loadData('xml:/something/bar.xml'); vs. new Foo('/something/bar.xml');
Personally, I completely agree with you Chris, and even suggested removing Zend_Db. For me, whatever effort is required to map input choice selections onto selected plugin strings (first parameter of the factory method) is not better than the effort to require_once the adapter and then instantiate it. I'm not sure I completely understand the problem and proposed solutions, but isn't it an option to support as much of the ways to instantiate it as possible (within the borders of sanity, of course)? E.g. do it both with factory and with direct instantiation (and with forks and hope ;) - and let the people use the method which they like better?
