Re: [fw-general] Using Zend_Rest to move image files

[till]

On Thu, Jul 17, 2008 at 7:48 PM, Ron Dyck <[EMAIL PROTECTED]> wrote:
> I'd like to move image files from a Zend_Rest client to a Zend_Rest server.
> I'm assuming this is possible utilizing the client post method.
>
> Does anyone have any comments on this? I'm hoping this should be fairly
> simple but would appreciate any suggestions before I start spinning my
> wheels.

It's probably PUT. :-)

Do you need an example of how to use Zend_Rest_* or are you using it
with a public API?

Till

[fw-general] Re: Re[fw-general] cent Component Promotions

[Juan E.]

I have been trying to use the Dojo_Form component with the docs examples and
I was having some problems to get it working so finally I downloaded the
demo I found in the issue tracker
http://framework.zend.com/issues/browse/ZF-3559 and everything worked ok
until I deleted the library/incubator and the library/Zend directories that
are part of the zip file and went back to use the SVN download of the
current trunk.
After that I'm getting a Warning message "Warning: helper 'GetPluginLoader'
not found in path in F:\xampp\php\PEAR\Zend\Form.php on line 2344" 
Maybe I'm doing something wrong, but I'm running out of ideas as to where to
look.

Thanks.


> 
> On Jul 16, 2008, at 11:16 AM, Matthew Weier O'Phinney wrote:
> 
> 
> 
> Greetings, all --
> 
> 
> 
> I've promoted the following components from
> standard/incubator/ to
> 
> standard/trunk/ in preparation for the 1.6.0 release:
> 
> 
> 
> * Zend_Dom_Query: use CSS selectors to query (X)HTML/XML
> documents
> 
> * Zend_Dojo: ZF/Dojo integration layer
> 
> * Zend_Json_Server: JSON-RPC implementation
> 
> * Zend_Session_SaveHandler_DbTable: Store session data in a
> database
> 
>   table
> 
> * Zend_Test_PHPUnit: testing infrastructure for MVC
> applications
> 
> * Zend_Text_Figlet: create Figlets with ZF
> 
> 
> 
> If you haven't tried these new components out yet, please do.
> If
> you
> 
> haven't due to lack of documentation, documentation is
> available in
>  
> 
> the
> 
> documentation/manual/en/module_specs/ tree in human-readable
> DocBook,
> 
> with full PHP examples and use cases.
> 
> 
> 
> A hearty thank you to all contributors and testers involved
> with  
> 
> making
> 
> these components a reality!
> 
> 
> 
> --
> 
> Matthew Weier O'Phinney
> 
> Software Architect   | [EMAIL PROTECTED]
> 
> Zend Framework   | http://framework.zend.com/
> 
> 
> 
> 
> --
> Matthew Weier O'Phinney
> Software Architect   | [EMAIL PROTECTED]
> Zend Framework   | http://framework.zend.com/
> 
> 

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/



-- 
View this message in context: 
http://www.nabble.com/Recent-Component-Promotions-tp18491148p18523206.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Recent Component Promotions

[Matthew Weier O'Phinney]

-- Todd Wolaver <[EMAIL PROTECTED]> wrote
(on Thursday, 17 July 2008, 06:01 PM -0500):
> I have another question regarding the dojo view helper...
> 
> Is there a way to disable the dojoType="dijit.form.Form" from being added to
> the  attributes on a standard Zend_Form() when
> using Zend_Dojo_View_Helper
> 
> In bootstrap:
> $view->addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');
> 
> In controller:
> $form = new Zend_From();
> 
> Returns:
>  id=""
> dojoType="dijit.form.Form">
> 
> Is this standard behavior or do I have something mixed up somewhere?  
> 
> It isn't a big deal but I'd like to disable it for now as my reset buttons in
> my standard forms seem to be disabled in a dojoType = dijit.form.Form

Please file an issue for this. I'm not quite sure how that's happening,
but I suspect the Zend_Dojo_View_Helper_Form view helper is getting used
and not the standard form view helper -- but even so, it should not be
setting the dojoType attribute unless you're using declarative syntax
(which is disabled by default).

File the issue, and I'll look into it after RC1.

> On Jul 17, 2008, at 12:04 PM, Matthew Weier O'Phinney wrote:
> 
> 
> -- Todd Wolaver <[EMAIL PROTECTED]> wrote
> (on Thursday, 17 July 2008, 11:17 AM -0500):
> 
> I've been playing with the Dojo view helper and Zend_Dojo_Form it all 
>  
> 
> looks great and easy to implement.
> 
> 
> 
> I did find a minor issue in the view helper related to adding module  
> 
> paths.  The generated code doesn't include the path for the module  
> 
> namespace.
> 
> 
> 
> Valid Dojo syntax would be:
> 
> dojo.registerModulePath("foo", "../../foo");
> 
> 
> 
> Veiw helper outputs:
> 
> dojo.registerModulePath("foo");
> 
> 
> 
> I've updated the _renderExtras method in  
> 
> Zend_Dojo_View_Helper_Dojo_Container to get it working for now.  I can
>  
> 
> add a bug to the issue tracker if you like but I didn't see a category
>  
> 
> for Zend_Dojo in there yet.
> 
> 
> I've added a category for this now; please enter the issue, and, if
> possible, attach the patch.
> 
> 
> As a side note on Zend_Dojo_Form, I'm having a hard time figuring out 
>  
> 
> how to get the checkboxes in MultiCheckbox to render as a Dijit  
> 
> checkbox, any suggestions?
> 
> 
> Hmm... I may need to add a MultiCheckBox dijit element. Place a feature
> request in the tracker for this; I can see this being useful.
> 
> 
> 
> On Jul 16, 2008, at 11:16 AM, Matthew Weier O'Phinney wrote:
> 
> 
> 
> Greetings, all --
> 
> 
> 
> I've promoted the following components from standard/incubator/ to
> 
> standard/trunk/ in preparation for the 1.6.0 release:
> 
> 
> 
> * Zend_Dom_Query: use CSS selectors to query (X)HTML/XML documents
> 
> * Zend_Dojo: ZF/Dojo integration layer
> 
> * Zend_Json_Server: JSON-RPC implementation
> 
> * Zend_Session_SaveHandler_DbTable: Store session data in a
> database
> 
>   table
> 
> * Zend_Test_PHPUnit: testing infrastructure for MVC applications
> 
> * Zend_Text_Figlet: create Figlets with ZF
> 
> 
> 
> If you haven't tried these new components out yet, please do. If
> you
> 
> haven't due to lack of documentation, documentation is available 
> in
>  
> 
> the
> 
> documentation/manual/en/module_specs/ tree in human-readable
> DocBook,
> 
> with full PHP examples and use cases.
> 
> 
> 
> A hearty thank you to all contributors and testers involved with  
> 
> making
> 
> these components a reality!
> 
> 
> 
> --
> 
> Matthew Weier O'Phinney
> 
> Software Architect   | [EMAIL PROTECTED]
> 
> Zend Framework   | http://framework.zend.com/
> 
> 
> 
> 
> --
> Matthew Weier O'Phinney
> Software Architect   | [EMAIL PROTECTED]
> Zend Framework   | http://framework.zend.com/
> 
> 

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

[fw-general] Using Zend_Rest to move image files

[Ron Dyck]

I'd like to move image files from a Zend_Rest client to a Zend_Rest server.
I'm assuming this is possible utilizing the client post method.

Does anyone have any comments on this? I'm hoping this should be fairly
simple but would appreciate any suggestions before I start spinning my
wheels.

Regards,
-- 
=
Ron Dyck
[EMAIL PROTECTED]
www.webbtech.net
=

Re: [fw-general] Recent Component Promotions

[Todd Wolaver]

I have another question regarding the dojo view helper...

Is there a way to disable the dojoType="dijit.form.Form" from being  
added to the  attributes on a standard Zend_Form() when using  
Zend_Dojo_View_Helper


In bootstrap:
$view->addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');

In controller:
$form = new Zend_From();

Returns:
method="post" id="" dojoType="dijit.form.Form">


Is this standard behavior or do I have something mixed up somewhere?

It isn't a big deal but I'd like to disable it for now as my reset  
buttons in my standard forms seem to be disabled in a dojoType =  
dijit.form.Form


Thanks,
Todd

On Jul 17, 2008, at 12:04 PM, Matthew Weier O'Phinney wrote:


-- Todd Wolaver <[EMAIL PROTECTED]> wrote
(on Thursday, 17 July 2008, 11:17 AM -0500):

I've been playing with the Dojo view helper and Zend_Dojo_Form it all
looks great and easy to implement.

I did find a minor issue in the view helper related to adding module
paths.  The generated code doesn't include the path for the module
namespace.

Valid Dojo syntax would be:
dojo.registerModulePath("foo", "../../foo");

Veiw helper outputs:
dojo.registerModulePath("foo");

I've updated the _renderExtras method in
Zend_Dojo_View_Helper_Dojo_Container to get it working for now.  I  
can
add a bug to the issue tracker if you like but I didn't see a  
category

for Zend_Dojo in there yet.


I've added a category for this now; please enter the issue, and, if
possible, attach the patch.


As a side note on Zend_Dojo_Form, I'm having a hard time figuring out
how to get the checkboxes in MultiCheckbox to render as a Dijit
checkbox, any suggestions?


Hmm... I may need to add a MultiCheckBox dijit element. Place a  
feature

request in the tracker for this; I can see this being useful.



On Jul 16, 2008, at 11:16 AM, Matthew Weier O'Phinney wrote:


Greetings, all --

I've promoted the following components from standard/incubator/ to
standard/trunk/ in preparation for the 1.6.0 release:

* Zend_Dom_Query: use CSS selectors to query (X)HTML/XML documents
* Zend_Dojo: ZF/Dojo integration layer
* Zend_Json_Server: JSON-RPC implementation
* Zend_Session_SaveHandler_DbTable: Store session data in a database
  table
* Zend_Test_PHPUnit: testing infrastructure for MVC applications
* Zend_Text_Figlet: create Figlets with ZF

If you haven't tried these new components out yet, please do. If you
haven't due to lack of documentation, documentation is available in
the
documentation/manual/en/module_specs/ tree in human-readable  
DocBook,

with full PHP examples and use cases.

A hearty thank you to all contributors and testers involved with
making
these components a reality!

--
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/




--
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] Zend_Deprecation is ready for community review.

[Bryce Lohr]

Bill Karwin wrote:

You could also consider using Zend_Log for deprecation messages.  Create a
Zend_Log object and store it in the Zend_Registry under a documented key,
such as 'Zend_Deprecation_Log'.  Each class or method that needs to report
deprecation would check the registry to see if that key exists and contains
a Zend_Log object.  If so, use it.  If no such object exists, then be
silent.  Zend_Log allows the developer to customize logging output,
including filtering levels.  Also you can create custom logging levels for
one or more deprecation levels.

So you'd leverage an existing part of ZF.  Unless of course Zend_Log becomes
deprecated!  ;-)

  


Leveraging existing components is always a good goal to strive for, but 
we should also consider what cost would be introduced by coupling every 
component with a deprecation to Zend_Log. In many cases, it would 
introduce a new dependency that doesn't currently exist. I don't have a 
feel for how big of a deal this is right now, but I figured it would be 
worth mentioning.


Regards,
Bryce Lohr

Re: [fw-general] Zend_Deprecation is ready for community review.

[Tobias Gies]

>
> You can also use @deprecated.
>
> <
> http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.deprecated.pkg.html
> >
>
> @deprecated is already used in ZF. The problem is that the developer gets
no feedback  about the deprecated components that are used in his/her
specific application. Throwing an E_USER_NOTICE or using Zend_Log will
provide this feedback to the developer.

Best regards,
Tobias

Re: [fw-general] Zend_Deprecation is ready for community review.

[Tobias Gies]

>
> I'm just trying to help explore your idea, not trying to shoot it down.

I never felt like you tried to shoot it down :-)


> In general, though, if you can solve a problem satisfactorily without
> writing
> any new code, that's better, isn't it?

Indeed.


>
>
> Yes, if multiple deprecation error types is a requirement, and cannot be
> satisfied simply with E_USER_NOTICE and establishing a convention for the
> deprecation notice message text, then perhaps a custom solution is needed.
> However, it's not clear that this is so important that it justifies a new
> component.  How many things are expected to become deprecated in ZF 2.0?
> Will the messages be so numerous to require special classes to report them?

Now that I come to think of it, probably no.


>
>
> You could also consider using Zend_Log for deprecation messages.  Create a
> Zend_Log object and store it in the Zend_Registry under a documented key,
> such as 'Zend_Deprecation_Log'.  Each class or method that needs to report
> deprecation would check the registry to see if that key exists and contains
> a Zend_Log object.  If so, use it.  If no such object exists, then be
> silent.  Zend_Log allows the developer to customize logging output,
> including filtering levels.  Also you can create custom logging levels for
> one or more deprecation levels.

Good idea!

You'd want a static method to do the above, so why not add it to Zend_Debug,
> which many folks have complained is a bit thin anyway.

Sounds reasonable.

Thanks for your input! I'm glad my announcement did at least start a
discussion about a reasonable way of showing the developer what is
deprecated. Your Zend_Log suggestion is the better idea!

Best regards,
Tobias

Re: [fw-general] Zend_Deprecation is ready for community review.

[till]

On Thu, Jul 17, 2008 at 1:42 PM, Bill Karwin <[EMAIL PROTECTED]> wrote:
>
>
>
> Tobias Gies wrote:
>>
>> as we approach 2.0, we will have to think of a way to report deprecated
>> class or method calls to the developer.
>>
>
> Does this really need a new component?  What's wrong with
> trigger_error(E_USER_NOTICE)?  This seems a lot simpler and more concise.
>
> It also satisfies your goal of eliminating the tedium of resolving one
> exception at a time.  Notices are not fatal; you can get a bunch of them
> during one execution.
>
> People who want to filter out the notices can do:
>  error_reporting(error_reporting() & ~E_USER_NOTICE);
> ...either in their bootstrap or else in php.ini.
>
> Regards,
> Bill Karwin

You can also use @deprecated.



Till

Re: [fw-general] Zend_Deprecation is ready for community review.

[Bill Karwin]

Tobias Gies wrote:
> 
> I'm all for simplicity, I just thought it could be useful to have multiple
> deprecation error types. If others agree that simply throwing an
> E_USER_NOTICE error is enough, we may well archive the proposal.
> 

I'm just trying to help explore your idea, not trying to shoot it down.  In
general, though, if you can solve a problem satisfactorily without writing
any new code, that's better, isn't it?

Yes, if multiple deprecation error types is a requirement, and cannot be
satisfied simply with E_USER_NOTICE and establishing a convention for the
deprecation notice message text, then perhaps a custom solution is needed. 
However, it's not clear that this is so important that it justifies a new
component.  How many things are expected to become deprecated in ZF 2.0? 
Will the messages be so numerous to require special classes to report them?

You could also consider using Zend_Log for deprecation messages.  Create a
Zend_Log object and store it in the Zend_Registry under a documented key,
such as 'Zend_Deprecation_Log'.  Each class or method that needs to report
deprecation would check the registry to see if that key exists and contains
a Zend_Log object.  If so, use it.  If no such object exists, then be
silent.  Zend_Log allows the developer to customize logging output,
including filtering levels.  Also you can create custom logging levels for
one or more deprecation levels.

So you'd leverage an existing part of ZF.  Unless of course Zend_Log becomes
deprecated!  ;-)

You'd want a static method to do the above, so why not add it to Zend_Debug,
which many folks have complained is a bit thin anyway.

Regards,
Bill Karwin
-- 
View this message in context: 
http://www.nabble.com/Zend_Deprecation-is-ready-for-community-review.-tp18513175p18517017.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Zend_Deprecation is ready for community review.

[Tobias Gies]

I'm all for simplicity, I just thought it could be useful to have multiple
deprecation error types. If others agree that simply throwing an
E_USER_NOTICE error is enough, we may well archive the proposal.

Best regards,
Tobias

2008/7/17 Bill Karwin <[EMAIL PROTECTED]>:

>
>
>
> Tobias Gies wrote:
> >
> > as we approach 2.0, we will have to think of a way to report deprecated
> > class or method calls to the developer.
> >
>
> Does this really need a new component?  What's wrong with
> trigger_error(E_USER_NOTICE)?  This seems a lot simpler and more concise.
>
> It also satisfies your goal of eliminating the tedium of resolving one
> exception at a time.  Notices are not fatal; you can get a bunch of them
> during one execution.
>
> People who want to filter out the notices can do:
>  error_reporting(error_reporting() & ~E_USER_NOTICE);
> ...either in their bootstrap or else in php.ini.
>
> Regards,
> Bill Karwin
> --
> View this message in context:
> http://www.nabble.com/Zend_Deprecation-is-ready-for-community-review.-tp18513175p18514041.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
>

[fw-general] zf-contributor list has been created!

[Wil Sinclair]

Howdy all, the zf-contributor list has been created. Please send a mail
to [EMAIL PROTECTED] to subscribe.
Please keep in mind that this provides a forum for contributors to the
ZF project to discuss development of the framework itself and the
scheduling thereof. Everyone is welcome to subscribe, but please do not
post to this list with user-oriented messages such as usage questions.
Such messages should continue to be posted on the 'fw-*' mailing lists.
Thanks, and looking forward to seeing all of you on the contributor
list!

,Wil 

Re: [fw-general] in latest standard trunk: decorators seem to have escaped from their original logic.

[Taco Jung]

Thanks Matthew,

I think I just figured that out myself!

Regards, TJ.



On Thu, Jul 17, 2008 at 8:21 PM, Matthew Weier O'Phinney <[EMAIL PROTECTED]>
wrote:

> -- Codiac <[EMAIL PROTECTED]> wrote
> (on Thursday, 17 July 2008, 10:39 AM -0700):
> > I have to retract my previous mail, stating the issue is resolved. I've
> > double checked and there's definitely something strange going on with
> adding
> > filters to elements using Zend_Config_Xml. Not sure what it is (probably
> me
> > again), so i need help.
> >
> > I played around with setting different (very wrong) options for the
> > StripTags filter, so now I have the following in my config file:
>
> Here's a simple XML config file I used:
>
>
>
>
>
>
>text
>
>keywords
>Keywords
>
>
> StripTags
>
>
> 
> 
>
>
>  class
>1
>
>
>
>
>
>
>
>
>
> I then did the following script:
>
>$config = new Zend_Config_Xml(dirname(__FILE__) . '/form.xml', 'form');
>$form = new Zend_Form($config);
>$filters = $form->keywords->getFilters();
>var_export($filters);
>
> and I get the following output:
>
>array (
>'Zend_Filter_StripTags' =>
>Zend_Filter_StripTags::__set_state(array(
>'commentsAllowed' => true,
>'_tagsAllowed' =>
>array (
>'tag' =>
>array (
>'' => NULL,
>'' => NULL,
>),
>),
>'_attributesAllowed' =>
>array (
>'class' => NULL,
>),
>)),
>)
>
> As you can see, the filter is being correctly setup.
>
> One thing to note when using configuration: the options you pass are
> passed IN ORDER to the constructor of the filter -- you can't skip
> options, nor can you pass them out-of-order -- which is why the below
> config does not work. It's missing the first argument (corresponding to
> 'tagsAllowed'), and it's got commentsAllowed and attributesAllowed in
> the wrong order.
>
>
> > 
> > 
> > StripTags
> > 
> > 
> > 
> > 
> > 
> > class
> > 
> > 
> > 
> > 
> >
> > I used $form->getElement('body')->getFilter('StripTags')  to get the
> filter
> > from the element and used a simple print_r to check how it was setup:
> >
> > Zend_Filter_StripTags Object([commentsAllowed] =>
> [_tagsAllowed:protected]
> > => Array([ => Array())
> > [_attributesAllowed:protected] => Array([class] => ))
> >
> >
> > ???
> >
> > When I use the following config of options:
> >
> >
> > 
> > 
> > StripTags
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > class
> > 
> > 
> > 
> > 
> >
> > I get:
> >
> > Zend_Filter_StripTags Object([commentsAllowed] => 1
> [_tagsAllowed:protected]
> > => Array([tag] => Array([] => ))
> >
> > [_attributesAllowed:protected] => Array([] => ))
> >
> > What the !@&$
> >
> > Questions:
> > Do I need to add all options in the config file for a filter? Is there a
> > particular order in which to add those options?
> >
> > No matter which order I use for setting the optionsthey simple don't
> get
> > set properly! Does it have anything to do with the following code in
> > Zend_Form_Element::_loadFilter?
> >
> >  if (empty($filter['options'])) {
> > $instance = new $name;
> > } else {
> > $r = new ReflectionClass($name);
> > if ($r->hasMethod('__construct')) {
> > $instance = $r->newInstanceArgs((array)
> $filter['options']);
> > } else {
> > $instance = $r->newInstance();
> > }
> > }
>
> --
> Matthew Weier O'Phinney
> Software Architect   | [EMAIL PROTECTED]
> Zend Framework   | http://framework.zend.com/
>

Re: [fw-general] in latest standard trunk: decorators seem to have escaped from their original logic.

[Taco Jung]

Hi,

Sorry for all the spam I've been spitting out, but I've found out that this
XML config setup works! Is this the way it's supposed to work?

Regards, TJ.



StripTags

Re: [fw-general] in latest standard trunk: decorators seem to have escaped from their original logic.

[Matthew Weier O'Phinney]

-- Codiac <[EMAIL PROTECTED]> wrote
(on Thursday, 17 July 2008, 10:39 AM -0700):
> I have to retract my previous mail, stating the issue is resolved. I've
> double checked and there's definitely something strange going on with adding
> filters to elements using Zend_Config_Xml. Not sure what it is (probably me
> again), so i need help.
> 
> I played around with setting different (very wrong) options for the
> StripTags filter, so now I have the following in my config file:

Here's a simple XML config file I used:






text

keywords
Keywords


StripTags





class
1









I then did the following script:

$config = new Zend_Config_Xml(dirname(__FILE__) . '/form.xml', 'form');
$form = new Zend_Form($config);
$filters = $form->keywords->getFilters();
var_export($filters);

and I get the following output:

array (
'Zend_Filter_StripTags' =>
Zend_Filter_StripTags::__set_state(array(
'commentsAllowed' => true,
'_tagsAllowed' =>
array (
'tag' =>
array (
'' => NULL,
'' => NULL,
),
),
'_attributesAllowed' =>
array (
'class' => NULL,
),
)),
)

As you can see, the filter is being correctly setup.

One thing to note when using configuration: the options you pass are
passed IN ORDER to the constructor of the filter -- you can't skip
options, nor can you pass them out-of-order -- which is why the below
config does not work. It's missing the first argument (corresponding to
'tagsAllowed'), and it's got commentsAllowed and attributesAllowed in
the wrong order.


> 
> 
> StripTags
> 
> 
> 
> 
> 
> class
> 
> 
> 
> 
> 
> I used $form->getElement('body')->getFilter('StripTags')  to get the filter
> from the element and used a simple print_r to check how it was setup:
> 
> Zend_Filter_StripTags Object([commentsAllowed] => [_tagsAllowed:protected]
> => Array([ => Array())
> [_attributesAllowed:protected] => Array([class] => ))
> 
> 
> ???
> 
> When I use the following config of options:
> 
> 
> 
> 
> StripTags
> 
> 
> 
>
> 
> 
> 
> 
> class
> 
> 
> 
> 
> 
> I get:
> 
> Zend_Filter_StripTags Object([commentsAllowed] => 1 [_tagsAllowed:protected]
> => Array([tag] => Array([] => ))
> 
> [_attributesAllowed:protected] => Array([] => ))
> 
> What the !@&$
> 
> Questions:
> Do I need to add all options in the config file for a filter? Is there a
> particular order in which to add those options?
> 
> No matter which order I use for setting the optionsthey simple don't get
> set properly! Does it have anything to do with the following code in
> Zend_Form_Element::_loadFilter?
> 
>  if (empty($filter['options'])) {
> $instance = new $name;
> } else {
> $r = new ReflectionClass($name);
> if ($r->hasMethod('__construct')) {
> $instance = $r->newInstanceArgs((array) $filter['options']);
> } else {
> $instance = $r->newInstance();
> }
> }

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] Zend_Deprecation is ready for community review.

[Bill Karwin]

Tobias Gies wrote:
> 
> as we approach 2.0, we will have to think of a way to report deprecated
> class or method calls to the developer. 
> 

Does this really need a new component?  What's wrong with
trigger_error(E_USER_NOTICE)?  This seems a lot simpler and more concise.

It also satisfies your goal of eliminating the tedium of resolving one
exception at a time.  Notices are not fatal; you can get a bunch of them
during one execution.

People who want to filter out the notices can do: 
  error_reporting(error_reporting() & ~E_USER_NOTICE);
...either in their bootstrap or else in php.ini.

Regards,
Bill Karwin
-- 
View this message in context: 
http://www.nabble.com/Zend_Deprecation-is-ready-for-community-review.-tp18513175p18514041.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] in latest standard trunk: decorators seem to have escaped from their original logic.

[Codiac]

Matthew,

I have to retract my previous mail, stating the issue is resolved. I've
double checked and there's definitely something strange going on with adding
filters to elements using Zend_Config_Xml. Not sure what it is (probably me
again), so i need help.

I played around with setting different (very wrong) options for the
StripTags filter, so now I have the following in my config file:




StripTags





class





I used $form->getElement('body')->getFilter('StripTags')  to get the filter
from the element and used a simple print_r to check how it was setup:

Zend_Filter_StripTags Object([commentsAllowed] => [_tagsAllowed:protected]
=> Array([ => Array())
[_attributesAllowed:protected] => Array([class] => ))


???

When I use the following config of options:




StripTags



   




class





I get:

Zend_Filter_StripTags Object([commentsAllowed] => 1 [_tagsAllowed:protected]
=> Array([tag] => Array([] => ))

[_attributesAllowed:protected] => Array([] => ))

What the !@&$

Questions:
Do I need to add all options in the config file for a filter? Is there a
particular order in which to add those options?

No matter which order I use for setting the optionsthey simple don't get
set properly! Does it have anything to do with the following code in
Zend_Form_Element::_loadFilter?

 if (empty($filter['options'])) {
$instance = new $name;
} else {
$r = new ReflectionClass($name);
if ($r->hasMethod('__construct')) {
$instance = $r->newInstanceArgs((array) $filter['options']);
} else {
$instance = $r->newInstance();
}
}



Regards, TJ.
-- 
View this message in context: 
http://www.nabble.com/in-latest-standard-trunk%3A-decorators-seem-to-have-escaped-from-their-original-logic.-tp18441904p18513972.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] simple synchronization / transaction question

[Bill Karwin]

Bryce Lohr-2 wrote:
> 
> In this case, the easiest thing to do would probably be to cause the DB 
> to set an exclusive lock on the row with the counter at the time it 
> reads it. Then, your application can decide if it needs to decrement the 
> value, delete the row, or whatever, and do the appropriate write.
> 
> Example in MySQL/InnoDB using  SELECT ... FOR UPDATE
> 
> There's certainly a way to achieve the same effect in PostgreSQL...
> 

I agree with all that Bryce said in his posting.

For what it's worth, PostgreSQL supports the same syntax as MySQL in this
case:
  SELECT ... FOR UPDATE

(Support for FOR UPDATE clause in other database brands:
Oracle: yes; 
IBM DB2: yes; 
FireBird/InterBase: yes, but syntax is FOR UPDATE WITH LOCK;
MS SQL Server: no, but the UPDLOCK hint is similar; 
SQLite: no)

It _should_ also work to specify SERIALIZABLE isolation mode when you begin
your transaction.  However, the implementation of SERIALIZABLE is
nonstandard in both PostgreSQL and MySQL/InnoDB; you can't get a true
serializable transaction as specified in the SQL standard.

You might already know this, but it bears repeating that MySQL's MyISAM
storage engine doesn't support transactions at all, so neither the FOR
UPDATE clause nor the transaction isolation level will have any effect.

Zend_Db has no special API methods for FOR UPDATE or transaction isolation
levels.  You'll have to execute transaction commands as SQL statements and
bear in mind the database-specific behavior.

Fortunately, the FOR UPDATE clause appears at the end of a SELECT statement
in both MySQL and PostgreSQL.  So if you create a Zend_Db_Select query,
here's how you can render it to its string equivalent and append the clause:

  $select = $db->select()->from('tablename')->order('colname'); // for
example
  $sql = $select->__toString() . ' FOR UPDATE'; // notice the extra space
inside the quotes
  $stmt = $db->query($sql);

Note that this works only if you're executing SQL queries directly using the
database adapter's methods such as query() or fetchAll().  If you're using
Zend_Db_Table objects, it renders SELECT queries internally, so you don't
have an opportunity to append the FOR UPDATE clause in that case.  You can't
specify this clause for queries run by Zend_Db_Table objects (except if
you're willing to hack the internals of this class, and also
Zend_Db_Table_Row).

Regards,
Bill Karwin
-- 
View this message in context: 
http://www.nabble.com/simple-synchronization---transaction-question-tp18480201p18513715.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Recent Component Promotions

[Matthew Weier O'Phinney]

-- Todd Wolaver <[EMAIL PROTECTED]> wrote
(on Thursday, 17 July 2008, 11:17 AM -0500):
> I've been playing with the Dojo view helper and Zend_Dojo_Form it all  
> looks great and easy to implement.
>
> I did find a minor issue in the view helper related to adding module  
> paths.  The generated code doesn't include the path for the module  
> namespace.
>
> Valid Dojo syntax would be:
> dojo.registerModulePath("foo", "../../foo");
>
> Veiw helper outputs:
> dojo.registerModulePath("foo");
>
> I've updated the _renderExtras method in  
> Zend_Dojo_View_Helper_Dojo_Container to get it working for now.  I can  
> add a bug to the issue tracker if you like but I didn't see a category  
> for Zend_Dojo in there yet.

I've added a category for this now; please enter the issue, and, if
possible, attach the patch.

> As a side note on Zend_Dojo_Form, I'm having a hard time figuring out  
> how to get the checkboxes in MultiCheckbox to render as a Dijit  
> checkbox, any suggestions?

Hmm... I may need to add a MultiCheckBox dijit element. Place a feature
request in the tracker for this; I can see this being useful.


> On Jul 16, 2008, at 11:16 AM, Matthew Weier O'Phinney wrote:
>
>> Greetings, all --
>>
>> I've promoted the following components from standard/incubator/ to
>> standard/trunk/ in preparation for the 1.6.0 release:
>>
>>  * Zend_Dom_Query: use CSS selectors to query (X)HTML/XML documents
>>  * Zend_Dojo: ZF/Dojo integration layer
>>  * Zend_Json_Server: JSON-RPC implementation
>>  * Zend_Session_SaveHandler_DbTable: Store session data in a database
>>table
>>  * Zend_Test_PHPUnit: testing infrastructure for MVC applications
>>  * Zend_Text_Figlet: create Figlets with ZF
>>
>> If you haven't tried these new components out yet, please do. If you
>> haven't due to lack of documentation, documentation is available in  
>> the
>> documentation/manual/en/module_specs/ tree in human-readable DocBook,
>> with full PHP examples and use cases.
>>
>> A hearty thank you to all contributors and testers involved with  
>> making
>> these components a reality!
>>
>> -- 
>> Matthew Weier O'Phinney
>> Software Architect   | [EMAIL PROTECTED]
>> Zend Framework   | http://framework.zend.com/
>

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

[fw-general] Zend_Deprecation is ready for community review.

[Tobias Gies]

Hi list,

as we approach 2.0, we will have to think of a way to report deprecated
class or method calls to the developer. To help solve this issue, I created
the Zend_Deprecation proposal. It offers a static interface similar to PHP's
own error handling functionality and should therefore be easy to use for the
developer.

There is another way that we could use to report deprecations to the
developer, which is simply throwing a Zend_Deprecation_Exception. This would
leave the developer in charge about doing something with those exceptions,
and it would presumably lead to an annoying loop of "load page -> read
exception -> fix -> reload page -> read next exception...". To solve this,
Zend_Deprecation uses an error stack to report the errors to the developer
all at once.

You can find my proposal here:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Deprecation+-+Tobias+Gies

Best regards
Tobias

Re: [fw-general] Memory leak in Zend_Date?

[Ota Mares]

Lars Strojny wrote:

Hi Matthew,

Am Samstag, den 12.07.2008, 19:11 -0400 schrieb Matthew Weier O'Phinney:
[...]
  

Lars -- can you provide some benchmarks that show the memory differences
between Zend_Date and DateTime? I'm curious to see if we might be able
to isolate the performance issues, if any, and improve the situation.



You can find the results attached. The benchmark suite can be found at
http://lars.schokokeks.org/php/time-bench.phps

cu, Lars
  

Before the topic gets forgotten, ill add myself to the benchmark list.

SuSe Linux 10.0
Intel(R) Pentium(R) 4 CPU 3.00GHz  
MemTotal: 1025604 kB


Instanciating Zend_Date

  - Average memory usage: 84.604000
  - Overall memory usage: 84604.00
  - Average time consumed (mS): 0.001542
  - Overall time consumed: (mS): 1.542281

Instanciating DateTime
  - Average memory usage: -0.792000
  - Overall memory usage: -792.00
  - Average time consumed (mS): 0.16
  - Overall time consumed: (mS): 0.015954

Returning a formatted date with DateTime
  - Average memory usage: 0.224000
  - Overall memory usage: 224.00
  - Average time consumed (mS): 0.04
  - Overall time consumed: (mS): 0.003700

Returning a formatting date with with Zend_Date
  - Average memory usage: 0.06
  - Overall memory usage: 60.00
  - Average time consumed (mS): 0.000663
  - Overall time consumed: (mS): 0.663352

Re: [fw-general] Recent Component Promotions

[Todd Wolaver]

Hi Matthew,

Thanks for all the hard and long work on the Dojo implementation!

I've been playing with the Dojo view helper and Zend_Dojo_Form it all  
looks great and easy to implement.


I did find a minor issue in the view helper related to adding module  
paths.  The generated code doesn't include the path for the module  
namespace.


Valid Dojo syntax would be:
dojo.registerModulePath("foo", "../../foo");

Veiw helper outputs:
dojo.registerModulePath("foo");

I've updated the _renderExtras method in  
Zend_Dojo_View_Helper_Dojo_Container to get it working for now.  I can  
add a bug to the issue tracker if you like but I didn't see a category  
for Zend_Dojo in there yet.


As a side note on Zend_Dojo_Form, I'm having a hard time figuring out  
how to get the checkboxes in MultiCheckbox to render as a Dijit  
checkbox, any suggestions?


Thanks again for a great component.
Todd


On Jul 16, 2008, at 11:16 AM, Matthew Weier O'Phinney wrote:


Greetings, all --

I've promoted the following components from standard/incubator/ to
standard/trunk/ in preparation for the 1.6.0 release:

 * Zend_Dom_Query: use CSS selectors to query (X)HTML/XML documents
 * Zend_Dojo: ZF/Dojo integration layer
 * Zend_Json_Server: JSON-RPC implementation
 * Zend_Session_SaveHandler_DbTable: Store session data in a database
   table
 * Zend_Test_PHPUnit: testing infrastructure for MVC applications
 * Zend_Text_Figlet: create Figlets with ZF

If you haven't tried these new components out yet, please do. If you
haven't due to lack of documentation, documentation is available in  
the

documentation/manual/en/module_specs/ tree in human-readable DocBook,
with full PHP examples and use cases.

A hearty thank you to all contributors and testers involved with  
making

these components a reality!

--
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] Zend_View_Helper_Jquery - Ready for Review

[Matthew Weier O'Phinney]

-- Jake McGraw <[EMAIL PROTECTED]> wrote
(on Thursday, 17 July 2008, 11:58 AM -0400):
> Page not found:
> 
> 
> http://framework.zend.com/wiki/display/ZFPROP/
> Zend_View_Helper_Jquery+-+Benjamin+Eberlei

Use this link:

http://framework.zend.com/wiki/x/AQFO

which won't change even if the page name changes again.


> On Thu, Jul 17, 2008 at 11:41 AM, Juan Felipe Alvarez Saldarriaga <
> [EMAIL PROTECTED]> wrote:
> 
> Great news! :D
> 
> Like Matthew say, don't care wich JS framework you use if you can use it
> via Zend Framework! :D :D, I think most important is bring Zend Framework
> more options.
> 
> Thx for the news!.
> 
> - Original Message -
> From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>
> To: fw-general@lists.zend.com
> Sent: Tuesday, July 15, 2008 6:21:08 AM GMT -05:00 Columbia
> Subject: Re: [fw-general] Zend_View_Helper_Jquery - Ready for Review
> 
> -- Cristian Bichis <[EMAIL PROTECTED]> wrote
> (on Tuesday, 15 July 2008, 08:52 AM +0300):
> > A very good idea, since jQuery is probably the most used JS
> > library/framewok.
> 
> Just a note: let's keep comments like the above out of the discussions.
> JS library choice is practically a religious topic, and everybody has
> their favorite and their opinions. Let's focus on implementation and
> requirements in the discussions.
> 
> BTW, Benjamin, I've commented on the proposal.
> 
> > > i wanted to let you know that my Zend_View_Helper_Jquery proposal is
> > > ready for review:
> > >
> > > http://framework.zend.com/wiki/display/ZFPROP/
> Zend_View_Helper_Jquery+-+Benjamin+Eberlei
> > >
> > > Please discuss. Important discussion for the beginning are the
> > > concerns/problems I raised in the first comment of that proposal
> > > regarding jQuery plugin architecture. I would appreciate every bit of
> > > input on this issue (and the component overall of course).
> 
> --
> Matthew Weier O'Phinney
> Software Architect   | [EMAIL PROTECTED]
> Zend Framework   | http://framework.zend.com/
> 
> 

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

Re: [fw-general] Zend_View_Helper_Jquery - Ready fo r Review

[Benjamin Eberlei]

Due to renaming issue (ZendX Package and own namespace) it changed to:

http://framework.zend.com/wiki/display/ZFPROP/ZendX_JQuery_View_Helper_JQuery+-+Benjamin+Eberlei

Sorry

On Thu, 17 Jul 2008 11:58:08 -0400, "Jake McGraw" <[EMAIL PROTECTED]>
wrote:
> Page not found:
> 
>
http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_Jquery+-+Benjamin+Eberlei
> 
> - jake
> 
> 
> On Thu, Jul 17, 2008 at 11:41 AM, Juan Felipe Alvarez Saldarriaga <
> [EMAIL PROTECTED]> wrote:
> 
>> Great news! :D
>>
>> Like Matthew say, don't care wich JS framework you use if you can use it
>> via Zend Framework! :D :D, I think most important is bring Zend
> Framework
>> more options.
>>
>> Thx for the news!.
>>
>> - Original Message -
>> From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>
>> To: fw-general@lists.zend.com
>> Sent: Tuesday, July 15, 2008 6:21:08 AM GMT -05:00 Columbia
>> Subject: Re: [fw-general] Zend_View_Helper_Jquery - Ready for Review
>>
>> -- Cristian Bichis <[EMAIL PROTECTED]> wrote
>> (on Tuesday, 15 July 2008, 08:52 AM +0300):
>> > A very good idea, since jQuery is probably the most used JS
>> > library/framewok.
>>
>> Just a note: let's keep comments like the above out of the discussions.
>> JS library choice is practically a religious topic, and everybody has
>> their favorite and their opinions. Let's focus on implementation and
>> requirements in the discussions.
>>
>> BTW, Benjamin, I've commented on the proposal.
>>
>> > > i wanted to let you know that my Zend_View_Helper_Jquery proposal is
>> > > ready for review:
>> > >
>> > >
>>
>
http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_Jquery+-+Benjamin+Eberlei
>> > >
>> > > Please discuss. Important discussion for the beginning are the
>> > > concerns/problems I raised in the first comment of that proposal
>> > > regarding jQuery plugin architecture. I would appreciate every bit
> of
>> > > input on this issue (and the component overall of course).
>>
>> --
>> Matthew Weier O'Phinney
>> Software Architect   | [EMAIL PROTECTED]
>> Zend Framework   | http://framework.zend.com/
>>

Re: [fw-general] Zend_View_Helper_Jquery - Ready for Review

[Jake McGraw]

Page not found:

http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_Jquery+-+Benjamin+Eberlei

- jake


On Thu, Jul 17, 2008 at 11:41 AM, Juan Felipe Alvarez Saldarriaga <
[EMAIL PROTECTED]> wrote:

> Great news! :D
>
> Like Matthew say, don't care wich JS framework you use if you can use it
> via Zend Framework! :D :D, I think most important is bring Zend Framework
> more options.
>
> Thx for the news!.
>
> - Original Message -
> From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>
> To: fw-general@lists.zend.com
> Sent: Tuesday, July 15, 2008 6:21:08 AM GMT -05:00 Columbia
> Subject: Re: [fw-general] Zend_View_Helper_Jquery - Ready for Review
>
> -- Cristian Bichis <[EMAIL PROTECTED]> wrote
> (on Tuesday, 15 July 2008, 08:52 AM +0300):
> > A very good idea, since jQuery is probably the most used JS
> > library/framewok.
>
> Just a note: let's keep comments like the above out of the discussions.
> JS library choice is practically a religious topic, and everybody has
> their favorite and their opinions. Let's focus on implementation and
> requirements in the discussions.
>
> BTW, Benjamin, I've commented on the proposal.
>
> > > i wanted to let you know that my Zend_View_Helper_Jquery proposal is
> > > ready for review:
> > >
> > >
> http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_Jquery+-+Benjamin+Eberlei
> > >
> > > Please discuss. Important discussion for the beginning are the
> > > concerns/problems I raised in the first comment of that proposal
> > > regarding jQuery plugin architecture. I would appreciate every bit of
> > > input on this issue (and the component overall of course).
>
> --
> Matthew Weier O'Phinney
> Software Architect   | [EMAIL PROTECTED]
> Zend Framework   | http://framework.zend.com/
>

Re: [fw-general] Zend_View_Helper_Jquery - Ready for Review

[Juan Felipe Alvarez Saldarriaga]

Great news! :D

Like Matthew say, don't care wich JS framework you use if you can use it via 
Zend Framework! :D :D, I think most important is bring Zend Framework more 
options.

Thx for the news!.

- Original Message -
From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>
To: fw-general@lists.zend.com
Sent: Tuesday, July 15, 2008 6:21:08 AM GMT -05:00 Columbia
Subject: Re: [fw-general] Zend_View_Helper_Jquery - Ready for Review

-- Cristian Bichis <[EMAIL PROTECTED]> wrote
(on Tuesday, 15 July 2008, 08:52 AM +0300):
> A very good idea, since jQuery is probably the most used JS  
> library/framewok.

Just a note: let's keep comments like the above out of the discussions.
JS library choice is practically a religious topic, and everybody has
their favorite and their opinions. Let's focus on implementation and
requirements in the discussions.

BTW, Benjamin, I've commented on the proposal.

> > i wanted to let you know that my Zend_View_Helper_Jquery proposal is 
> > ready for review:
> >
> > http://framework.zend.com/wiki/display/ZFPROP/Zend_View_Helper_Jquery+-+Benjamin+Eberlei
> >
> > Please discuss. Important discussion for the beginning are the  
> > concerns/problems I raised in the first comment of that proposal 
> > regarding jQuery plugin architecture. I would appreciate every bit of 
> > input on this issue (and the component overall of course).

-- 
Matthew Weier O'Phinney
Software Architect   | [EMAIL PROTECTED]
Zend Framework   | http://framework.zend.com/

RE: [fw-general] Re: Re[fw-general] direct Question

[Robert Castley]

I am successfully using $this->_helper->url in my controller but it's syntax
seems to differ from the view version. 

In a view I can do: 

$this->url(array('pageTitle'=> $this->title, 'groupKey' => $this->groupKey),
'view'); 

If I try this in a controller e.g. 

$this->_helper->url(array('pageTitle'=> $this->title, 'groupKey' =>
$this->groupKey), 'view'); 

I get the following: 

/view/Array in my view 

The only way I can get it to work is by doing: 

echo $this->_helper->url($this->title, this->groupKey, 'view'); 

Is this correct? 

Cheers, 
- Robert 


-Original Message- 
From: Matthew Weier O'Phinney [mailto:[EMAIL PROTECTED]
 ] 
Sent: 08 July 2008 17:51 
To: fw-general@lists.zend.com 
Subject: Re: [fw-general] Re: Re[fw-general] direct Question 

-- Robert Castley <[EMAIL PROTECTED]> wrote (on Tuesday, 08 July
2008, 05:05 PM +0100): 
> I am having a similar problem.  In my controller I would like to specify a
URL. 
> 
> Currently I am using: $this->view->saveUrl = $this->_baseUrl . '/save/' . 
> $this->_groupKey . '/' . $this->_pageTitle; 
> 
> I tried the redirector approach but obviously that redirects straight
away. 
> 
> Is there another method to build up urls in the controller.  Much akin 
> to the $this->url in the view. 

Yes -- there is a url() action helper that works just like its cousin in the
view helpers: 

$this->view->saveUrl = $this->_helper->url(...); 


> -Original Message- 
> From: Matthew Weier O'Phinney [mailto:[EMAIL PROTECTED]
 ] 
> Sent: 08 July 2008 16:18 
> To: fw-general@lists.zend.com 
> Subject: Re: [fw-general] Re: Re[fw-general] direct Question 
> 
> -- monk.e.boy <[EMAIL PROTECTED]> wrote (on Tuesday, 08 July 
> 2008, 
> 07:36 AM -0700): 
> > Matthew Weier O'Phinney-3 wrote: 
> > > 
> > > 
> > > Use the redirector instead of constructing the URL yourself: 
> > > 
> > > $this->_helper->redirector('project'); 
> > > 
> > > This will do the same as what you were trying to accomplish before. 
> > > -- 
> > > Matthew Weier O'Phinney 
> > > 
> > > 
> > 
> > Matt, 
> > 
> >   Thanks for the promp reply! 
> > 
> >   Does the redirector act like the URL constructor? My URL looks like
this: 
> > 
> >   /base/application/report/customer/33/project/12/report/99/ 
> > 
> > Doing this: 
> >   $this->_helper->redirector('report') 
> > 
> > takes me to: 
> >   /base/application/report/ 
> > 
> > How do you suggest I build and pass the URL above to the redirector? 
> 
> If you want to do url()-like redirection, use the gotoRoute() method 
> of the 
> redirector: 
> 
> $this->_helper->redirector->gotoRoute(array('action' => 
> 'project')); 
> 
> It takes the same arguments as the url() view helper, and builds using 
> the same mechanisms. 
> 
> > At the 
> > moment I do a lot of: 
> > 
> > '/base/application/report/customer/'. $this->_getParam( 'customer' )
.'/'. 
> > $this->_getParam( 'project' ) .'/report/'. $this->_getParam( 'report' 
> > ) 
> > 
> > which makes me feel icky :-( 
> 
> -- 
> Matthew Weier O'Phinney 
> Software Architect   | [EMAIL PROTECTED] 
> Zend Framework   | http://framework.zend.com/
  
> 
> __ 
> __ This email has been scanned for all known viruses by the 
> MessageLabs Email Security Service and the Macro 4 plc internal virus 
> protection system. 
> 
> __ 
> __ 
> 
> 
> __ 
> __ This email has been scanned for all known viruses by the 
> MessageLabs Email Security Service and the Macro 4 plc internal virus 
> protection system. 
> __ 
> __ 

-- 
Matthew Weier O'Phinney 
Software Architect   | [EMAIL PROTECTED] 
Zend Framework   | http://framework.zend.com/
  

 
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.

 



This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.



This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 plc internal virus protection system.





This email has been scanned for a

Re: [fw-general] in latest standard trunk: decorators seem to have escaped from their original logic.

[Bart McLeod]

Hi Matthew,

Sorry for my late reply, I am under a lot of pressure for a deadline.

You fixed it! :-)   
And a few other things along the way.


First result of the update was an error, due to some corrected (!) behavior:
*Fatal error*: Uncaught exception 'Zend_Loader_PluginLoader_Exception' 
with message 'File CmsScripts.php was loaded but class named 
Admin_View_Helper_CmsScripts was not found within it.' in 
D:\ZendFramework\library\Zend\Loader\PluginLoader.php:351 Stack trace: 
#0 D:\ZendFramework\library\Zend\View\Abstract.php(1114): 
Zend_Loader_PluginLoader->load('CmsScripts') #1 
D:\ZendFramework\library\Zend\View\Abstract.php(545): 
Zend_View_Abstract->_getPlugin('helper', 'cmsScripts') #2 
D:\ZendFramework\library\Zend\View\Abstract.php(312): 
Zend_View_Abstract->getHelper('cmsScripts') #3 [internal function]: 
Zend_View_Abstract->__call('cmsScripts', Array) #4 
D:\werkmap\www.mrvane.com 
zf\application\admin\controllers\ItemsController.php(20): 
Zend_View->cmsScripts() #5 
D:\ZendFramework\library\Zend\Controller\Action.php(129): 
Admin_ItemsController->init() #6 
D:\ZendFramework\library\Zend\Controller\Dispatcher\Standard.php(269): 
Zend_Controller_Action->__construct(Object(Zend_Controller_Request_Http), 
Object(Zend_Controller_Response_Http), A in 
*D:\ZendFramework\library\Zend\Loader\PluginLoader.php* on line *351


*But I know how to fix this one!, I named it Zend_View_Helper_etc., so 
just have to rename to Admin_View_Helper...and a few others too


Bart McLeod

Matthew Weier O'Phinney schreef:

-- Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote
(on Monday, 14 July 2008, 08:54 AM -0400):
  

-- Bart McLeod <[EMAIL PROTECTED]> wrote
(on Monday, 14 July 2008, 02:07 PM +0200):


another addition:
The problem is in the new getDecorator function. If you call it, it  
'lazyloads' the decorator, but puts it at the end of the stack. See this  
output, where I var_dumped the decorators inside the lazy load function,  
before and after getting the decorator 'td':
In the first array of 7 decorators, td is between errors and tr, where  
it should be. In the second array, it comes after table, effectively  
breaking the rendering chain.
  

Ah, okay -- I see what's happening, and it's a use case which didn't
have a test. I'll work on correcting it in the next 1-2 days.

As an explanationg, a little over a week ago, I refactored Zend_Form,
Zend_Form_DisplayGroup, and Zend_Form_Element to use lazy loading. This
was done for two reasons: a) to reduce overhead when plugins of a
certain type are never invoked, and b) to make it easier to set plugin
prefix paths at any given point in time, and have them affect previously
set plugins. (b) was partly to address Dojo and other JS library
integration.

Obviously, this has evidently created an issue of ordering plugins when
an individual plugin is fetched before others have been instantiated.
I'll write a test for this use case so that I can correct it in the next
couple of days so that it can get into the 1.6 release.



I've written tests to cover this situation, and updated the code to
ensure that plugin order is retained during lazy loading. Please test
and confirm!

  

Re: [fw-general] simple synchronization / transaction question

[Bryce Lohr]

Hi Dietrich,

Dietrich Bollmann wrote:

As this should be a very common situation (different users accessing and
manipulating the same data) I thought there should be a simple
solution :)
  


What you're describing is, in fact, a very common situation. However, 
concurrency issues in general are among the most difficult to deal with. 
There isn't a really "simple" solution in ZF or elsewhere, to my knowledge.


In this case, the easiest thing to do would probably be to cause the DB 
to set an exclusive lock on the row with the counter at the time it 
reads it. Then, your application can decide if it needs to decrement the 
value, delete the row, or whatever, and do the appropriate write.


I have a situation similar to yours in my application: users can put in 
applications in a number of different categories, but each category has 
a specific limit it can take. So the limit counter is decremented each 
time an application is accepted, or a demand tracking record is written 
if the category is full.


In MySQL/InnoDB, I do essentially this:

beginTransaction();
SELECT (counter > 0) as isOpen FROM categories WHERE id = ? FOR UPDATE
if ($isOpen) {
   INSERT INTO applications (...) VALUES (...)
   UPDATE categories SET counter = counter - 1 WHERE id = ?
} else {
   INSERT INTO demand_tracking (...) VALUES (...)
}
commit();

In MySQL/InnoDB, the "FOR UPDATE" on the select sets an exclusive lock 
on all the rows matching the query. Thus, any other transaction that 
wants to write to that row must wait for the lock to be released (when 
the current transaction ends), so the counter value cannot be changed by 
another transaction between the first select and the commit. At the same 
time, the exclusive lock prevents other transactions from reading the 
counter. This is lowers concurrency, but increases safety since multiple 
transactions don't see the same value of the counter and try to insert 
more applications.


There's certainly a way to achieve the same effect in PostgreSQL, but I 
don't remember what it is off the top of my head (maybe "SERIALIZABLE" 
transaction isolation level is sufficient?). You should be able to find 
the answer in the Postgres docs.


Hope this helps,
Bryce Lohr

Re: [fw-general] Problem with Zend_Mail using smtp and attachments

[Dermot Buckley]

On 16 Jul 2008, at 12:36, Dermot Buckley wrote:



We get the following warning:

PHP Warning:  Zend_Mail_Protocol_Abstract::require_once(Zend/Mail/ 
Protocol/Exception.php) [function.Zend-Mail-Protocol-Abstract-require- 
once]: failed to open stream: No such file or directory in / 
Library/WebServer/Documents/CBDB/library/Zend/Mail/Protocol/ 
Abstract.php on line 275


followed by ...

PHP Fatal error:  Zend_Mail_Protocol_Abstract::require_once() [href='function.require'>function.require]: Failed opening  
required 'Zend/Mail/Protocol/Exception.php' (include_path='.:../ 
library:../application/models:../incubator/library:.:../library')  
in /Library/WebServer/Documents/CBDB/library/Zend/Mail/Protocol/ 
Abstract.php on line 275




Just for the sake of completeness, I'll post the resolution to this  
problem:



For reasons as yet unknown (to me at least), the working directory for  
php changes during object destruction (at least on several of our  
servers here).  A side effect of this is that if you're using relative  
paths in the include path, dynamic loading of php files will fail  
during __destruct calls.


So the fix for me was to change the include path entries to absolute  
paths.  The exception is still thrown in  
Zend_Mail_Protocol_Smtp::quit(), but it is caught and ignored as was  
intended.



Hopefully this will be of help to someone in the future, it cost me  
nearly a day to find.



Dermot.

Re: [fw-general] Recent Component Promotions

[Carlton Gibson]

On 16 Jul 2008, at 20:26, Matthew Weier O'Phinney wrote:

No proposal documentation? Not that I don't mind digging elbow  
deep into new
code, just thought there would be a little hand holding in the  
work leading up

to the move to an officially sanctioned Zend Component.


There's documentation in the repository, and it's human-readable:

http://framework.zend.com/svn/framework/standard/documentation/ 
manual/en/module_specs/


look for Zend_Dom*.xml (or Zend_Dojo*.xml, or Zend_Test*.xml, etc.).


You can build to HTML documentation yourself.

Navigate to the language subfolder you're after, e.g. documentation/ 
manual/en and run

$ autoconf
$ ./configure
$ make

(This is in the README)

Come back in a while and the html folder will contain your docs.

When you want to update the documentation simply run
$ make clean && make html

Regards
Carlton