[fw-general] Using context switcher to default to xml context
I'm having some problems using the context switcher when I try to default
the context to 'xml'. It tells me that the default context is xml but it
doesn't load the xml.phtml files. Here is my code per the manual:
public function init()
{
//set all context to xml
$this->_helper->contextSwitch()->initContext('xml');
}
It simply does not load my xml.phtml files. What am I doing wrong?
Thanks,
-Joshua-
Re: [fw-general] Zend_Session_SaveHandler_DbTable
Hey I hope it's not too late - I use this in a production site and it's working an absolute treat! Thanks Jordan! http://framework.zend.com/issues/browse/ZF-2335 Finally got around to finishing the unit tests and writing some documentation.. I'm not done with the docs but its a decent start. The unit tests have 94% code coverage by line count and 100% of methods. Might be too late for 1.5.0 (maybe not?) Thanks, Jordan He that teaches himself hath a fool for his master. -- Benjamin Franklin Poor is the pupil who does not surpass his master. -- Leonardo da Vinci. -- 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] Zend_Session_SaveHandler_DbTable
http://framework.zend.com/issues/browse/ZF-2335 Finally got around to finishing the unit tests and writing some documentation.. I'm not done with the docs but its a decent start. The unit tests have 94% code coverage by line count and 100% of methods. Might be too late for 1.5.0 (maybe not?) Thanks, Jordan He that teaches himself hath a fool for his master. -- Benjamin Franklin Poor is the pupil who does not surpass his master. -- Leonardo da Vinci.
[fw-general] Zend Framework 1.5 Release Candidate 3 is now available!
We couldn't be happier to announce that Zend Framework 1.5 Release Candidate 3 is now available from the Zend Framework download site! http://framework.zend.com/download An overview of new features (also included in previous 1.5 Release Candidates): * New Zend_Form component with support for AJAX-enabled form elements * New action and view helpers for automating and facilitating AJAX requests and alternate response formats * Infocard, OpenID, and LDAP authentication adapters * Support for complex Lucene searches, including fuzzy, date-range, and wildcard queries * Support for Lucene 2.1 index file format * Partial, Placeholder, Action, and Header view helpers for advanced view composition and rendering * New Zend_Layout component for automating and facilitating site layouts * UTF-8 support for PDF documents * New Nirvanix, Technorati, and SlideShare web services RC3 already? How time- and Release Candidates- fly! Thanks again to everyone who has contributed to this release with code, documentation, and feedback. It seems that we are quickly approaching- or have already arrived at- a GA-quality release. As we continue to break new ground in the community (how about the shortest lived RC yet with RC2? ;), we should keep in mind that many new and casual users will be checking out 1.5 once it is released for general availability, and we should be looking our best with both new initiatives and existing infrastructure/community sites. We're calling on all community members to update their own ZF sites and the ZF wiki pages, throw some blogging love in ZF's direction, and provide feedback on our excellent QuickStart Contest entries: http://framework.zend.com/wiki/display/ZFDEV/Completed+Entries. Stay tuned for all kinds of announcements in the next few weeks, including the QuickStart contest winner, an updated proposal process, new Zend-lead initiatives, and (with some luck and hard work) the 1.5 release itself! Again, the Zend Framework community does NOT recommend this release for production use. We do, however, recommend evaluating new features in this release with existing and new applications. Enjoy 1.5RC3 and see you on the issue tracker, wiki, and mailing lists! ,Wil
Re: [fw-general] Zend_Form bug or am I stupid?
Matthew Weier O'Phinney-3 wrote:
>
> -- fab2008 <[EMAIL PROTECTED]> wrote
> (on Wednesday, 12 March 2008, 06:22 PM -0700):
>> Now the problems:
>>
>> 1) Why StringTrim filter is not applied to submitted value? I expect as
>> output the value 'qwerty', but blanks remains in the result...
>
> This is because setElementFilters() applies the filter to all
> *currently* registered elements -- it does not apply to elements
> registered after the fact.
>
> I'd suggest in your original subclass, you do the following:
>
> [...]
>
> Then, in the classes subclassing the above, you would *not* override the
> constructor, but instead implement the init() method for your
> initialization tasks. This would ensure that your StringTrim gets added
> to all elements.
>
>
Ok, understood. Good explanation and good solution.
Matthew Weier O'Phinney-3 wrote:
>
> There was a bug in RC1 with how required elements created the NotEmpty
> validator that is prepended to the validation chain -- the
> 'breakChainOnFailure' flag was getting reset on already instantiated
> validators. I fixed this in svn yesterday, and it's available in both
> the trunk and the 1.5 release branch.
>
Perfect, thank you. It's all the evening that I search for a solution ;-)
Another thing, is there any way to add custom error message to a field or to
the form, without using a validator? I explain better suppose i have a login
form (with username and password fields) and the submitted data is
sintattically valid, but when I use Zend_Auth i have a INVALID_CREDENTIAL
result, i want to insert a "Wrong password" error for the password field,
for the moment i did this adding a custom LoginCheck validator for login
field by using the context parameter for checking password and trigger a
wrong password error, but i'd like to do something like this in my
controllers:
if ($form->isValid($data)) {
// check user and pass with zend auth
$ok = $this->check($form->getValues());
if (!$ok) {
$form->addError('password', 'wrong password for user ' .
$data['login']);
return;
} else {
// forward to account page
$this->_forward('userinfo');
return;
}
}
--
View this message in context:
http://www.nabble.com/Zend_Form-bug-or-am-I-stupid--tp16019346s16154p16019851.html
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Broken after upgrade to Apache 2.2
Hi, I have a App working fine with Apache 2.0/PHP 5.2.4/ZF 1.0.2. Now, I upgrade to Apache 2.2 with others remain the same (I changed PHP config to run with Apache 2.2). The app broke: the home page (http://localhost/my-app)showing up correctly but all other pages getting 404 file not found error. Interestingly, http://localhost/my-app/index/index got the same error: HTTP 404 Not Found. I checked httpd.conf settings, I have mod_rewrite module loaded. My .htaccess remain the same. Any idea where should I check next? Is ZF working with Apache 2.2?
Re: [fw-general] Zend_Form bug or am I stupid?
-- fab2008 <[EMAIL PROTECTED]> wrote
(on Wednesday, 12 March 2008, 06:22 PM -0700):
> Hi to everyone, i've just started a new project with Zend Framework (very
> cool), i want to submit a question about Zend_Form usage.
>
> I created a custom subclass of Zend_Form to enclose all common code shared
> by different forms and then for every form I need, I subclass this custom
> class adding elements and validators. Now I have two problems, one with
> filters and one very frustrating with validators. This is the constructor of
> first form (the parent form of every other):
>
> public function __construct($options = null) {
> parent::__construct($options);
> // set class for this form
> $this->setAttrib('class', 'zenitspotform');
> // set the form to be post
> $this->setMethod('post');
> // trim all values provided in form
> $this->setElementFilters(array ('StringTrim'));
The above is going to likely cause issues, but it appears you found that
out... I'll explain more below...
> // set translator
> $this->setTranslator(
> Zend_Registry::get('translator')->getAdapter());
> }
>
> and this is an example form constructor (with only one field but in the
> others, with more fields, the behaviour is the same)
>
> public function __construct($options = null) {
> parent::__construct($options);
>
> $this->addElement('text', 'login',
> array ('label' => 'Username (e-mail)'));
> $this->login->setRequired(true);
> $this->login->addValidator('Date', true);
> $this->login->addValidator('Digits', true);
> $this->login->addValidator('Alpha', true);
> /* this method add a submit button */
> $this->addSubmitButton('Send >>');
> }
>
> If I insert the value ' qwerty ' (without quotes, please note the blanks at
> the begin and at the end of the string) I obtain these errors:
>
> * ' qwerty ' is not of the format -MM-DD
> * ' qwerty ' contains not only digit characters
> * ' qwerty ' has not only alphabetic characters
>
> Now the problems:
>
> 1) Why StringTrim filter is not applied to submitted value? I expect as
> output the value 'qwerty', but blanks remains in the result...
This is because setElementFilters() applies the filter to all
*currently* registered elements -- it does not apply to elements
registered after the fact.
I'd suggest in your original subclass, you do the following:
abstract class My_Form extends Zend_Form
{
public function __construct($options = null)
{
parent::__construct($options);
// set class for this form
$this->setAttrib('class', 'zenitspotform');
// set the form to be post
$this->setMethod('post');
// set translator
$this->setTranslator(
Zend_Registry::get('translator')->getAdapter());
// custom initializations...
$this->init();
// trim all values provided in form
$this->setElementFilters(array ('StringTrim'));
}
abstract public function init();
}
Then, in the classes subclassing the above, you would *not* override the
constructor, but instead implement the init() method for your
initialization tasks. This would ensure that your StringTrim gets added
to all elements.
> 2) Why all validators are executed I passed true as second parameter of
> every addValidator call, so I expect only the date validator should be
> processed.
>
> Two other strange thing, if I remove the setRequired line, only the first
> validator is being executed and the other two don't show their error
> message. As a other solution If I add a NotEmpty validator, I obtain the
> same result...
There was a bug in RC1 with how required elements created the NotEmpty
validator that is prepended to the validation chain -- the
'breakChainOnFailure' flag was getting reset on already instantiated
validators. I fixed this in svn yesterday, and it's available in both
the trunk and the 1.5 release branch.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Hardcoded form decorators and the FormLabel helper
-- Nathan <[EMAIL PROTECTED]> wrote
(on Wednesday, 12 March 2008, 03:24 PM -0700):
> Sorry if I what I said came across as being hostile or presumptuous, I
> didn't mean to slight the hard work you've put into Zend_Form.
And apologies on this end if I came across... cross. I'd just discovered
the ViewRenderer bug in the RC2 release, which had me pretty grumpy.
> Your arguments are certainly convincing, I'd just like to mention that this
> was the simple use case that my idea for static defaults came from:
>
> Zend_Form_Element::setDefaultDecorators(array(new
> Zend_Form_Decorator_ViewHelper));
>
> However, I can certainly see how it might be unnecessarily complex and
> confusing to have certain elements override that. I was stuck on
> Zend_Form_Element instead of overloading the defaults from within Zend_Form
> subclasses. Good call.
There's actually another issue I didn't mention: there are also good
reasons for each element having its own decorator instances. Most
decorators can receive options that allow you to customize the
decorator for that particular element -- for instance, you may wish for
the Label decorator on one element to prepend, but append on another, or
add a specific id to a particular HtmlTag decorator. In your example
above, if you decided you wanted to customize the HtmlTag of one
element, you'd end up customizing it for all of them, as it would be the
same decorator instance across all elements.
So, in the end, while statics seem like they'd be a quick and easy
solution, they also end up making for less flexibility.
> I'll submit a unit test and a use case for the FormLabel improvement
> shortly.
I saw the comment come through in my inbox earlier; I'll look at it
after we do the final 1.5.0 release. Thanks for the contribution!
> On 03 Mar 2008, at 5:44 AM, Matthew Weier O'Phinney wrote:
>
>> -- Nathan <[EMAIL PROTECTED]> wrote
>> (on Tuesday, 11 March 2008, 04:00 PM -0700):
>>> First and foremost, hard coded default decorators seems suboptimal.
>>> Extending all the elements to define your own defaults isn't much of an
>>> option, since you'd have to subclass all the element classes. I realize
>>> the
>>> defaults can be bypassed by passing your own decorators to the element's
>>> constructor, but this isn't always ideal either.
>>
>> I want to point out a few things here. First, it's hardly "hard coding"
>> -- it's providing sane defaults. There *is* a difference -- hard coding
>> means you wouldn't be able to change them, and, quite clearly from your
>> own explanation, you can.
>>
>> Let's look at the flexibility availalble here (forgive me if I'm
>> repeating you a little...):
>>
>> * You can subclass and override the loadDefaultDecorators() method
>>
>> * You can pass in decorators when creating elements/forms/etc, which
>>will prevent the default decorators from loading
>>
>> * You can even prevent the default decorators from loading at all (by
>>passing a 'disableLoadDefaultDecorators' option at instantiation)
>>
>> * You can set all element or display group decorators at once
>>(setElementDecororators(), setDisplayGroupDecorators())
>>
>> I'm failing to see how this is not enough flexibility, but, whatever.
>>
>>> I propose that default decorators be loaded from a static array via
>>> addDecorators(). Then the static array could be overridden by calling
>>> Zend_Form_Element::setDefaultDecorators($array). Besides being more
>>> flexible, this also has the potential to improve performance, since it
>>> would allow you to set your own decorator *instances* and save a ton of
>>> redundant pluginloader calls. Would this work or am I missing something?
>>
>> You're missing a couple fundamental things, actually. First off, not all
>> elements use the same set of decorators. The Button, Submit, Reset, and
>> Image elements each have a different set of decorators than the other
>> elements -- and users can define their own elements with their own
>> defaults. If we use a static member for defining this array, then we
>> actually *lose* flexibility, as all elements would, out of necessity,
>> have to use the same set (either that, or we then end up potentially
>> having more logic and duplicate entries in classes that don't use the
>> same defaults).
>>
>> Additionally, your argument of using decorator instances will not work:
>>
>>class Foo
>>{
>>public static $decorators = array(
>>new Zend_Form_Decorator_ViewScript()
>>);
>>
>>public function getDecorators()
>>{
>>return self::$decorators;
>>}
>>}
>>
>>$foo = new Foo;
>>var_export($foo->getDecorators());
>>
>> Try the above -- you'll get a parse error. It's not valid PHP. That
>> means that the only way that using decorator instances would work with a
>> static member is if you add them in *MANUALLY* prior to
>> instantiating your objects. This sounds to me like about the same amount
>> of work as doing this:
[fw-general] Zend_Form bug or am I stupid?
Hi to everyone, i've just started a new project with Zend Framework (very
cool), i want to submit a question about Zend_Form usage.
I created a custom subclass of Zend_Form to enclose all common code shared
by different forms and then for every form I need, I subclass this custom
class adding elements and validators. Now I have two problems, one with
filters and one very frustrating with validators. This is the constructor of
first form (the parent form of every other):
public function __construct($options = null) {
parent::__construct($options);
// set class for this form
$this->setAttrib('class', 'zenitspotform');
// set the form to be post
$this->setMethod('post');
// trim all values provided in form
$this->setElementFilters(array ('StringTrim'));
// set translator
$this->setTranslator(
Zend_Registry::get('translator')->getAdapter());
}
and this is an example form constructor (with only one field but in the
others, with more fields, the behaviour is the same)
public function __construct($options = null) {
parent::__construct($options);
$this->addElement('text', 'login',
array ('label' => 'Username (e-mail)'));
$this->login->setRequired(true);
$this->login->addValidator('Date', true);
$this->login->addValidator('Digits', true);
$this->login->addValidator('Alpha', true);
/* this method add a submit button */
$this->addSubmitButton('Send >>');
}
If I insert the value ' qwerty ' (without quotes, please note the blanks at
the begin and at the end of the string) I obtain these errors:
* ' qwerty ' is not of the format -MM-DD
* ' qwerty ' contains not only digit characters
* ' qwerty ' has not only alphabetic characters
Now the problems:
1) Why StringTrim filter is not applied to submitted value? I expect as
output the value 'qwerty', but blanks remains in the result...
2) Why all validators are executed I passed true as second parameter of
every addValidator call, so I expect only the date validator should be
processed.
Two other strange thing, if I remove the setRequired line, only the first
validator is being executed and the other two don't show their error
message. As a other solution If I add a NotEmpty validator, I obtain the
same result...
Can anyone explain me this behaviour, i'm going crazy!!!
Thanks.
--
View this message in context:
http://www.nabble.com/Zend_Form-bug-or-am-I-stupid--tp16019346s16154p16019346.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] ACL actual use
hi Alexander,
my ACL solution is based on ini files and my AclModel class reads those
files and creates the ACL object, which should be cached by a cache
mechanism, because a file solution is a little bit slower than a db
solution. But it's much simpler to handle, for me.
http://sources.online-skripte.de/Mtwd_Zend_AclModel.phps Source
http://php.online-skripte.de/Mtwd_Zend_AclModel/api/ API
usage in bootstrap:
// STANDARD ACL
$acl = new Mtwd_Zend_AclModel(new
Zend_Config_Ini('../application/configs/accesslist.ini'));
// MODULE ACLs
$acl->addModule(new
Zend_Config_Ini('../application/configs/modules/gallery.ini'));
// USER ACL
$acl->addUser(new
Zend_Config_Ini('../application/configs/user_acl/user_x.ini'));
accesslist.ini
[guest]
main.parents =
main.allow = home news
main.privilegesAllow = "(show)"
main.privilegesDeny =
[member]
main.parents = guest
main.allow = profiles tutorials shoutbox
main.privilegesAllow = "(insert,shoutbox)"
main.privilegesDeny =
[admin]
main.parents = member
main.allow =
main.privilegesAllow = "(delete)"
main.privilegesDeny = "(delete,shoutbox) (delete,news)"
gallery.ini
[memberGallery]
main.parents =
main.allow = gallery
main.privilegesAllow = "(show)"
main.privilegesDeny =
[moderatorGallery]
main.parents = memberGallery
main.allow =
main.privilegesAllow = "(edit) (hide)"
main.privilegesDeny =
[adminGallery]
main.parents = moderatorGallery
main.allow =
main.privilegesAllow = "(delete)"
main.privilegesDeny =
user_x.ini
[user_x]
main.parents = member moderatorGallery
I know it seems to be difficult but for me it is a intuitive way. Maybe
there are some bugs but i will keep on working on it.
Bye,
David
Alexander Johannesen wrote:
>
> Hi,
>
> Has anyone used Zend ACL in an active project, and would like to share
> some thoughts on it? (Pro/con/gotcha's) I'm about to implement it into
> a larger framework (an extension of ZF, really) and would like to hear
> people's opinions before I get my surgeons knife out...
>
> Also, has anyone defined an ACL definition / ini files? Much of the
> API can be replicated through much simpler ini files, so if anyone has
> done this I could save some time.
>
>
> Alex
> --
> ---
> Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
> -- http://shelter.nu/blog/
>
>
>
--
View this message in context:
http://www.nabble.com/ACL-actual-use-tp15986088s16154p16016536.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Hardcoded form decorators and the FormLabel helper
Sorry if I what I said came across as being hostile or presumptuous, I
didn't mean to slight the hard work you've put into Zend_Form.
Your arguments are certainly convincing, I'd just like to mention that
this was the simple use case that my idea for static defaults came from:
Zend_Form_Element::setDefaultDecorators(array(new
Zend_Form_Decorator_ViewHelper));
However, I can certainly see how it might be unnecessarily complex and
confusing to have certain elements override that. I was stuck on
Zend_Form_Element instead of overloading the defaults from within
Zend_Form subclasses. Good call.
I'll submit a unit test and a use case for the FormLabel improvement
shortly.
Thanks for your time,
Nathan
On 03 Mar 2008, at 5:44 AM, Matthew Weier O'Phinney wrote:
-- Nathan <[EMAIL PROTECTED]> wrote
(on Tuesday, 11 March 2008, 04:00 PM -0700):
First and foremost, hard coded default decorators seems suboptimal.
Extending all the elements to define your own defaults isn't much
of an
option, since you'd have to subclass all the element classes. I
realize the
defaults can be bypassed by passing your own decorators to the
element's
constructor, but this isn't always ideal either.
I want to point out a few things here. First, it's hardly "hard
coding"
-- it's providing sane defaults. There *is* a difference -- hard
coding
means you wouldn't be able to change them, and, quite clearly from
your
own explanation, you can.
Let's look at the flexibility availalble here (forgive me if I'm
repeating you a little...):
* You can subclass and override the loadDefaultDecorators() method
* You can pass in decorators when creating elements/forms/etc, which
will prevent the default decorators from loading
* You can even prevent the default decorators from loading at all (by
passing a 'disableLoadDefaultDecorators' option at instantiation)
* You can set all element or display group decorators at once
(setElementDecororators(), setDisplayGroupDecorators())
I'm failing to see how this is not enough flexibility, but, whatever.
I propose that default decorators be loaded from a static array via
addDecorators(). Then the static array could be overridden by calling
Zend_Form_Element::setDefaultDecorators($array). Besides being more
flexible, this also has the potential to improve performance, since
it
would allow you to set your own decorator *instances* and save a
ton of
redundant pluginloader calls. Would this work or am I missing
something?
You're missing a couple fundamental things, actually. First off, not
all
elements use the same set of decorators. The Button, Submit, Reset,
and
Image elements each have a different set of decorators than the other
elements -- and users can define their own elements with their own
defaults. If we use a static member for defining this array, then we
actually *lose* flexibility, as all elements would, out of necessity,
have to use the same set (either that, or we then end up potentially
having more logic and duplicate entries in classes that don't use the
same defaults).
Additionally, your argument of using decorator instances will not
work:
class Foo
{
public static $decorators = array(
new Zend_Form_Decorator_ViewScript()
);
public function getDecorators()
{
return self::$decorators;
}
}
$foo = new Foo;
var_export($foo->getDecorators());
Try the above -- you'll get a parse error. It's not valid PHP. That
means that the only way that using decorator instances would work
with a
static member is if you add them in *MANUALLY* prior to
instantiating your objects. This sounds to me like about the same
amount
of work as doing this:
$decorators = array(
new Zend_Form_Decorator_Foo(),
new Zend_Form_Decorator_Bar(),
new Zend_Form_Decorator_Baz(),
);
$form->setElementDecorators($decorators);
Basically, statics tend to reduce flexibility in the long run as any
class with static members ends up becoming a de facto singleton.
They're
a pain to test, and even worse to extend.
Honestly, I think there's plenty of flexibility already. The thing
about
forms is, you create them once, and use them many times. Start
extending
Zend_Form, and put your logic in your extending class -- then you
have a
single place to debug it, it's not in your controller or model logic,
so you don't have to look at the details when debugging program flow.
My other thought was that the FormLabel View Helper should be able to
accept a Zend_Form_Element, thus saving you from manually calling
ZFE::getName() and ZFE::getLabel().
If you use the Label decorator, you don't have to do this anyways...
I've created an issue on the tracker for this improvement
(ZF-2865), and
included a working patch, but I'm a little unsure of the preferred
protocol
here. Should I assign this to myself? Write a unit test? I couldn't
find
anything on the dev
Re: [fw-general] RE: CHM Documentation
-- Eric Coleman <[EMAIL PROTECTED]> wrote (on Wednesday, 12 March 2008, 04:00 PM -0400): > On Mar 12, 2008, at 3:41 PM, Alan Wagstaff wrote: >> On a related note to CHM manuals, are there any plans to add a search >> function to the online manual? > > +1 for a searchable api / manual online, maybe a nice little tutorial on > using Lucene could come from it. I'm actually working on that now. :-) -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
[fw-general] Re: Large descriptions kills Atom feeds
On Sat, Mar 1, 2008 at 5:03 PM, Joó Ádám <[EMAIL PROTECTED]> wrote:
> Hello List,
>
> It took my a while to figure this out, but I think I found a strange
> bug. Generating an Atom feed using Zend_Feed, produces only two empty
> lines of output, if the provided description is longer than 1378
> characters. RSS works fine.
>
>
> Ádám
>
I still have this problem, now using RSS too. I just can't figure out
its reason. It seems that the length of the description that can be
passed in varies. But I found that, regardless of the format (Atom
description cannot contain HTML), if I wrap my description into HTML
paragraphs, it passes through.
Could somebody please help me? I don't want to put my site online,
until I don't have working feeds.
Thanks,
Ádám
PS.: Here's my code; this does not work; wrap description into
or use shorter text and it works fine.
--
Zend_Controller_Front::getInstance()->getResponse()->setHeader('Content-Type',
'text/xml; charset="utf-8"');
$feed = array(
'charset' => 'utf-8',
'description' => 'Description',
'language' => 'hu',
'link' => 'http://example.com/feed'),
'title' => 'Title',
);
foreach ($this->items as $item) {
$feed['entries'][] = array(
'description' => 'Lorem ipsum dolor sit amet, consectetuer
adipiscing elit. Fusce accumsan. Proin volutpat velit. Fusce nec nulla
quis sem dapibus tristique.
Curabitur molestie sodales mauris. Donec massa dui, commodo bibendum,
sagittis ut, congue nec, sem. Nam molestie augue sit amet tortor.
Morbi turpis enim, semper at, convallis non, tincidunt sit amet, erat.
Aenean metus tellus, lacinia ut, egestas vitae, laoreet quis, quam.
Pellentesque volutpat feugiat risus.
Ut sit amet nunc. Nunc mollis interdum ante. Mauris sit amet odio a
enim volutpat euismod. Mauris ligula. Sed pede orci, posuere in,
egestas quis, volutpat eu, ante. In ac turpis.kjfkjfgkdjghkj dkfg
kdfgdkfjgkdjfgkj hdkfjg dkfjgdkfjghk jfhdkjfghkd jfhgdkjfghkjfg kjfkdj
gdjfgh kdjghdk jhdkjf g kjfkjfgkdjghkj dkfg kdfgdkfjgkdjfgkj hdkfjg
dkfjgdkfjghk jfhdkjfghkd jfhgdkjfghkjfg kjfkdj gdjfgh kdjghdk jhdkjf g
kjfkjfgkdjghkj dkfg kdfgdkfjgkdjfgkj',
'guid' => 'http://example.com/' . $item['id']),
'link' => 'http://example.com/' . $item['id'],
'title' => $item['name'],
);
}
$feed = Zend_Feed::importArray($feed, 'rss');
$feed->send();
--
[fw-general] Lazy Autoloading View Helpers Shared Between Modules
My two cents,
I've been using viewHelpers in this way:
A view helper for a specific controller goes in directory
app/modules/views/helpers/controllerName
A view helper shared between controllers in a given module goes in
directory
app/modules/views/helpers/
A view helper shared by all modules goes in
app/views/helpers
Example:
Controller Specific viewHelpers
app/modules/default/views/helpers/index/IndexPage.phtml
app/modules/default/views/helpers/index/IndexPageForm.phtml
app/modules/default/views/helpers/login/LoginPage.php
app/modules/default/views/helpers/login/LoginPageForm.php
app/modules/default/views/helpers/login/GetMenu.php
ViewHelpers available to all controllers in default module:
app/modules/default/views/GetDefaultMenu.php
ViewHelpers available to all modules:
app/views/helpers/GetSideMenu.php
app/views/helpers/RouteOutput.php
In my acl plugin I add the view helper paths from general to specific.
With the most specific being at the controller level. Order is important..
$module = $request->module;
$controller = $request->controller;
$action = $request->action;
$view = Zend_Registry::get('view');
$views_path =
make_private_path("/app/modules/$module/views/scripts");
$view->addScriptPath($views_path);
$views_path =
make_private_path("/app/modules/$module/views/scripts/$controller");
$view->addScriptPath($views_path);
$helperPath = make_private_path("/app/views/helpers");
$view->addHelperPath($helperPath);
$helperPath =
make_private_path("/app/modules/$module/views/helpers");
$view->addHelperPath($helperPath);
$helperPath =
make_private_path("/app/modules/$module/views/helpers/$controller");
$view->addHelperPath($helperPath);
So, in my IndexController I can write:
public function indexAction() {
$view = Zend_Registry::get('view');
$text = $view->indexPage(); //call to viewHelper
$view->routeOutput('main', $text); //call to viewHelper
$view->renderView();
}
Inside IndexPage.php.php I can write:
class Zend_View_Helper_IndexPage
{
public function indexPage()
{
$view = Zend_Registry::get('view');
$view->routeOutput('menu', $view->getMenu($flag)); //call to viewHelper
return $view->indexPageForm(); // call to viewHelper
}
}
class Zend_View_Helper_IndexPageForm
{
public function indexPageForm()
{
$view = Zend_Registry::get('view');
$form = blah...
return $form;
}
}
'main_content', 'menu' =>'main_menu');
$route = $route_map[$to];
if(true === $overwrite)
$view->$route = $what; //overwrite it
else
$view->$route .= $what; // add to it
}
}
?>
The amazing thing is it will actually find the proper ViewHelper. The
view is
exo-polymorphic, you can add functions to it without touching the object or
mucking about with inheritance.
Sold on view helpers!
cheers,
pat
Re: [fw-general] RE: CHM Documentation
On Mar 12, 2008, at 3:41 PM, Alan Wagstaff wrote: On a related note to CHM manuals, are there any plans to add a search function to the online manual? +1 for a searchable api / manual online, maybe a nice little tutorial on using Lucene could come from it. Regards, Eric
Re: [fw-general] RE: CHM Documentation
Hy Alan, as I already wrote twice I will add search functionality... this is called "index" and me and the german guys are working on a first draft of it. But it's unnecessary to integrate if we have CHM not available on the homepage. Also to say... you can already search through the complete CHM file for any word. So vote for this issue, and we (Wil and me) will spend time on it. The more voters, the more spend time and the faster implementation and ready for complete comunity. Greetings Thomas Weidner, I18N Team Leader http://www.thomasweidner.com - Original Message - From: "Alan Wagstaff" <[EMAIL PROTECTED]> To: "Wil Sinclair" <[EMAIL PROTECTED]> Cc: "Thomas Weidner" <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]> Sent: Wednesday, March 12, 2008 8:41 PM Subject: Re: [fw-general] RE: CHM Documentation Hi Will, On a related note to CHM manuals, are there any plans to add a search function to the online manual? I'm so glad that Thomas has created these CHM manuals because I can finally search it rather than visually scan the very long pages of the online manual looking for what I need :-) Thanks, Alan On 12/03/2008, Wil Sinclair <[EMAIL PROTECTED]> wrote: I've been meaning to respond to this for a while- just catching up on email now. :) I won't make any promises about CHM documentation, but rest assured that we can always be convinced that adding to our build process is worthwhile if enough community members find the addition useful. That said, voting on this- or any- issue is a great way to let us know what you want us to work on first. While we don't take votes as a final say on allocating Zend resources, they have had an increasingly important role in what we prioritize lately. So, vote away! As far as adding to the build process goes, it is much more palatable if it's a fully automated solution and community members help us in updating the build scripts. Remember, to do builds early and often we have to minimize the overhead associated with them. We've been examining ways to cut this overhead down, and there is still work to do. Thanks. ,Wil > All of you who want to have the CHM documentation also in future and > for new > releases can vote in this issue > http://framework.zend.com/issues/browse/ZF-2454 for integration... > maybe we > can persuade Wil to do this for us. :-)
Re: [fw-general] RE: CHM Documentation
Hi Will, On a related note to CHM manuals, are there any plans to add a search function to the online manual? I'm so glad that Thomas has created these CHM manuals because I can finally search it rather than visually scan the very long pages of the online manual looking for what I need :-) Thanks, Alan On 12/03/2008, Wil Sinclair <[EMAIL PROTECTED]> wrote: > I've been meaning to respond to this for a while- just catching up on > email now. :) I won't make any promises about CHM documentation, but > rest assured that we can always be convinced that adding to our build > process is worthwhile if enough community members find the addition > useful. That said, voting on this- or any- issue is a great way to let > us know what you want us to work on first. While we don't take votes as > a final say on allocating Zend resources, they have had an increasingly > important role in what we prioritize lately. So, vote away! > As far as adding to the build process goes, it is much more palatable if > it's a fully automated solution and community members help us in > updating the build scripts. Remember, to do builds early and often we > have to minimize the overhead associated with them. We've been examining > ways to cut this overhead down, and there is still work to do. > > Thanks. > ,Wil > > > All of you who want to have the CHM documentation also in future and > > for new > > releases can vote in this issue > > http://framework.zend.com/issues/browse/ZF-2454 for integration... > > maybe we > > can persuade Wil to do this for us. :-) > >
[fw-general] Re: CHM Documentation
Hy Wil, I don't know if I forgot to write this, but I already changed the build script to do most of the work. If anyone of you is integrating it I could help for the rest where I did not know the details on how you build the releases and how they are integrated in the homepage. As PHP itself does also provide CHM I see no problems. I will integrate several improvments as indezes and searchkeys into the documentation. But as this is a long-time work it has no effects on the issue or homepage integration itself. Just write me if you want to save time at integration. :-) And you others should vote it you see a benefit for having this, because I will not provide CHM files in future on my homepage as I am not Zend :-)) Greetings Thomas Weidner, I18N Team Leader http://www.thomasweidner.com - Original Message - From: "Wil Sinclair" <[EMAIL PROTECTED]> To: "Thomas Weidner" <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]> Sent: Wednesday, March 12, 2008 7:56 PM Subject: RE: CHM Documentation I've been meaning to respond to this for a while- just catching up on email now. :) I won't make any promises about CHM documentation, but rest assured that we can always be convinced that adding to our build process is worthwhile if enough community members find the addition useful. That said, voting on this- or any- issue is a great way to let us know what you want us to work on first. While we don't take votes as a final say on allocating Zend resources, they have had an increasingly important role in what we prioritize lately. So, vote away! As far as adding to the build process goes, it is much more palatable if it's a fully automated solution and community members help us in updating the build scripts. Remember, to do builds early and often we have to minimize the overhead associated with them. We've been examining ways to cut this overhead down, and there is still work to do. Thanks. ,Wil All of you who want to have the CHM documentation also in future and for new releases can vote in this issue http://framework.zend.com/issues/browse/ZF-2454 for integration... maybe we can persuade Wil to do this for us. :-)
[fw-general] RE: CHM Documentation
I've been meaning to respond to this for a while- just catching up on email now. :) I won't make any promises about CHM documentation, but rest assured that we can always be convinced that adding to our build process is worthwhile if enough community members find the addition useful. That said, voting on this- or any- issue is a great way to let us know what you want us to work on first. While we don't take votes as a final say on allocating Zend resources, they have had an increasingly important role in what we prioritize lately. So, vote away! As far as adding to the build process goes, it is much more palatable if it's a fully automated solution and community members help us in updating the build scripts. Remember, to do builds early and often we have to minimize the overhead associated with them. We've been examining ways to cut this overhead down, and there is still work to do. Thanks. ,Wil > All of you who want to have the CHM documentation also in future and > for new > releases can vote in this issue > http://framework.zend.com/issues/browse/ZF-2454 for integration... > maybe we > can persuade Wil to do this for us. :-)
[fw-general] 1.5RC2 and YouTube announcement. . .
Hi all, as many of you are probably aware, YouTube made a major announcement regarding their web services API's yesterday: http://www.youtube.com/blog. What you may not be aware of is that we already have support for these API's in the RC2 GData package. Fitting this functionality in was one of the primary reasons RC2 was delayed by a few days. Please download the new client library here and let us know what you think: http://framework.zend.com/download/gdata. Now, about that RC2 release. . . :) RC2 unfortunately includes an issue that will break most applications running on Windows. It is easily corrected (Matthew has already checked in the fix, the impatient can use SVN to check out from r8781 on the 1.5 branch), but we don't want to make a release publically available that doesn't work for many of our users "out of the box". We have therefore decided to take the main 1.5RC2 package off our downloads page, and we've already begun rolling an RC3 release. I will send out a release announcement once the main 1.5RC3 package is available, hopefully before leaving the office today. Thanks for your patience, and we can all breathe easier knowing that the release candidate process is working (it caught this bug, didn't it?). ;) ,Wil
Re: [fw-general] Problem with Zend_Layout and Zend_View_Helper_Action
-- berthausmans <[EMAIL PROTECTED]> wrote (on Wednesday, 12 March 2008, 09:35 AM -0700): > > I found the problem. Zend_View_Helper_Action disables the ViewRenderer. Are you using latest trunk from svn? It doesn't disable the ViewRenderer; it clones it. This is necessary to ensure that state is correct to allow the dispatched action to auto-render as necessary. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] escaping lists
Matthew Weier O'Phinney-3 wrote: > > -- digitalus_media <[EMAIL PROTECTED]> wrote > (on Wednesday, 12 March 2008, 08:57 AM -0700): >> i am having trouble getting my head around escaping html lists. i am >> trying >> to use the htmlList helper for navigation lists, but it escapes all of >> the >> output. what is the best practice here? > > By default, it escapes. However, you can turn off escaping by passing a > false value to the escape parameter (fourth parameter): > Ok, thanks. on the subject of filtering and escaping, are there any resources that you know fo that go into depth about view filters? - http://http://code.google.com/p/digitalus-site-manager/ Digitalus Site Manager | http://forrestlyman.com Forrest Lyman -- View this message in context: http://www.nabble.com/escaping-lists-tp16005545s16154p16009372.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Routing: / != /index != /index/index?
Jan, Michals solution is right, but be sure to include the trailing slashes
and the ^ and $ markers in the regex.
On Wed, Mar 12, 2008 at 5:55 PM, Michał Minicki <[EMAIL PROTECTED]> wrote:
> Jan Pieper wrote:
> > Okay, my mistake but your solution allows something like /index/123 (if
> :article
> > is the article_id). I want that /, /index and /index/index use
> ArticleController
> > with indexAction. If no article_id is given, the application will show
> the
> > newest article.
> >
> > The actual problem is, that I don´t see a solution how to use
> > ArticleController::indexAction() at /, /index and /index/index without
> adding
> > one entry per route (= 3 routes with the same target). I think this will
> work,
> > but I don´t think that this is an clean solution.
>
> name=index {
> module: null
> controller: article
> action: index
> param1: default
> param2: default
> route: :param1/:param2
> }
>
> If you want only 'index' strings as params, you have to set requirements
> (third constructor param to route instances) as 'index'.
>
> Or you can directly use a regex route instead:
>
> new ZCR_Route_Regex(
>'(index(/index)?)?'
>array('controller' => 'article', 'action' => 'index')
> );
>
> --
> Michał Minicki aka Martel Valgoerad | [EMAIL PROTECTED] |
> http://aie.pl/martel.asc
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "Idleness is not doing nothing. Idleness is being free to do anything." --
> Floyd Dell
>
Re: [fw-general] Routing: / != /index != /index/index?
Jan Pieper wrote:
Okay, my mistake but your solution allows something like /index/123 (if :article
is the article_id). I want that /, /index and /index/index use ArticleController
with indexAction. If no article_id is given, the application will show the
newest article.
The actual problem is, that I don´t see a solution how to use
ArticleController::indexAction() at /, /index and /index/index without adding
one entry per route (= 3 routes with the same target). I think this will work,
but I don´t think that this is an clean solution.
name=index {
module: null
controller: article
action: index
param1: default
param2: default
route: :param1/:param2
}
If you want only 'index' strings as params, you have to set requirements
(third constructor param to route instances) as 'index'.
Or you can directly use a regex route instead:
new ZCR_Route_Regex(
'(index(/index)?)?'
array('controller' => 'article', 'action' => 'index')
);
--
Michał Minicki aka Martel Valgoerad | [EMAIL PROTECTED] |
http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell
Re: [fw-general] escaping lists
Hi Matthew, I'm guessing that his problem could be because htmlList doesn't pass on the escape parameter when it calls itself recursively for sub lists. I thought I've submitted an issue for this before, but I didn't! So here it is: http://framework.zend.com/issues/browse/ZF-2870 Kind Regards, - Amr On Wed, Mar 12, 2008 at 6:23 PM, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote: > -- digitalus_media <[EMAIL PROTECTED]> wrote > (on Wednesday, 12 March 2008, 08:57 AM -0700): > > i am having trouble getting my head around escaping html lists. i am > trying > > to use the htmlList helper for navigation lists, but it escapes all of > the > > output. what is the best practice here? > > By default, it escapes. However, you can turn off escaping by passing a > false value to the escape parameter (fourth parameter): > >htmlList($this->items, false, false, false); > > You should do this only if you trust the source of the items -- i.e., if > they are not user submitted. > > -- > Matthew Weier O'Phinney > PHP Developer| [EMAIL PROTECTED] > Zend - The PHP Company | http://www.zend.com/ >
Re: [fw-general] Problem with Zend_Layout and Zend_View_Helper_Action
I found the problem. Zend_View_Helper_Action disables the ViewRenderer. -- View this message in context: http://www.nabble.com/Problem-with-Zend_Layout-and-Zend_View_Helper_Action-tp16002216s16154p16007119.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] escaping lists
-- digitalus_media <[EMAIL PROTECTED]> wrote (on Wednesday, 12 March 2008, 08:57 AM -0700): > i am having trouble getting my head around escaping html lists. i am trying > to use the htmlList helper for navigation lists, but it escapes all of the > output. what is the best practice here? By default, it escapes. However, you can turn off escaping by passing a false value to the escape parameter (fourth parameter): htmlList($this->items, false, false, false); You should do this only if you trust the source of the items -- i.e., if they are not user submitted. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
[fw-general] escaping lists
i am having trouble getting my head around escaping html lists. i am trying to use the htmlList helper for navigation lists, but it escapes all of the output. what is the best practice here? - http://http://code.google.com/p/digitalus-site-manager/ Digitalus Site Manager | http://forrestlyman.com Forrest Lyman -- View this message in context: http://www.nabble.com/escaping-lists-tp16005545s16154p16005545.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Quote all database query parameters
Teemu Valimaki wrote:
>
> I noticed that numeric values are not quoted in a query. Is there a reason
> for
> not quoting all parameters automatically no matter of their type? Or
> should
> the question be, why should they be quoted? To me it should be more
> consistent, but I might miss some important point in this.
>
Some databases (e.g. Oracle), throw an error if you compare dissimilar
types.
SELECT * FROM mytable WHERE integerColumn = '1234'; -- ERROR!
But no database has a problem with an unquoted integer literal:
SELECT * FROM mytable WHERE integerColumn = 1234;
So the quote() method in the Zend_Db_Adapter classes interpret PHP native
integers and floats as meant to be unquoted. However, a PHP string passed
to the quote() method is quoted by default.
But there are some cases where we need to represent the numeric value as a
string. For instance PHP's 32-bit integer type has a smaller range than a
SQL BIGINT type. That's why Zend_Db has an optional data type argument for
quote() and related methods, so we can use numeric values outside the range
of PHP native types, but still tell the quoting function not to quote them
since it would upset the SQL engine:
$sqlExpr = $db->quoteInto('WHERE bigintColumn = ?', '2147483648',
Zend_Db::BIGINT_TYPE);
Regards,
Bill Karwin
--
View this message in context:
http://www.nabble.com/Quote-all-database-query-parameters-tp16002047s16154p16004872.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] How render Zend_Form to html table?
-- bouzafr <[EMAIL PROTECTED]> wrote
(on Wednesday, 12 March 2008, 06:31 AM -0700):
> I'm using setElementDecorators() to do something similar like the table
> example, but it doesn't do anything at all? Is that feature enabled or not
> yet?
>
> $form->setElementDecorators(array(
> 'ViewHelper',
> 'Errors',
> array('Label', array('tag' => 'dt', 'class' => 'register')),
> array('HtmlTag', array('tag' => 'dd', 'class' => 'register'))
> ));
It has to be called *after* your elements are loaded (it doesn't affect
elements loaded after that call is made), and yes, the feature is
enabled.
> Matthew Weier O'Phinney-3 wrote:
> >
> > -- wizardz <[EMAIL PROTECTED]> wrote
> > (on Tuesday, 05 February 2008, 12:43 PM -0800):
> >> I need create next html code
> >>
> >>
> >>
> >> Label
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Do I have a way to create this HTML using Zend_Form?
> >> Thank you for answers.
> >> Andriy
> >
> > To render the form into a table:
> >
> > $form->setDecorators(array(
> > 'FormElements',
> > array('HtmlTag', array('tag' => 'table')),
> > 'Form'
> > ));
> >
> > Plus, you'll need to ensure the elements and labels are in table data
> > and table rows:
> >
> > $form->setElementDecorators(array(
> > 'ViewHelper',
> > 'Errors',
> > array('decorator' => array('td' => 'HtmlTag'), 'options' =>
> > array('tag' => 'td')),
> > array('Label', array('tag' => 'td')),
> > array('decorator' => array('tr' => 'HtmlTag'), 'options' =>
> > array('tag' => 'tr')),
> > ));
> >
> > For your 'submit' button, you'll want to modify the decorators so the
> > submit spans both columns:
> >
> > $form->submit->setDecorators(array(
> > array(
> > 'decorator' => 'ViewHelper',
> > 'options' => array('helper' => 'formSubmit')),
> > array(
> > 'decorator' => array('td' => 'HtmlTag'),
> > 'options' => array('tag' => 'td', 'colspan' => 2)),
> > array(
> > 'decorator' => array('tr' => 'HtmlTag'),
> > 'options' => array('tag' => 'tr')),
> > ));
> >
> > Enjoy.
> >
> > --
> > Matthew Weier O'Phinney
> > PHP Developer| [EMAIL PROTECTED]
> > Zend - The PHP Company | http://www.zend.com/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-render-Zend_Form-to-html-table--tp15299082s16154p16002312.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] How render Zend_Form to html table?
Matthew,
I'm using setElementDecorators() to do something similar like the table
example, but it doesn't do anything at all? Is that feature enabled or not
yet?
$form->setElementDecorators(array(
'ViewHelper',
'Errors',
array('Label', array('tag' => 'dt', 'class' => 'register')),
array('HtmlTag', array('tag' => 'dd', 'class' => 'register'))
));
Thank you.
Matthew Weier O'Phinney-3 wrote:
>
> -- wizardz <[EMAIL PROTECTED]> wrote
> (on Tuesday, 05 February 2008, 12:43 PM -0800):
>> I need create next html code
>>
>>
>>
>> Label
>>
>>
>>
>>
>>
>>
>>
>> Do I have a way to create this HTML using Zend_Form?
>> Thank you for answers.
>> Andriy
>
> To render the form into a table:
>
> $form->setDecorators(array(
> 'FormElements',
> array('HtmlTag', array('tag' => 'table')),
> 'Form'
> ));
>
> Plus, you'll need to ensure the elements and labels are in table data
> and table rows:
>
> $form->setElementDecorators(array(
> 'ViewHelper',
> 'Errors',
> array('decorator' => array('td' => 'HtmlTag'), 'options' =>
> array('tag' => 'td')),
> array('Label', array('tag' => 'td')),
> array('decorator' => array('tr' => 'HtmlTag'), 'options' =>
> array('tag' => 'tr')),
> ));
>
> For your 'submit' button, you'll want to modify the decorators so the
> submit spans both columns:
>
> $form->submit->setDecorators(array(
> array(
> 'decorator' => 'ViewHelper',
> 'options' => array('helper' => 'formSubmit')),
> array(
> 'decorator' => array('td' => 'HtmlTag'),
> 'options' => array('tag' => 'td', 'colspan' => 2)),
> array(
> 'decorator' => array('tr' => 'HtmlTag'),
> 'options' => array('tag' => 'tr')),
> ));
>
> Enjoy.
>
> --
> Matthew Weier O'Phinney
> PHP Developer| [EMAIL PROTECTED]
> Zend - The PHP Company | http://www.zend.com/
>
>
--
View this message in context:
http://www.nabble.com/How-render-Zend_Form-to-html-table--tp15299082s16154p16002312.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] ACL actual use
Alex, I have my controllers/actions mapped directly to resources/privileges. I have a controller plugin that checks on predispatch to see if the user has access to the requested controller/action and, if not, routes them to a 404 or denied page. Jason On Tue, Mar 11, 2008 at 12:17 PM, Alexander Johannesen < [EMAIL PROTECTED]> wrote: > Hi, > > Has anyone used Zend ACL in an active project, and would like to share > some thoughts on it? (Pro/con/gotcha's) I'm about to implement it into > a larger framework (an extension of ZF, really) and would like to hear > people's opinions before I get my surgeons knife out... > > Also, has anyone defined an ACL definition / ini files? Much of the > API can be replicated through much simpler ini files, so if anyone has > done this I could save some time. > > > Alex > -- > > --- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > -- http://shelter.nu/blog/ >
Re: [fw-general] Quote all database query parameters
Teemu Välimäki schreef: On Wednesday 12 March 2008 14:21:43 Isaak Malik wrote: I think the question would rather be: "why should they be quoted?", if the value is validated as a numeric value there is no need to quote them because there are no reserved numeric keywords in SQL and it's no threat to not quote them. I want to make it clear, that I am not pushing for the idea of quoting everything just because it would be possible. The question came to when I looked at a query where two out of three integer values were quoted. Those two came probably as a string and the one did not, just like you said it should work. However, if we fail to detect the correct type, then why not simply quote everything for consistency. Of course, this is hardly an issue. Well, it's not really "failing to detect the correct type", if the value has been passed as a string it's very normal that these are being quoted, so the Zend FW is doing its work. If this troubles you why not (int) or (float) them before they are being passed? If the value can also be non-numeric types then you should just ignore this, as this can do no harm :). -- Isaak Malik Web Developer [EMAIL PROTECTED]
Re: [fw-general] Hardcoded form decorators and the FormLabel helper
-- Nathan <[EMAIL PROTECTED]> wrote
(on Tuesday, 11 March 2008, 04:00 PM -0700):
> First and foremost, hard coded default decorators seems suboptimal.
> Extending all the elements to define your own defaults isn't much of an
> option, since you'd have to subclass all the element classes. I realize the
> defaults can be bypassed by passing your own decorators to the element's
> constructor, but this isn't always ideal either.
I want to point out a few things here. First, it's hardly "hard coding"
-- it's providing sane defaults. There *is* a difference -- hard coding
means you wouldn't be able to change them, and, quite clearly from your
own explanation, you can.
Let's look at the flexibility availalble here (forgive me if I'm
repeating you a little...):
* You can subclass and override the loadDefaultDecorators() method
* You can pass in decorators when creating elements/forms/etc, which
will prevent the default decorators from loading
* You can even prevent the default decorators from loading at all (by
passing a 'disableLoadDefaultDecorators' option at instantiation)
* You can set all element or display group decorators at once
(setElementDecororators(), setDisplayGroupDecorators())
I'm failing to see how this is not enough flexibility, but, whatever.
> I propose that default decorators be loaded from a static array via
> addDecorators(). Then the static array could be overridden by calling
> Zend_Form_Element::setDefaultDecorators($array). Besides being more
> flexible, this also has the potential to improve performance, since it
> would allow you to set your own decorator *instances* and save a ton of
> redundant pluginloader calls. Would this work or am I missing something?
You're missing a couple fundamental things, actually. First off, not all
elements use the same set of decorators. The Button, Submit, Reset, and
Image elements each have a different set of decorators than the other
elements -- and users can define their own elements with their own
defaults. If we use a static member for defining this array, then we
actually *lose* flexibility, as all elements would, out of necessity,
have to use the same set (either that, or we then end up potentially
having more logic and duplicate entries in classes that don't use the
same defaults).
Additionally, your argument of using decorator instances will not work:
class Foo
{
public static $decorators = array(
new Zend_Form_Decorator_ViewScript()
);
public function getDecorators()
{
return self::$decorators;
}
}
$foo = new Foo;
var_export($foo->getDecorators());
Try the above -- you'll get a parse error. It's not valid PHP. That
means that the only way that using decorator instances would work with a
static member is if you add them in *MANUALLY* prior to
instantiating your objects. This sounds to me like about the same amount
of work as doing this:
$decorators = array(
new Zend_Form_Decorator_Foo(),
new Zend_Form_Decorator_Bar(),
new Zend_Form_Decorator_Baz(),
);
$form->setElementDecorators($decorators);
Basically, statics tend to reduce flexibility in the long run as any
class with static members ends up becoming a de facto singleton. They're
a pain to test, and even worse to extend.
Honestly, I think there's plenty of flexibility already. The thing about
forms is, you create them once, and use them many times. Start extending
Zend_Form, and put your logic in your extending class -- then you have a
single place to debug it, it's not in your controller or model logic,
so you don't have to look at the details when debugging program flow.
> My other thought was that the FormLabel View Helper should be able to
> accept a Zend_Form_Element, thus saving you from manually calling
> ZFE::getName() and ZFE::getLabel().
If you use the Label decorator, you don't have to do this anyways...
> I've created an issue on the tracker for this improvement (ZF-2865), and
> included a working patch, but I'm a little unsure of the preferred protocol
> here. Should I assign this to myself? Write a unit test? I couldn't find
> anything on the dev wiki which explains what's involved nor how you can
> help to the process along. Any insights would be appreciated, as this is
> the first open source project I've taken an interest in contributing to.
Submit a patch that includes a unit test, and I'll review and (a)
determine if it's a feature we want to include, and (b) apply the patch
if we do.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
[fw-general] Problem with Zend_Layout and Zend_View_Helper_Action
In a certain controller i want to pass content from another module/controller
into the layout script by using the Zend_View_Helper_Action view helper.
After calling "$this->view->action();" in the controller
"$this->layout()->content;" in the view is empty. How is this possible?
# Controller ##
...
$moduleContent = $this->view->action('login', 'index', 'mod_user'); //
Content is correct
$this->view->placeholder('sidebar')->set($moduleContent);
...
# View ##
...
action('index', 'index', 'mod_menu'); // Works fine! ?>
layout()->content; // No content using
"$this->view->action();" in the controller. ?>
placeholder('sidebar'); // Works fine! ?>
...
--
View this message in context:
http://www.nabble.com/Problem-with-Zend_Layout-and-Zend_View_Helper_Action-tp16002216s16154p16002216.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Quote all database query parameters
On Wednesday 12 March 2008 14:21:43 Isaak Malik wrote: > I think the question would rather be: "why should they be quoted?", if > the value is validated as a numeric value there is no need to quote them > because there are no reserved numeric keywords in SQL and it's no threat > to not quote them. I want to make it clear, that I am not pushing for the idea of quoting everything just because it would be possible. The question came to when I looked at a query where two out of three integer values were quoted. Those two came probably as a string and the one did not, just like you said it should work. However, if we fail to detect the correct type, then why not simply quote everything for consistency. Of course, this is hardly an issue. -- Teemu Valimaki <[EMAIL PROTECTED]>
Re: [fw-general] RC2 tmp/zf.log error
-- steve2002 <[EMAIL PROTECTED]> wrote
(on Wednesday, 12 March 2008, 04:01 AM -0700):
> Using a very simple Hello World test which worked under RC1 I get the
> following error now with RC2. Any ideas appreciated. Thanks.
There was some debug code that accidently got checked into the release
branch. I've removed it now, but it came after RC2 was released. :-/
You can check out from the release-1.5 branch, or trunk, and this will
be gone.
> Unexpected Exception: "/tmp/zf.log" cannot be opened with mode "a"
>
> #0 C:\Documents and Settings\steve\My
> Documents\websites\dev0002-places\lib\Zend\Controller\Action\Helper\ViewRenderer.php(873):
> Zend_Log_Writer_Stream->__construct('/tmp/zf.log')
> #1 C:\Documents and Settings\steve\My
> Documents\websites\dev0002-places\lib\Zend\Controller\Action\Helper\ViewRenderer.php(898):
> Zend_Controller_Action_Helper_ViewRenderer->renderScript('index/index.pht...',
> NULL)
> #2 C:\Documents and Settings\steve\My
> Documents\websites\dev0002-places\lib\Zend\Controller\Action\Helper\ViewRenderer.php(937):
> Zend_Controller_Action_Helper_ViewRenderer->render()
> #3 C:\Documents and Settings\steve\My
> Documents\websites\dev0002-places\lib\Zend\Controller\Action\HelperBroker.php(161):
> Zend_Controller_Action_Helper_ViewRenderer->postDispatch()
> #4 C:\Documents and Settings\steve\My
> Documents\websites\dev0002-places\lib\Zend\Controller\Action.php(512):
> Zend_Controller_Action_HelperBroker->notifyPostDispatch()
> #5 C:\Documents and Settings\steve\My
> Documents\websites\dev0002-places\lib\Zend\Controller\Dispatcher\Standard.php(293):
> Zend_Controller_Action->dispatch('indexAction')
> #6 C:\Documents and Settings\steve\My
> Documents\websites\dev0002-places\lib\Zend\Controller\Front.php(914):
> Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http),
> Object(Zend_Controller_Response_Http))
> #7 C:\Documents and Settings\steve\My
> Documents\websites\htdocs\dev0002-places\index.php(62):
> Zend_Controller_Front->dispatch()
> #8 {main}
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Quote all database query parameters
First a big thank you for Mr. O'Phinney and others for helping out in my previous questions. I noticed that numeric values are not quoted in a query. Is there a reason for not quoting all parameters automatically no matter of their type? Or should the question be, why should they be quoted? To me it should be more consistent, but I might miss some important point in this. I think the question would rather be: "why should they be quoted?", if the value is validated as a numeric value there is no need to quote them because there are no reserved numeric keywords in SQL and it's no threat to not quote them. -- Isaak Malik Web Developer [EMAIL PROTECTED]
[fw-general] RC"
-- View this message in context: http://www.nabble.com/RC%22-tp16001707s16154p16001707.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Quote all database query parameters
First a big thank you for Mr. O'Phinney and others for helping out in my previous questions. I noticed that numeric values are not quoted in a query. Is there a reason for not quoting all parameters automatically no matter of their type? Or should the question be, why should they be quoted? To me it should be more consistent, but I might miss some important point in this. -- Teemu Valimaki <[EMAIL PROTECTED]>
