[fw-general] Zend Config Writer and constants.
Zend Framework version 1.7.4.
PHP version 5.2.4 (ubuntu hardy 8.04 pkg)
Hi all,
When updating a configuration file via Zend_Config_Writer_Ini, I
noticed that constants defined in the configuration would get wrapped
in quotation marks (or converted to the value of the constant if not
passed), effectively negating the intent.
From Zend_Config_Writer_Ini:
protected function _prepareValue($value)
{
if (is_integer($value) || is_float($value)) {
return $value;
} elseif (is_bool($value)) {
return ($value ? 'true' : 'false');
} else {
return '' . addslashes($value) . '';
}
}
Adding a elseif stanza to check for defined($value) doesn't appear to
work in my case as I get a fatal error stating:
PHP Fatal error: Class 'Zivios ' not found in
/opt/zivios/zivios-panel/application/library/Zend/Config/Writer/Ini.php
on line 201, referer: https://master.zivios.net/
I am not at all sure what is causing this. The constant in my case is
not Zivios at all, but 'ZVERSION', which holds the version of the
application and is in-turn used to derive certain paths. The reasoning
here is that application level updates would not clobber generated
configuration files.
I could of course work around this by not housing constants in the
configuration, though I am guessing this requirement should be
considered (if possible).
If I can provide additional details, please feel free to ask.
Thank you,
Mustafa.
Re: [fw-general] Issue with nested border containers content panes in dojo tab containers.
On Wed, Feb 4, 2009 at 11:01 AM, Mustafa A. Hashmi mahas...@gmail.com wrote:
On Wed, Feb 4, 2009 at 12:04 AM, Matthew Weier O'Phinney
matt...@zend.com wrote:
-- Mustafa A. Hashmi mahas...@gmail.com wrote
(on Tuesday, 03 February 2009, 11:58 PM +0500):
I seem to have hit a strange issue with content panes in tab
containers. To ensure the issue is indeed with ZF, or at least my
implementation of ZF based tab containers and content panes, I tested
dojo's functionality independently and verified that it was working as
*snip*
Can someone please confirm or deny this? I can pastebin the ZF code if
required as well.
Actually, I've run into this using regular dojo markup not generated via
ZF as well -- it's not specific to ZF generated code. I have it solved
on one project right now, but have no concrete idea how I got it to
work.
Will revert back to the list if I come up with any answers.
The only working solution we found was introducing a destroy function
in dijit.layout.ContentPane.js. Obviously this is not ideal, however,
works quite well.
destroy: function() {
// summary:
// adding destory to contentpane.
dojo.forEach(this.getDescendants(), function(widget){
widget.destroyRecursive();
});
this.inherited(arguments);
},
Regards,
Mustafa.
[fw-general] Issue with nested border containers content panes in dojo tab containers.
Hi all,
I seem to have hit a strange issue with content panes in tab
containers. To ensure the issue is indeed with ZF, or at least my
implementation of ZF based tab containers and content panes, I tested
dojo's functionality independently and verified that it was working as
intended.
The working example:
When a tab container is closed, all widgets inside the tab container
get destroyed by default. A very simple implementation:
http://www.pastebin.ca/1326335 - the index page.
http://www.pastebin.ca/1326340 - the href target for the tab.
This works as expected and I verified that the widget ids are indeed
destroyed when the tab is closed. A simple way to check this is to
simply: javascript:alert(dijit.byId('tabid')); in the browser url
input area. Doing so before the tab is close shows the widget ID,
wherein closing the tab destroys all widgets within.
The issue:
When using tab containers which are rendered via
$view-tabContainer(..) however, closing the tab does not destory
nested widget ids. I can paste a code example of this if requested,
though it's quite simple to put together. In a nutshell:
Create a tab with a static ID. Within the tab, open a border container
which consists of a additional content panes. Close the tab and open
it again. I seem to get a widget id collision here. I am using
declarative mark up for dojo and have tried overriding the destroy
function with a call to destoryDescendants() . I also tried doing a
dojo.connect to onClose and passing the tab id and calling
destroyDescendants(), however the widget ID is still available,
whereas the tab has been destroyed.
Can someone please confirm or deny this? I can pastebin the ZF code if
required as well.
Many thanks,
Mustafa.
Re: [fw-general] Issue with nested border containers content panes in dojo tab containers.
On Wed, Feb 4, 2009 at 12:04 AM, Matthew Weier O'Phinney matt...@zend.com wrote: -- Mustafa A. Hashmi mahas...@gmail.com wrote (on Tuesday, 03 February 2009, 11:58 PM +0500): I seem to have hit a strange issue with content panes in tab containers. To ensure the issue is indeed with ZF, or at least my implementation of ZF based tab containers and content panes, I tested dojo's functionality independently and verified that it was working as *snip* Can someone please confirm or deny this? I can pastebin the ZF code if required as well. Actually, I've run into this using regular dojo markup not generated via ZF as well -- it's not specific to ZF generated code. I have it solved on one project right now, but have no concrete idea how I got it to work. Will revert back to the list if I come up with any answers. Cheers, Mustafa.
Re: [fw-general] Question regarding dojo forms rendered in templates called via xhr.
On Thu, Jan 8, 2009 at 5:50 PM, Matthew Weier O'Phinney
matt...@zend.com wrote:
On Thursday 08 January 2009 12:22:31 Mustafa A. Hashmi wrote:
I am in the process of switching our application to make use of dojo
forms, however, am having some issues with forms which are rendered
via xhr requests. In a nutshell:
a) Layout is rendered and the index action renders a dojo form which
works perfectly fine.
b) After submitting the form, the user manually follows a link which
calls a JS function and loads the required action template in a
specified div.
c) The loaded dojo form in the resulting div however doesn't seem to
be 'dojo enabled'. The form does render, albeit without any styles or
dijit functionality.
When using XHR to retrieve (X)HTML content that will be injected into
the DOM, you need to do two things:
1) Any dojo modules that the new content uses must already be loaded
(i.e., the dojo.require calls should already have occurred).
Because of how Zend_Dojo works, anything aggregated in the dojo
view helper will not be sent in the payload (unless you explicitly
include it). Additionally, HTML content pulled by XHR ignores any
scripts attached -- which means even if you did return the dojo
view helper payload, it wouldn't be executed. So your initial
payload must have all the requisite dojo.require statements.
As you demonstrate in your pastebin app, I too am gearing the app for
a light js library build, hence all required modules that the app
needs are specified explicitly for loading. The front controller is
initialized with the installer module plugin which instantiates the
view and sets required modules / paths / view helpers, etc.
dojo.provide(installer.layer);
(function() {
dojo.require(dijit.layout.ContentPane);
dojo.require(dijit.layout.BorderContainer);
...
For this reason, it's also best to turn on declarative markup for
any XHR payloads -- since the programmatic elements will not be
present. You can do this with the following:
Zend_Dojo_View_Helper_Dojo::setUseDeclarative(true);
Also done during front controller initialization of the view obj.
2) You need to run the dojo parser over the returned content. If
you're pulling the content into a ContentPane, you can do this by
setting the parseOnLoad property of that pane to true. Otherwise,
make sure you have the dojo.parser module loaded, and call:
dojo.parser.parse(dom node containing retrieved content);
I was doing every one of the things you recommended, barring the
dojo.parser.parse bit. Once the response is injected into the relevant
dom node, I simply ran the parser over said node and everything came
alive.
Thank you Matthew, much appreciated!
--
Mustafa A. Hashmi
[fw-general] Question regarding dojo forms rendered in templates called via xhr.
Hi all, I am in the process of switching our application to make use of dojo forms, however, am having some issues with forms which are rendered via xhr requests. In a nutshell: a) Layout is rendered and the index action renders a dojo form which works perfectly fine. b) After submitting the form, the user manually follows a link which calls a JS function and loads the required action template in a specified div. c) The loaded dojo form in the resulting div however doesn't seem to be 'dojo enabled'. The form does render, albeit without any styles or dijit functionality. Please note: initialization of application is based on Matthew Weier O'Phinney's excellent pastebin app. I pasted the relevant sections @: http://www.pastebin.ca/1303381 The entire application source can be viewed at: http://bazaar.launchpad.net/~mhashmi/zivios/devel/files (please see the 'installer' module). Also: I had made quite a few attempts to selectively load the required dojo modules (with dojo.addOnLoad), but for some reason I am not getting it right. I am also confused about setting dojo to declarative mode in the view template when we have already done so in the predispatch action... Any help would be much appreciated. Thanks, -- Mustafa A. Hashmi
Re: [fw-general] Question regarding dojo forms rendered in templates called via xhr.
On Thu, Jan 8, 2009 at 4:25 PM, Benjamin Eberlei kont...@beberlei.de wrote: that is a javascript specific problem. If you load stuff via XHR you have to reattach all the events to it, because they have not been registered. all the content inside the loaded div has not been dojo eventized lets call it, so no javascript is happening there. you have to reattach all events to that specific elements. Many thanks for the speedy response. I actually did try the addOnLoad calls and requireModule calls from within the template, however, I am obviously missing more of the required glue. Will try again and share my attempts if I can't go further. Also: noticed that pastebin is up to 1.3.0 (i was referencing 1.0.0), so will look there for pointers as well. Thanks again. On Thursday 08 January 2009 12:22:31 Mustafa A. Hashmi wrote: Hi all, I am in the process of switching our application to make use of dojo forms, however, am having some issues with forms which are rendered via xhr requests. In a nutshell: a) Layout is rendered and the index action renders a dojo form which works perfectly fine. b) After submitting the form, the user manually follows a link which calls a JS function and loads the required action template in a specified div. c) The loaded dojo form in the resulting div however doesn't seem to be 'dojo enabled'. The form does render, albeit without any styles or dijit functionality. Please note: initialization of application is based on Matthew Weier O'Phinney's excellent pastebin app. I pasted the relevant sections @: http://www.pastebin.ca/1303381 The entire application source can be viewed at: http://bazaar.launchpad.net/~mhashmi/zivios/devel/files (please see the 'installer' module). Also: I had made quite a few attempts to selectively load the required dojo modules (with dojo.addOnLoad), but for some reason I am not getting it right. I am also confused about setting dojo to declarative mode in the view template when we have already done so in the predispatch action... Any help would be much appreciated. Thanks, -- Mustafa A. Hashmi -- Benjamin Eberlei http://www.beberlei.de
