Matthew Weier O'Phinney wrote:
-- Christopher Thompson <[EMAIL PROTECTED]> wrote
The issue is that there are currently two distinct approaches to the
issue of how to include layout support, both of which are valid. The
question, to me, is which makes more sense in the context of t
I agree with Matthew that identifying the actual use cases that people
are requesting and then showing the code that solves those use cases in
the proposed systems is necessary.
I have had discussions with Pádraic on this subject and looked at his
and Ralph's code. While I think we agree on th
It's basically a matter of preference.
It is really a matter of practice. Experts will obviously know the
trade-offs of the options, but the point of focusing on a Best Practice
is to generally reduce problems. I would agree with Rob that other than
communicating with the other controller class
Bill Karwin wrote:
However, in general you wouldn't use the error messages of Zend_Validate
classes literally in output to the user. You should probably use the
boolean return values and from these, output your own error messages.
That way you can specify the wording to be more appropriate to yo
I think that looks good as a compromise for the two or three use cases.
I do wonder whether there is starting to be too much code supporting
multiple use cases all in one class. Perhaps there should be a separate
base class for those who only want an instance. I assume that those who
want stat
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
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
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
The only real reason given for Zend/Core.php containing four classes is
for performance, but I think it will actually have the opposite effect.
The only class really used in the framework is Zend_Loader. Exceptions
are lazy loaded, the Registry is a userland thing, and the
Zend_Framework class
+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
Rob Allen wrote:
Matthew Weier O'Phinney wrote:
-- Rob Allen <[EMAIL PROTECTED]> wrote
The main intention of the request object, from my perspective, was to
allow determination of the controller and action values. Any class
extending the basic request abstract is simply adding more places
fro
+Zend_Validator+-+Christopher+Thompson?focusedCommentId=7541#comment-7541
Short url (scroll down to last comment):
http://framework.zend.com/wiki/x/cwM
Just a further question: Which project team is on control of
Zend_Filter(Chain) and Zend_Validator? Maybe it makes more sense to
discuss the issues
Simon Mundy wrote:
This is where it gets totally subjective :)
Despite identical functionality, to me the name Zend_Loader seems a
bit awkward and implies less of a 'core' component, whereas simply
'Zend' does seem to be core and more naturally related to all
components within the framework.
Simon Mundy wrote:
Except that it is not for the framework to use -- it is for userland
and separate specific classes would be better to use for that.
I disagree - Zend.php should be used as part of the coding standards
for the sake of consistency and reusability.
A lot of the components use
Simon Mundy wrote:
I'm less inclined to be rid of it - it seems perfectly logical that
Zend.php is the 'glue' for all other components within the framework,
so why not have it perform bootstrap-specific functionality:-
Except that it is not for the framework to use -- it is for userland and
sep
André Hoffmann wrote:
Correct me if I'm wrong but as I understood it, Zend::registry is not
going to be superseded by Zend_Registry.
And I really don't think that having problems copying Zend.php is a
reason to remove it.
The real reason to remove is is that it does not belong. It is a
mishm
Ralph,
Some immediate things that jump out:
- The files use short tags rather than - I am wondering what Message.php, Session/Debug.php and the
Session/Validation files are for?
- From a quick look at setFeature() I think maybe some sort of plugin or
decoration might be better than a hard co
Zend_Session is currently a proposal. Check the developer wiki.
Pierre Kircher wrote:
Hi
is there a Class for Sessions in the current Framework ?
Regards Pierre
I have proposed having a Credential class that you could wrapper the
factors for any kind of scheme. Then an Authenticator class would be
extended for each scheme to provide the second half of a
Credential/Authenticator pair for an Authentication Manager to run.
These would really just be adapt
I believe that was a necessary PHP4 evil, but Reflection can now be used
and it is much cleaner.
Paul M Jones wrote:
Whoever suggested this particular tidbit ...
for ($i = 0; $i < $argsCount; $i++) {
$argsString .= ($comma ? ', ' : '') . "\$args[$i]";
$comma =
I suggested something like this earlier, but for Zend_Registry not Zend.
I think enhance Zend_Registry but not the Zend class. The enhancements I
proposed allowed you to load and instantiate an object with a single
call and also allowed registering a class name and instantiation
parameters so t
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.
Cheers,
Gavin
Christopher Thompson wrote:
I continue to wonder at the usage of statics. The use case where a
Michael Sheakoski wrote:
When you say "inverting it" are you saying to have an Intercepting
Filter outside of the FrontController? Such as in index.php? If it
is outside of the FrontController then you would not be able to do
things like check permissions in a central place because they would
And for the record. I format my own code in the same way that Paul and
Jeff format theirs. So I am advocating tolerance of those who prefer BSD
style. I have worked to "free my mind" from being bothered by trivia
like spacing and they no longer hinder my considering other aspects of
the code
Paul M Jones wrote:
Jeff Moore wrote:
Having your code in a "normalized" form frees the mind to consider
other aspects of the code. Poorly or inconsistently styled code can
obscure refactorings. With a good coding standard, the benefits
outweigh having to re-train yourself out of a few habits.
I think the practice in ZF is going to be:
- do Access Control that uses centralized data with preDispatch()
- do Access Control that uses data distributed in the Actions with preRun()
The Front Controller does everything internally, including these
Filters. I would still prefer to remove as m
Ifs with no braces ... Booo
Gavin Vess wrote:
.. although the Linux Kernel team does not use braces when there is
only one statement after the conditional. I would prefer we follow
this standard more closely, and eliminate braces around a single
statement. Anyone else have this p
End separation now! Support vertical equality!
:)
Ralph Schindler wrote:
Thomas Weidner wrote:
And I feel a missunderstanding between "White space" and "White face"
;-)
I think you accidentally misused "Separate but equal" Mr.
Give-me-vertical-whitespace-or-give-me-death. ;) :)
Braces:
I think you accidentally misused "Separate but equal" Mr.
Give-me-vertical-whitespace-or-give-me-death. ;) :)
Ralph Schindler wrote:
And those are conventions I would expect from those projects... they are
stuck in an age where blacks drank from one water fountain, whites from
another, and dev
wrote:
On 28/09/2006, at 11:52 AM, Christopher Thompson wrote:
I agree that the ZF would benefit by having the container type
objects share a common interface. Whether any of these classes
inherit a basic array/property class is a separate question that
should be made on a case by case basis
I agree that the ZF would benefit by having the container type objects
share a common interface. Whether any of these classes inherit a basic
array/property class is a separate question that should be made on a
case by case basis. But having a common interface standard would easy
learning the Z
It seems like specialized ViewHelpers would be the way to encapsulate
the kind of View specific data you mention.
Terry Cullen wrote:
And how are you guys getting failure messages back to the view? Do you
pass error codes or something like that? Or does your model have to
become aware of lan
The problem with saying that all validation needs to happen in the Model
is that for practical reasons it does not work very well. The most
common reason is that the Model usually does not deal with all the input
from the request. Some input is intended for the Controller or the View
logic spec
33 matches
Mail list logo
