Re: [fw-general] New Zend_Wildfire_FirebugLogWriter component now in standard incubator
FirePHP also offers a LogWriter for Zend Framework - looks a bit
useless to me.
This is the FirePHP Log Writer (the one you are referring to was a
prototype).
The component has been named Zend_Wildfire_FirebugLogWriter to make it
clear that it logs messages to Firebug.
There will be other components in the Zend_Wildfire namespace that will
enhance the integration with FirePHP as well as other client extensions.
The namespace represents the name of a project aimed at developing some
standard communication channels between server and client code. It will
also provide a plugin system to allow server code to control code in
client extensions. FirePHP will migrate its own protocol to this
communication layer and will become a plugin to the Wildfire system.
I am working on more detailed information about Wildfire which will be
posted at http://www.wildfirehq.org/ as it becomes available.
Christoph
On Wed, Jul 23, 2008 at 8:29 PM, Christoph Dorn
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
There is a new component called Zend_Wildfire_FirebugLogWriter in the
standard incubator.
Proposal:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Wildfire_FirebugLogWriter+-+Christoph+Dorn
The Zend_Wildfire namespace belongs to the http://www.wildfirehq.org/
project. There will be more information available about this
project soon.
The Zend_Wildfire_FirebugLogWriter component allows you to send
logging
messages to the Firebug Console. The initialization is very simple if
using Zend_Controller_Front (it can also be used without the front
controller - see documentation).
/**
* Place this in your bootstrap file
*/
$writer = new Zend_Wildfire_FirebugLogWriter();
$logger = new Zend_Log($writer);
/**
* Use this in your model, view and controller files
*/
$logger-log('This is a log message!', Zend_Log::INFO);
Please see the documentation for more options and examples.
There is also a demo application in the incubator.
You will need FirePHP version 0.1.0.5 http://0.1.0.5/ or better
(http://www.firephp.org/). The 0.1.0.5 http://0.1.0.5/ FirePHP
client extension will be
promoted to 0.1.1 later this week.
Please take a look at this component and provide your feedback.
I am hoping that it can make it into the 1.6 RC2.
Looking forward to your feedback.
Christoph
Re: [fw-general] Zend Framework 1.6 Release Candidate 1 now available!
Matthew Weier O'Phinney-3 wrote: You appear to have marked it as resolved without anyone actually applying the patch. :) What was I supposed to do ? Leave it as open ? I could not find clear how-to on this subject. Matthew Weier O'Phinney-3 wrote: I'm scheduling it for next minor release. Thank you for your help Matthew. -- View this message in context: http://www.nabble.com/Zend-Framework-1.6-Release-Candidate-1-now-available%21-tp18587079p18626941.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
Hi all, I'm just downloaded the 1.6 RC1 release to give it a try. I've just one trouble : no projects are running now. The worst there's no errors just a blank page. (All demo previously used have the same symptom ) I could imagine there's some changes, but there's no documentation about what a dev need to adapt inside projects to have them running. Or did I miss it ( there's could be a improvement like a update.txt file at the root of library ) ? PS : In documentation there chapter missing in the index ( 18 doesn't have title GDATA, 23 is not write and so ... ) -- Bruno Friedmann
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
On Thu, Jul 24, 2008 at 4:31 AM, Bruno Friedmann [EMAIL PROTECTED] wrote: Hi all, I'm just downloaded the 1.6 RC1 release to give it a try. I've just one trouble : no projects are running now. The worst there's no errors just a blank page. (All demo previously used have the same symptom ) I could imagine there's some changes, but there's no documentation about what a dev need to adapt inside projects to have them running. Or did I miss it ( there's could be a improvement like a update.txt file at the root of library ) ? PS : In documentation there chapter missing in the index ( 18 doesn't have title GDATA, 23 is not write and so ... ) You probably want to enable: log_errors = On error_log = /path/to/a/writable/log/file Or maybe it is already enabled and you just need to check it out. To find out, do a phpinfo() and look for the above options. Till
Re: [fw-general] Error in Zend Framework 1.6 RC1 ?
I have same problem and I'll try to explain it a bit more
Exception: File ActionUri.php was loaded but class named
Admin_View_Helper_ActionUri was not found within it.
I setup my view in controller plugin in dispatchLoopStartup() and I add
Helper path and prefix of my class -
$viewRenderer-view-addHelperPath('../application/views/helpers',
'Dhi_View_Helper');
However when I use it in any module it will load right file but it will try
to look for class prefix : $moduleName . 'View_Helper. So in a way all my
global view helpers are useless in modules , unless I extend each of them
with module named class form (like Admin_View_Helper_ActionUri).
I was checking what classes did zf loader look for and there were three
class names. One was default ZF naming, second was the one I added with
addHelperPath() and the thrid was this MODULE based. It starts looking first
for module named class and since it loaded right file but could find the
class it stopped there.
Hope this helps.
Matthew Weier O'Phinney-3 wrote:
-- Endijs Lisovskis [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 03:25 PM -0700):
First off, in 1.6, we refactored the code in Zend_View to utilize the
PluginLoader -- no reason to have code duplication. :)
Most likely, what's happening is that you've got an invalid helper
prefix registered; why it was not throwing an error before is the new
question.
Several qustions:
* How are you setting up your views?
* How are you adding the Rn_View_Helper prefix to the view object?
* Is 'Rn' a module? or a private library namespace?
* Can you confirm that the file LoggedInuser.php exists on the helper
path? If so, what class is in it?
Answer those questions, and I may have a better idea of how to fix the
issue.
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
--
View this message in context:
http://www.nabble.com/Error-in-Zend-Framework-1.6-RC1---tp18621418p18627894.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
till wrote:
On Thu, Jul 24, 2008 at 4:31 AM, Bruno Friedmann [EMAIL PROTECTED] wrote:
Hi all,
I'm just downloaded the 1.6 RC1 release to give it a try.
I've just one trouble : no projects are running now.
The worst there's no errors just a blank page.
(All demo previously used have the same symptom )
I could imagine there's some changes, but there's no documentation about
what a dev
need to adapt inside projects to have them running.
Or did I miss it ( there's could be a improvement like a update.txt file at
the root of library ) ?
PS : In documentation there chapter missing in the index ( 18 doesn't have
title GDATA, 23 is not write and so ... )
You probably want to enable:
log_errors = On
error_log = /path/to/a/writable/log/file
Or maybe it is already enabled and you just need to check it out. To
find out, do a phpinfo() and look for the above options.
Till
wouah ...
As I've declare
error_reporting(E_ALL E_STRICT);
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
in my bootstrap I has forgotten to see my php_error.log ...
What I've found sound strange to me ... sorry
never see this before ... :-)
[error] [client 127.0.0.1] ALERT - Include filename
('zend.view:///home/bruno/workspace/socketfinder/sf/application/modules/default/views/scripts/index/index.phtml')
is an URL that
is not allowed (attacker '127.0.0.1', file
'/ioda/data/web-include/ZF/library/Zend/View.php', line 105)
--
Bruno Friedmann
Ioda-Net Sàrl - www.ioda-net.ch
2830 Vellerat - Switzerland
Tél : ++41 32 435 7171
Fax : ++41 32 435 7172
gsm : ++41 78 802 6760
C'est Facile et Cool d'Évoluer en ligne : www.cfcel.com
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
Bruno Friedmann wrote:
till wrote:
On Thu, Jul 24, 2008 at 4:31 AM, Bruno Friedmann [EMAIL PROTECTED] wrote:
Hi all,
I'm just downloaded the 1.6 RC1 release to give it a try.
I've just one trouble : no projects are running now.
The worst there's no errors just a blank page.
(All demo previously used have the same symptom )
I could imagine there's some changes, but there's no documentation about
what a dev
need to adapt inside projects to have them running.
Or did I miss it ( there's could be a improvement like a update.txt file at
the root of library ) ?
PS : In documentation there chapter missing in the index ( 18 doesn't have
title GDATA, 23 is not write and so ... )
You probably want to enable:
log_errors = On
error_log = /path/to/a/writable/log/file
Or maybe it is already enabled and you just need to check it out. To
find out, do a phpinfo() and look for the above options.
Till
wouah ...
As I've declare
error_reporting(E_ALL E_STRICT);
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
in my bootstrap I has forgotten to see my php_error.log ...
What I've found sound strange to me ... sorry
never see this before ... :-)
[error] [client 127.0.0.1] ALERT - Include filename
('zend.view:///home/bruno/workspace/socketfinder/sf/application/modules/default/views/scripts/index/index.phtml')
is an URL that
is not allowed (attacker '127.0.0.1', file
'/ioda/data/web-include/ZF/library/Zend/View.php', line 105)
Ok found this is when suoshin module is loaded ...
What strange is that with 1.5.2 ZF there's no trouble ...
Can someone confirm ...
--
Bruno Friedmann
Ioda-Net Sàrl - www.ioda-net.ch
2830 Vellerat - Switzerland
Tél : ++41 32 435 7171
Fax : ++41 32 435 7172
gsm : ++41 78 802 6760
C'est Facile et Cool d'Évoluer en ligne : www.cfcel.com
Re: [fw-general] Zend_View helpers return object ids instead of strings
I'm not 100% on the specifics, but before 5.2.0 the __toString() magic method was only called in certain contexts, I think you example below should work because it's in an echo context, but perhaps it's more complicated than that. Anyway, the easiest solution would be to call __toString() manually: ?php echo $this-headTitle()-__toString().\n; ? Endijs Lisovskis wrote: Hi! If such problems were discussed before - please excuse me. I'm new to this mailing list and I couldn't find answer in archive. OK - now about problem. I developed web application on server with PHP 5.2.5, but now I need to put scripts on server with PHP 5.1.6. But there is a problem (I think it's because of PHP 5.1.6). When I try to echo View helpers in Views I receive object ids instead of strings. For example. If I use: head ?php echo $this-headTitle().\n; ? /head Head title is not displayed, but instead I receive something like Object id #40. On server with PHP 5.2.5 everything is fine. Is there any quick solutions for such problems? Thanks! -- Jack
RE: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
The new Zend_View stream wrapper might have something to do with this, although
I'm not sure it is included in 1.6RC1.
See
http://www.nabble.com/Zend_View-and-the-View-Stream-Wrapper-tc17607130ef15440.html#a17607130
Vincent de Lau
[EMAIL PROTECTED]
-Original Message-
From: Bruno Friedmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2008 11:18 AM
To: fw-general@lists.zend.com
Subject: Re: [fw-general] The how-to / what to do upgrading 1.5.2 to
1.6.0
Bruno Friedmann wrote:
till wrote:
On Thu, Jul 24, 2008 at 4:31 AM, Bruno Friedmann [EMAIL PROTECTED]
wrote:
Hi all,
I'm just downloaded the 1.6 RC1 release to give it a try.
I've just one trouble : no projects are running now.
The worst there's no errors just a blank page.
(All demo previously used have the same symptom )
I could imagine there's some changes, but there's no documentation
about what a dev
need to adapt inside projects to have them running.
Or did I miss it ( there's could be a improvement like a update.txt
file at the root of library ) ?
PS : In documentation there chapter missing in the index ( 18
doesn't have title GDATA, 23 is not write and so ... )
You probably want to enable:
log_errors = On
error_log = /path/to/a/writable/log/file
Or maybe it is already enabled and you just need to check it out. To
find out, do a phpinfo() and look for the above options.
Till
wouah ...
As I've declare
error_reporting(E_ALL E_STRICT);
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
in my bootstrap I has forgotten to see my php_error.log ...
What I've found sound strange to me ... sorry
never see this before ... :-)
[error] [client 127.0.0.1] ALERT - Include filename
('zend.view:///home/bruno/workspace/socketfinder/sf/application/modules
/default/views/scripts/index/index.phtml') is an URL that
is not allowed (attacker '127.0.0.1', file '/ioda/data/web-
include/ZF/library/Zend/View.php', line 105)
Ok found this is when suoshin module is loaded ...
What strange is that with 1.5.2 ZF there's no trouble ...
Can someone confirm ...
--
Bruno Friedmann
Ioda-Net Sàrl - www.ioda-net.ch
2830 Vellerat - Switzerland
Tél : ++41 32 435 7171
Fax : ++41 32 435 7172
gsm : ++41 78 802 6760
C'est Facile et Cool d'Évoluer en ligne : www.cfcel.com
Re: [fw-general] New Zend_Wildfire_FirebugLogWriter component now in standard incubator
ChristophDorn wrote: There is a new component called Zend_Wildfire_FirebugLogWriter in the standard incubator. [...] Please take a look at this component and provide your feedback. I am hoping that it can make it into the 1.6 RC2. Nice, I like how it displays formatted exceptions and you can hover over the arguments to see them, this is really cool. And it's so easy to add it to existing code utilising Zend_Log. Good job, I hope to see it in 1.6GA Cheers -- View this message in context: http://www.nabble.com/New-Zend_Wildfire_FirebugLogWriter-component-now-in-standard-incubator-tp18617421p18628883.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
On Thu, Jul 24, 2008 at 6:05 AM, Vincent de Lau [EMAIL PROTECTED] wrote: The new Zend_View stream wrapper might have something to do with this, although I'm not sure it is included in 1.6RC1. See http://www.nabble.com/Zend_View-and-the-View-Stream-Wrapper-tc17607130ef15440.html#a17607130 Vincent de Lau [EMAIL PROTECTED] Interesting. We are still running trunk, and my php has suhosin included as well. No issues what so ever. We also went from straight 1.5.2 to trunk without issues.
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
It is related, I try to find where and how I can insert an issue But don't find
it in jira.
It's a big blocker if it goes release without mention !!
Vincent de Lau wrote:
The new Zend_View stream wrapper might have something to do with this,
although I'm not sure it is included in 1.6RC1.
See
http://www.nabble.com/Zend_View-and-the-View-Stream-Wrapper-tc17607130ef15440.html#a17607130
Vincent de Lau
[EMAIL PROTECTED]
-Original Message-
From: Bruno Friedmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2008 11:18 AM
To: fw-general@lists.zend.com
Subject: Re: [fw-general] The how-to / what to do upgrading 1.5.2 to
1.6.0
Bruno Friedmann wrote:
till wrote:
On Thu, Jul 24, 2008 at 4:31 AM, Bruno Friedmann [EMAIL PROTECTED]
wrote:
Hi all,
I'm just downloaded the 1.6 RC1 release to give it a try.
I've just one trouble : no projects are running now.
The worst there's no errors just a blank page.
(All demo previously used have the same symptom )
I could imagine there's some changes, but there's no documentation
about what a dev
need to adapt inside projects to have them running.
Or did I miss it ( there's could be a improvement like a update.txt
file at the root of library ) ?
PS : In documentation there chapter missing in the index ( 18
doesn't have title GDATA, 23 is not write and so ... )
You probably want to enable:
log_errors = On
error_log = /path/to/a/writable/log/file
Or maybe it is already enabled and you just need to check it out. To
find out, do a phpinfo() and look for the above options.
Till
wouah ...
As I've declare
error_reporting(E_ALL E_STRICT);
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
in my bootstrap I has forgotten to see my php_error.log ...
What I've found sound strange to me ... sorry
never see this before ... :-)
[error] [client 127.0.0.1] ALERT - Include filename
('zend.view:///home/bruno/workspace/socketfinder/sf/application/modules
/default/views/scripts/index/index.phtml') is an URL that
is not allowed (attacker '127.0.0.1', file '/ioda/data/web-
include/ZF/library/Zend/View.php', line 105)
Ok found this is when suoshin module is loaded ...
What strange is that with 1.5.2 ZF there's no trouble ...
Can someone confirm ...
--
--
Bruno Friedmann
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
On Thu, Jul 24, 2008 at 7:04 AM, Bruno Friedmann [EMAIL PROTECTED] wrote: It is related, I try to find where and how I can insert an issue But don't find it in jira. It's a big blocker if it goes release without mention !! The link (CREATE ISSUE) used to be up top, it disappeared for me as well. Till
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
I had the same problem recently, CREATE NEW ISSUE was gone and reappeared few hours later. Other JIRA users claimed it's available, I wonder what was that about. Karol tfk wrote: On Thu, Jul 24, 2008 at 7:04 AM, Bruno Friedmann [EMAIL PROTECTED] wrote: It is related, I try to find where and how I can insert an issue But don't find it in jira. It's a big blocker if it goes release without mention !! The link (CREATE ISSUE) used to be up top, it disappeared for me as well. Till -- View this message in context: http://www.nabble.com/The-how-to---what-to-do-upgrading-1.5.2-to-1.6.0-tp18627451p18629794.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Trying Dojo Hello World
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 11:30 PM -0500):
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
?
html
head
?php
echo $this-headTitle();
echo $this-headMeta();
echo $this-headLink();
echo $this-headStyle();
?
?php if ($this-dojo()-isEnabled()):
You don't need to do the conditional here -- just echo the helper. If
it's not enabled, nothing will be rendered.
Ok, I just commented that line.
One technique I've used is to do the setup below:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
Do you use it like that in your bootstrap?
I suggest that the documentation should include the part of the bootstrap that
took me a while to figure out... Setting the view helper like this:
$view = new Zend_View();
$view-addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer-setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
Is this snippet correct?
Yes. An alternative that shortens it up slightly:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$viewRenderer-initView();
Zend_Dojo::enableView($viewRenderer-view);
but that only eliminates two lines. :)
in my bootstrap, and then disable the helper until I explicitly enable
it in a view script. (I should probably put that in the manual.)
echo $this-dojo();
endif;
?
?php
echo $this-headScript();
?
/head
body class=tundra
h1?php echo $this-placeholder('title') ?/h1
?php echo $this-layout()-content ?
br /
br /
/body
/html
So, now my question is: is something not working for you here?
I just set an explicit localpath:
$this-dojo()-setLocalPath('http://localhost/dev/example/html/scripts/dojo_f/
dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
but still doesn't work... I'll attach some pics to explain myself a little
better though.
Your local path is still incorrect.
Let's say you're using the standard application layout, and have dojo
under public/scripts/dojo_f:
application/
controllers/
views/
library/
Zend/
public/
.htaccess
index.php
scripts/
dojo_f/
dojo/
dojo.js
Your vhost is pointing the DocumentRoot at your public directory. So,
you need so specify the local path as starting at that directory:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js');
Basically, the value you give to setLocalPath() should be the value of
the script's src attribute:
script src=/scripts/dojo_f/dojo/dojo.js
type=text/javascript/script
Make sense?
In dojopic1 is the original example from dojo docs without using ZF at all.
The
button is bigger and nicer...
Well, dojopic2 is the result with the localpath set like:
/scripts/dojo_f/dojo/
dojo.js You can see the button there (a standard one...), but firebug shows
that the the dojo.js wasn't found,
This tells me that you probably don't have the path right. What happens
when you go to /scripts/dojo_f/dojo/dojo.js on your site? Does it
actually resolve, or does it give you a 404?
so I changed the localpath to: http://
localhost/dev/example/html/scripts/dojo_f/dojo/dojo.js the result is in the
dojopic3... But no button at all (?!?!?!?!?) when I check for the source code
of the page (dojopic4) the code has the button in it... :S So I'm quite
confused... I'm at work now, but I use a portable XAMPP It's the same
implementation like the one I use at home... So I still can't explain myself
what is going on there...
BTW thanks for helping matt... I know u are really busy :-)
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 01:02 PM -0500):
Ok, changing that makes the button appear :-) but not in the
tundra
theme
way
:-(
Did you place a 'class=tundra' on a container that has the dijits?
Typically, I place it in my body tag, just to be safe:
body class=tundra
but the only requirement for tundra to be applied is that it is on
an
element that contains dijits:
div class=tundra
?= $this-form ?
/div
Try that
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
-- Bruno Friedmann [EMAIL PROTECTED] wrote
(on Thursday, 24 July 2008, 11:05 AM +0200):
till wrote:
What I've found sound strange to me ... sorry
never see this before ... :-)
[error] [client 127.0.0.1] ALERT - Include filename
('zend.view:///home/bruno/workspace/socketfinder/sf/application/modules/default/views/scripts/index/index.phtml')
is an URL that
is not allowed (attacker '127.0.0.1', file
'/ioda/data/web-include/ZF/library/Zend/View.php', line 105)
Aha! I added what was supposed to be an optional streams layer for
Zend_View to allow using short tags when short tags are disabled.
However, it's supposed to be off by default.
I'll correct this in svn today -- thanks for the report!
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
-- till [EMAIL PROTECTED] wrote (on Thursday, 24 July 2008, 06:58 AM -0400): On Thu, Jul 24, 2008 at 6:05 AM, Vincent de Lau [EMAIL PROTECTED] wrote: The new Zend_View stream wrapper might have something to do with this, although I'm not sure it is included in 1.6RC1. See http://www.nabble.com/Zend_View-and-the-View-Stream-Wrapper-tc17607130ef15440.html#a17607130 Vincent de Lau [EMAIL PROTECTED] Interesting. We are still running trunk, and my php has suhosin included as well. No issues what so ever. We also went from straight 1.5.2 to trunk without issues. The stream wrapper is not used if you have short tags enabled already -- which is why you're not seeing the issues. As mentioned previously, I'm adding a ticket to have this disabled by default, and to document how to enable it (and potential issues with suhosin). -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
-- Matthew Weier O'Phinney [EMAIL PROTECTED] wrote
(on Thursday, 24 July 2008, 08:29 AM -0400):
-- Bruno Friedmann [EMAIL PROTECTED] wrote
(on Thursday, 24 July 2008, 11:05 AM +0200):
till wrote:
What I've found sound strange to me ... sorry
never see this before ... :-)
[error] [client 127.0.0.1] ALERT - Include filename
('zend.view:///home/bruno/workspace/socketfinder/sf/application/modules/default/views/scripts/index/index.phtml')
is an URL that
is not allowed (attacker '127.0.0.1', file
'/ioda/data/web-include/ZF/library/Zend/View.php', line 105)
Aha! I added what was supposed to be an optional streams layer for
Zend_View to allow using short tags when short tags are disabled.
However, it's supposed to be off by default.
I'll correct this in svn today -- thanks for the report!
I've filed an issue if you want to vote or watch on it:
http://framework.zend.com/issues/browse/ZF-3739
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
[fw-general] Re: New Zend_Wildfire_FirebugLogWriter component now in standard incubator
Christoph Dorn wrote: FirePHP also offers a LogWriter for Zend Framework - looks a bit useless to me. This is the FirePHP Log Writer (the one you are referring to was a prototype). The component has been named Zend_Wildfire_FirebugLogWriter to make it clear that it logs messages to Firebug. There will be other components in the Zend_Wildfire namespace that will enhance the integration with FirePHP as well as other client extensions. The namespace represents the name of a project aimed at developing some standard communication channels between server and client code. It will also provide a plugin system to allow server code to control code in client extensions. FirePHP will migrate its own protocol to this communication layer and will become a plugin to the Wildfire system. I am working on more detailed information about Wildfire which will be posted at http://www.wildfirehq.org/ as it becomes available. Nice :) FWIW, Firebug console is currently a bit broken in FF 3.0.1 with FB 1.2.0b7... issues being tracked/worked on via Firebug google group. Col
RE: [fw-general] Announcing Project Planetarium!
Well, ZFWiki has had a make over (and for the better IMHO!) Screenshot: http://code.google.com/p/zfwiki/ http://code.google.com/p/zfwiki/ And how it use to look: http://code.google.com/p/zfwiki/wiki/Screenshots http://code.google.com/p/zfwiki/wiki/Screenshots I am not using Ext JS, but their UI design is excellent. _ From: Robert Castley Sent: 23 July 2008 10:01 To: Zend Framework General Subject: RE: [fw-general] Announcing Project Planetarium! Tine 2.0 looks amazing and what's better it led me to find Ext JS. Now ZFWiki is going to get a complete makeover (LOL). It would be great to have a public list of ZF based open source projects. PHP leads the way in 3 application areas IMHO 1) Bulletin Boards (phpBB, vBulletin etc.) 2) CMS (Drupal, Joomla, Wordpress etc.) 3) Wiki (MediaWiki, DocuWiki etc.) It would be great to see similar applications written using ZF for these 3 areas in the future. One of the greatest strengths I find with ZF is the out-of-the-box SEO friendly URL's. In my years developing Mambo this was one of the biggest requirements and took ages to get it right. Also trying to code around XSS etc was also a nightmare, ZF again to the rescue there. I love ZF :-) _ From: Wil Sinclair [mailto:[EMAIL PROTECTED] Sent: 22 July 2008 23:46 To: Robert Castley; Jurriën Stutterheim Cc: Zend Framework General Subject: RE: [fw-general] Announcing Project Planetarium! I actually have not gotten this impression. In fact, Andi just blogged about 2 ZF-based apps that are finalists in SourceForge's Community Choice Awards (Magento and Tine 2.0 if you'd rather not follow the link): http://andigutmans.blogspot.com/2008/07/zf-well-represented-at-sourceforge.h tml http://andigutmans.blogspot.com/2008/07/zf-well-represented-at-sourceforge. html . There are lots of other projects based on ZF, but I can understand why they may not have gotten a lot of attention: · A lot of these projects are actually closed source powering sites/apps at large companies and organizations. You might be surprised to find out how widespread it is in the 'enterprise' environment; I bet most of you use ZF daily without even knowing it. If I had to guess, I'd say this is because ZF has always taken the difficult position of prioritizing power flexibility over usability in the first few hours. This is something that companies appreciate since they have their requirements at hand when they are choosing the framework, but OS projects are often built up more organically from (sometime simple) projects with requirements coalescing during development. They might not realize that ZF is a good fit for them from the outset. Like I said- just a guess. J · ZF is still relatively young with little more than a year under our belt since the 1.0 release. · A lot of projects actually use ZF components, but don't identify or advertise themselves as ZF-based. We get back to the question of what exactly a ZF app is. Ultimately, I don't care as long as people are using it. ;) · We don't have a big-player CMS based on ZF. CMS's seem to almost reign supreme as the ultimate app in the PHP world and are the lifeblood of many PHPer's development lives. It's a very different situation in other communities in my experience, where CMS's are just another class of applications along with the usual acronym suspects like CRM, ERP, BI, etc. I think this is just a matter of time on this count. We would definitely love to have a list of ZF-based projects on the ZF site. Please, everyone, let me know if you have a project of your own and a link! ,Wil From: Robert Castley [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2008 3:09 PM To: Jurriën Stutterheim Cc: Zend Framework General Subject: RE: [fw-general] Announcing Project Planetarium! It's great to see another Open Source ZF app out there. I thought I was alone ;-) I am surprised there hasn't been a bigger take up. Maybe it is time to have a page on the ZF site dedicated to promoting and supporting OS ZF apps. At the moment the trawl of the web turns up little to nothing in regards to (useful) apps using ZF as the backbone. Tons of tutorials and howtos yes, but nothing really functional. Padraic's blog tutorial has been a really useful resource for me as I explore the deeper depths of ZF. I know this is a framework that can be used standalone, MVC etc. but I think people out there would really benefit from seeing how easily and QUICKLY! apps can be put together. I speak from experience. My little OS project (ZFWiki) took 2 days to get a functional prototype out, a few weeks down the line and I have something that is 'almost' ready to be rolled out internally at the company I work for. ZF is amazing, I love it (and the community that helps me understand it better), but it would be great to see more apps/utils out there that use ZF. Good luck with your project! - Robert
Re: [fw-general] Zend Framework 1.6 Release Candidate 1 nowavailable!
For clearification: The I18N files are available since the beginning and they are not the reason for 20MB more as they still need the same size as before 1.6 (about 3MB in sum for all components). It is impossible that they are the reason for ZF to grow from 6MB to 26MB. :-) The 20MB more must be from another source. Greetings Thomas, I18N Team Leader, Zend Framework - Original Message - From: Matthew Weier O'Phinney [EMAIL PROTECTED] To: fw-general@lists.zend.com Sent: Wednesday, July 23, 2008 2:16 PM Subject: Re: [fw-general] Zend Framework 1.6 Release Candidate 1 nowavailable! -- SiCo007 [EMAIL PROTECTED] wrote (on Wednesday, 23 July 2008, 04:58 AM -0700): Just a quick question why has the file size jumped from 6mb to 26?! Well, for one, there are a ton of new components, which means more code, more tests, and more documentation. As you also note, Dojo is shipping with ZF now, which also boosts the size some (though the Dojo repo is fraction of ZF's size). Can have a download (of the final release) without dojo (assuming that's the culprit) for those of us that don't use it? We have been discussing shipping a lean-and-mean distribution that does not include documentation, tests, dojo, or the localization files (the i18n/l10n files account for a large percentage of the distro). I'm not sure how soon we will be doing this, but it _has_ been on our radar for some time. -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
[fw-general] WYSIWYG editor and Zend Framework
Hi All I have added WYSIWYG editor to one of my form but am unable to utilize its full feature, like when i am going to add Emotions or Citation then it gives the controller error Invalid controller specified (jscripts). Is there something wrong? Is there any other way to add any type of editor within Zend Framework. Regards Rohit -- View this message in context: http://www.nabble.com/WYSIWYG-editor-and-Zend-Framework-tp18633087p18633087.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_File_Transfer and Zend_Form on 1.6
Hy Christian, Question is how Zend_File_Transfer is (or is going to be) integrated with Zend_Form fo file uploads through forms. 1. As far as i see there is no File form element (can be done easily i know) I was said there is one... :-) Matthew or myself will integrate one in the next days. 2. There is any plan to integrate validation side for Zend_File_Transfer with Zend_Form validation side ? Sample: on adding a File upload component all validators set into file upload element to be used for validation under Zend_File_Transfer ? Of course... it would not make sense to have validation for both components seperated. 3. There is any sample for combining Zend_Form with Zend_File_Transfer ? Actually not... you will have to wait a few days until the form element is finished. Until then you can look into my blog for an example usage of Zend_File_Transfer. And there are also 2 or 3 chapters of documentation available which you can work with. Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com
RE: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
Could you please verify that you're logged in (check that your name is listed with filters, profile, etc. links in the upper right-hand corner *on the same page/request* where you don't see the 'create issue' option? We've been having issues at our ISP with load balancing that manifests as the applications not authenticating correctly on some responses, so you might log in, request a page that comes back as if you weren't logged in, then refresh and see a page where you're logged in again. :/ So far we have anecdotal evidence that this is not a problem for everyone, so it may be IP or client state related. In any case, we have a ticket open with our ISP and are actively working on it. I will also verify that you belong to the right groups. Thanks. ,Wil -Original Message- From: Karol Grecki [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 4:15 AM To: fw-general@lists.zend.com Subject: Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0 I had the same problem recently, CREATE NEW ISSUE was gone and reappeared few hours later. Other JIRA users claimed it's available, I wonder what was that about. Karol tfk wrote: On Thu, Jul 24, 2008 at 7:04 AM, Bruno Friedmann [EMAIL PROTECTED] wrote: It is related, I try to find where and how I can insert an issue But don't find it in jira. It's a big blocker if it goes release without mention !! The link (CREATE ISSUE) used to be up top, it disappeared for me as well. Till -- View this message in context: http://www.nabble.com/The-how-to---what- to-do-upgrading-1.5.2-to-1.6.0-tp18627451p18629794.html Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0
I was logged in, I also tried logging out and in again but that didn't help. I could see my profile, unresolved issues I reported etc. It seemed to be working fine, it's just the link was not there. Heh, I just checked and it's missing again. My profile says Groups: confluence-users Logging out didn't help. I don't have this option ATM. But it was there like an hour ago, because I raised an improvement. Karol wllm wrote: Could you please verify that you're logged in (check that your name is listed with filters, profile, etc. links in the upper right-hand corner *on the same page/request* where you don't see the 'create issue' option? We've been having issues at our ISP with load balancing that manifests as the applications not authenticating correctly on some responses, so you might log in, request a page that comes back as if you weren't logged in, then refresh and see a page where you're logged in again. :/ So far we have anecdotal evidence that this is not a problem for everyone, so it may be IP or client state related. In any case, we have a ticket open with our ISP and are actively working on it. I will also verify that you belong to the right groups. Thanks. ,Wil -Original Message- From: Karol Grecki [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 4:15 AM To: fw-general@lists.zend.com Subject: Re: [fw-general] The how-to / what to do upgrading 1.5.2 to 1.6.0 I had the same problem recently, CREATE NEW ISSUE was gone and reappeared few hours later. Other JIRA users claimed it's available, I wonder what was that about. Karol tfk wrote: On Thu, Jul 24, 2008 at 7:04 AM, Bruno Friedmann [EMAIL PROTECTED] wrote: It is related, I try to find where and how I can insert an issue But don't find it in jira. It's a big blocker if it goes release without mention !! The link (CREATE ISSUE) used to be up top, it disappeared for me as well. Till -- View this message in context: http://www.nabble.com/The-how-to---what- to-do-upgrading-1.5.2-to-1.6.0-tp18627451p18629794.html Sent from the Zend Framework mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/The-how-to---what-to-do-upgrading-1.5.2-to-1.6.0-tp18627451p18635880.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Re[fw-general] agrding the current Dispatch process...
Hey, all. I feel like I must have missed something at some point, but has the
Dispatch process changed at some point? Here's what I remember:
1. Front Controller instantiates the Request, Response, Router, and
Dispatcher objects;
2. Dispatcher gets information about initial dispatch from Request and
Router;
3. Dispatcher instantiates the appropriate Controller object, which also
runs Controller-init();
3a. Dispatcher calls Controller-preDispatch();
3b. Dispatcher calls Controller-{$Request-getActionName()}Action();
3c. Dispatcher fields additional dispatch requests (a la
Controller-_forward()), repeat 3...
3d. Dispatcher calls Controller-postDispatch();
4. Dispatcher returns to Front Controller;
5. Front Controller outputs the Response.
This structure precedes the ActionStack, of course, but the important thing
to note is that the postDispatch (hook) method was not called until the
whole loop completed.
From experience, it appears that postDispatch() is now executed after the
action resolves, prior to initiating the next loop (3c and 3d are switched).
The manual and the API docs don't clearly represent this, if this is the
case, although the routing diagram in the manual kinda does. The docs for
Controller::_forward() don't clearly indicate where the re-dispatching
occurs, either. :/
Somebody else please confirm this process! It's important to note the
difference... Personally, I'd much rather see Controller::_forward()
interrupt the dispatch loop (as it used to) and ActionStack preserve it,
even if that means I write Zend_Controller_Action_Helper_Forwarder (a la
Redirector) to do so. I'm not certain there's a method to do so, however, as
the docs on plugins and helpers are a little vague on the subject as well.
Is there an authoritative resource somewhere on how the dispatch loop
actually operates? I've done a little snooping about on the Wiki, and there
are pieces from the 1.1 revision that reference the new Router scheme and
possible changes to the looping process, but I haven't found that one page
that says this is how we do it yet... Thanks...!
David @ OrlandoPHP.org
--
View this message in context:
http://www.nabble.com/Reagrding-the-current-Dispatch-process...-tp18635886p18635886.html
Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] Zend Framework 1.6 Release Candidate 1 now available!
I'll be adjusting the issue process later this week (if I find the time, that is :o), and I will publish a workflow diagram on the homepage of the issue tracker at that time. ,Wil -Original Message- From: Jean-Marc Fontaine [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 12:49 AM To: fw-general@lists.zend.com Subject: Re: [fw-general] Zend Framework 1.6 Release Candidate 1 now available! Matthew Weier O'Phinney-3 wrote: You appear to have marked it as resolved without anyone actually applying the patch. :) What was I supposed to do ? Leave it as open ? I could not find clear how-to on this subject. Matthew Weier O'Phinney-3 wrote: I'm scheduling it for next minor release. Thank you for your help Matthew. -- View this message in context: http://www.nabble.com/Zend-Framework-1.6- Release-Candidate-1-now-available%21-tp18587079p18626941.html Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] ZF SVN repository on Ohloh
I would guess it's because it wasn't updated when we did the repository reorg. I tried to update it myself, but I don't see where I can. Maybe this is something only the creator of the project in Ohloh can do? ,Wil -Original Message- From: Christoph Dorn [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 10:22 AM To: Zend Framework General Subject: [fw-general] ZF SVN repository on Ohloh ZF has a project on Ohloh http://www.ohloh.net/projects/zend_framework but the SVN repository is not being indexed. Is there a reason for this? Christoph
Re: [fw-general] ZF SVN repository on Ohloh
I would guess it's because it wasn't updated when we did the repository reorg. I tried to update it myself, but I don't see where I can. Maybe this is something only the creator of the project in Ohloh can do? Yes. As far as I know only the creator can make changes to how the repository is indexed. Christoph
[fw-general] Extending Zend_Mail_Part for Reading
I couldn't figure out how to open a new issue, so I'm post this to the list.
I needed to add some functionality to Zend_Mail_Part to improve upon a mail
parser for work. In order to get the Storage object to use my new Part
object I had to jump through many hoops to get it all to work. The
following code fragments illustrate how I managed to get it to work:
//storage object
require_once ('Zend/Mail/Storage/Imap.php');
class My_Mail_Storage_Imap extends Zend_Mail_Storage_Imap
{
protected $_messageClass = 'My_Mail_Message';
}
//message object
require_once 'My/Mail/Part.php';
class My_Mail_Message extends My_Mail_Part
{ ...exact copy of Zend_Mail_Message violating DRY... }
//part object
require_once ('Zend/Mail/Part.php');
class My_Mail_Part extends Zend_Mail_Part
{
protected function _cacheContent()
{
// caching content if we can't fetch parts
if ($this-_content === null $this-_mail) {
$this-_content =
$this-_mail-getRawContent($this-_messageNum);
}
if (!$this-isMultipart()) {
return;
}
// split content in parts
$boundary = $this-getHeaderField('content-type', 'boundary');
if (!$boundary) {
/**
* @see Zend_Mail_Exception
*/
require_once 'Zend/Mail/Exception.php';
throw new Zend_Mail_Exception('no boundary found in content type
to split message');
}
$parts = Zend_Mime_Decode::splitMessageStruct($this-_content,
$boundary);
$counter = 1;
// WORKAROUND Early Binding Issue: ZF-3745
$classname = get_class($this);
foreach ($parts as $part) {
$this-_parts[$counter++] = new $classname(array('headers' =
$part['header'], 'content' = $part['body']));
}
}
public function myNewMethod()
{...}
}
Notice I had to make a duplicate class for My_Mail_Message which is an exact
copy of Zend_Mail_Message save for the extends My_Mail_Part. Also due to
early binding I had to duplicate Zend_Mail_Part::_cacheContent() in
My_Mail_Part and implement a work around to get it to return my new class
vs. Zend_Mail_Part.
This seems more difficult than it should be. Extending these components so
we can add functionality or tailor their implementation should be much
easier than this. If I didn't have Nico on irc helping me I would still be
stuck. There is an issue open for the early binding bit, but that sill
leaves us having to duplicate Zend_Mail_Message in order to get an extended
object chain working.
Either that or the docs need to be updated with how accomplish using an
extended Mail_Part class without having to jump through these hoops.
Thanks
--
View this message in context:
http://www.nabble.com/Extending-Zend_Mail_Part-for-Reading-tp18641268p18641268.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Trying Dojo Hello World
So, you're telling me that I _must_ have the vhosts file configured so that
any given project is given a full URL i.e.: http://localhost/ (or any other
vhosts URL I configured?).
2008/7/24 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 11:30 PM -0500):
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
?
html
head
?php
echo $this-headTitle();
echo $this-headMeta();
echo $this-headLink();
echo $this-headStyle();
?
?php if ($this-dojo()-isEnabled()):
You don't need to do the conditional here -- just echo the helper. If
it's not enabled, nothing will be rendered.
Ok, I just commented that line.
One technique I've used is to do the setup below:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
Do you use it like that in your bootstrap?
I suggest that the documentation should include the part of the bootstrap
that
took me a while to figure out... Setting the view helper like this:
$view = new Zend_View();
$view-addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer-setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
Is this snippet correct?
Yes. An alternative that shortens it up slightly:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$viewRenderer-initView();
Zend_Dojo::enableView($viewRenderer-view);
but that only eliminates two lines. :)
in my bootstrap, and then disable the helper until I explicitly
enable
it in a view script. (I should probably put that in the manual.)
echo $this-dojo();
endif;
?
?php
echo $this-headScript();
?
/head
body class=tundra
h1?php echo $this-placeholder('title') ?/h1
?php echo $this-layout()-content ?
br /
br /
/body
/html
So, now my question is: is something not working for you here?
I just set an explicit localpath:
$this-dojo()-setLocalPath('
http://localhost/dev/example/html/scripts/dojo_f/
dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
but still doesn't work... I'll attach some pics to explain myself a
little
better though.
Your local path is still incorrect.
Let's say you're using the standard application layout, and have dojo
under public/scripts/dojo_f:
application/
controllers/
views/
library/
Zend/
public/
.htaccess
index.php
scripts/
dojo_f/
dojo/
dojo.js
Your vhost is pointing the DocumentRoot at your public directory. So,
you need so specify the local path as starting at that directory:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js');
Basically, the value you give to setLocalPath() should be the value of
the script's src attribute:
script src=/scripts/dojo_f/dojo/dojo.js
type=text/javascript/script
Make sense?
In dojopic1 is the original example from dojo docs without using ZF at
all. The
button is bigger and nicer...
Well, dojopic2 is the result with the localpath set like:
/scripts/dojo_f/dojo/
dojo.js You can see the button there (a standard one...), but firebug
shows
that the the dojo.js wasn't found,
This tells me that you probably don't have the path right. What happens
when you go to /scripts/dojo_f/dojo/dojo.js on your site? Does it
actually resolve, or does it give you a 404?
so I changed the localpath to: http://
localhost/dev/example/html/scripts/dojo_f/dojo/dojo.js the result is in
the
dojopic3... But no button at all (?!?!?!?!?) when I check for the source
code
of the page (dojopic4) the code has the button in it... :S So I'm quite
confused... I'm at work now, but I use a portable XAMPP It's the same
implementation like the one I use at home... So I still can't explain
myself
what is going on there...
BTW thanks for helping matt... I know u are really busy :-)
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 01:02 PM -0500):
Ok, changing that makes the button appear :-) but not in the
tundra
theme
way
:-(
Did you place a 'class=tundra' on a container that has the
dijits?
Typically, I place
Re: [fw-general] Trying Dojo Hello World
Ok I configured the vhosts and still nothing... The button disappears...
I attached the applicaion layout i'm using for your consideration.
2008/7/24 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 11:30 PM -0500):
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
?
html
head
?php
echo $this-headTitle();
echo $this-headMeta();
echo $this-headLink();
echo $this-headStyle();
?
?php if ($this-dojo()-isEnabled()):
You don't need to do the conditional here -- just echo the helper. If
it's not enabled, nothing will be rendered.
Ok, I just commented that line.
One technique I've used is to do the setup below:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
Do you use it like that in your bootstrap?
I suggest that the documentation should include the part of the bootstrap
that
took me a while to figure out... Setting the view helper like this:
$view = new Zend_View();
$view-addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer-setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
Is this snippet correct?
Yes. An alternative that shortens it up slightly:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$viewRenderer-initView();
Zend_Dojo::enableView($viewRenderer-view);
but that only eliminates two lines. :)
in my bootstrap, and then disable the helper until I explicitly
enable
it in a view script. (I should probably put that in the manual.)
echo $this-dojo();
endif;
?
?php
echo $this-headScript();
?
/head
body class=tundra
h1?php echo $this-placeholder('title') ?/h1
?php echo $this-layout()-content ?
br /
br /
/body
/html
So, now my question is: is something not working for you here?
I just set an explicit localpath:
$this-dojo()-setLocalPath('
http://localhost/dev/example/html/scripts/dojo_f/
dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
but still doesn't work... I'll attach some pics to explain myself a
little
better though.
Your local path is still incorrect.
Let's say you're using the standard application layout, and have dojo
under public/scripts/dojo_f:
application/
controllers/
views/
library/
Zend/
public/
.htaccess
index.php
scripts/
dojo_f/
dojo/
dojo.js
Your vhost is pointing the DocumentRoot at your public directory. So,
you need so specify the local path as starting at that directory:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js');
Basically, the value you give to setLocalPath() should be the value of
the script's src attribute:
script src=/scripts/dojo_f/dojo/dojo.js
type=text/javascript/script
Make sense?
In dojopic1 is the original example from dojo docs without using ZF at
all. The
button is bigger and nicer...
Well, dojopic2 is the result with the localpath set like:
/scripts/dojo_f/dojo/
dojo.js You can see the button there (a standard one...), but firebug
shows
that the the dojo.js wasn't found,
This tells me that you probably don't have the path right. What happens
when you go to /scripts/dojo_f/dojo/dojo.js on your site? Does it
actually resolve, or does it give you a 404?
so I changed the localpath to: http://
localhost/dev/example/html/scripts/dojo_f/dojo/dojo.js the result is in
the
dojopic3... But no button at all (?!?!?!?!?) when I check for the source
code
of the page (dojopic4) the code has the button in it... :S So I'm quite
confused... I'm at work now, but I use a portable XAMPP It's the same
implementation like the one I use at home... So I still can't explain
myself
what is going on there...
BTW thanks for helping matt... I know u are really busy :-)
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 01:02 PM -0500):
Ok, changing that makes the button appear :-) but not in the
tundra
theme
way
:-(
Did you place a 'class=tundra' on a container that has the
dijits?
Typically, I place it in my body tag, just to be safe:
Re: [fw-general] Trying Dojo Hello World
Ok, figured it out... Firebug told me that I was calling an undefined
object... The dojo version I was using It's the one from the 1.6RC1... I
downloaded a fresh copy and it worked fine... The button is now the same
from the dojo docs examples... Thanks for the help Matt
2008/7/24 Christian Sanchez [EMAIL PROTECTED]:
Ok I configured the vhosts and still nothing... The button disappears...
I attached the applicaion layout i'm using for your consideration.
2008/7/24 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 11:30 PM -0500):
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
?
html
head
?php
echo $this-headTitle();
echo $this-headMeta();
echo $this-headLink();
echo $this-headStyle();
?
?php if ($this-dojo()-isEnabled()):
You don't need to do the conditional here -- just echo the helper.
If
it's not enabled, nothing will be rendered.
Ok, I just commented that line.
One technique I've used is to do the setup below:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
Do you use it like that in your bootstrap?
I suggest that the documentation should include the part of the
bootstrap that
took me a while to figure out... Setting the view helper like this:
$view = new Zend_View();
$view-addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer-setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
Is this snippet correct?
Yes. An alternative that shortens it up slightly:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$viewRenderer-initView();
Zend_Dojo::enableView($viewRenderer-view);
but that only eliminates two lines. :)
in my bootstrap, and then disable the helper until I explicitly
enable
it in a view script. (I should probably put that in the manual.)
echo $this-dojo();
endif;
?
?php
echo $this-headScript();
?
/head
body class=tundra
h1?php echo $this-placeholder('title') ?/h1
?php echo $this-layout()-content ?
br /
br /
/body
/html
So, now my question is: is something not working for you here?
I just set an explicit localpath:
$this-dojo()-setLocalPath('
http://localhost/dev/example/html/scripts/dojo_f/
dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
but still doesn't work... I'll attach some pics to explain myself a
little
better though.
Your local path is still incorrect.
Let's say you're using the standard application layout, and have dojo
under public/scripts/dojo_f:
application/
controllers/
views/
library/
Zend/
public/
.htaccess
index.php
scripts/
dojo_f/
dojo/
dojo.js
Your vhost is pointing the DocumentRoot at your public directory. So,
you need so specify the local path as starting at that directory:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js');
Basically, the value you give to setLocalPath() should be the value of
the script's src attribute:
script src=/scripts/dojo_f/dojo/dojo.js
type=text/javascript/script
Make sense?
In dojopic1 is the original example from dojo docs without using ZF at
all. The
button is bigger and nicer...
Well, dojopic2 is the result with the localpath set like:
/scripts/dojo_f/dojo/
dojo.js You can see the button there (a standard one...), but firebug
shows
that the the dojo.js wasn't found,
This tells me that you probably don't have the path right. What happens
when you go to /scripts/dojo_f/dojo/dojo.js on your site? Does it
actually resolve, or does it give you a 404?
so I changed the localpath to: http://
localhost/dev/example/html/scripts/dojo_f/dojo/dojo.js the result is in
the
dojopic3... But no button at all (?!?!?!?!?) when I check for the source
code
of the page (dojopic4) the code has the button in it... :S So I'm quite
confused... I'm at work now, but I use a portable XAMPP It's the same
implementation like the one I use at home... So I still can't explain
myself
what is going on there...
BTW thanks for helping matt... I know u are really busy :-)
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on
Re: [fw-general] Zend Framework 1.6 Release Candidate 1 now available!
Hey I just re-downloaded (if that's a word :P) the package from the page you sent but I had some issues with the dojo (externals) version packaged, I suggest you should make a new package because Dojo wasn't working with the tests I was making. Had to download a fresh copy from the dojotoolkit home page. Firebug was sending some errors about not defined objects... Hope this suggestion could help some people that downloaded this version and it wasn't working for them... 2008/7/22 Alexander Veremyev [EMAIL PROTECTED]: We couldn't be happier to announce that Zend Framework 1.6 Release Candidate 1 is now available from the Zend Framework download site! http://framework.zend.com/download An overview of new features: * Dojo Integration - JSON-RPC - Dojo Data packing - Dojo View Helper - Dijit integration with Zend_Form Zend_View - Dojo Library Distribution * SOAP - SOAP Server - SOAP Client - Autodiscovery - WSDL access - WSDL Generation * Preview of Tooling Project in Laborator (see /laboratory folder) - Command Line Interface - Project Asset Management * Unit Testing Harness for Controllers * Lucene 2.3 Index File Format Support * Zend_Session save handler for Database Tables * Paginator Component * Text/Figlet Support * ReCaptcha Service * Zend_Config_Xml Attribute Support * Character Set Option for DB Adapters * Zend File Transfer Component * New Media View Helpers (Flash, Quicktime, Object, and Page) * Support in Zend_Translate for INI File Format This obviously marks a very important step towards a high-quality, highly tested 1.6 GA release. Thanks to everyone who has contributed to this release in any way: with patches/check ins, documentation/translations, and bug reports. But our work is not yet over! Let's do our best to bring this release to the breaking point to find areas we can improve the release for General Availability. Based on your feedback we will determine in the next few weeks whether we require additional release candidates, so please provide feedback on our issue tracker (http://framework.zend.com/issues) as soon as you can and ask any questions/post your experiences on the appropriate mailing list. 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.6RC1, and see you on the issue tracker, wiki, and mailing lists! ,Alexander -- Christian Sánchez A.
Re: [fw-general] Trying Dojo Hello World
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Thursday, 24 July 2008, 04:50 PM -0500):
So, you're telling me that I _must_ have the vhosts file configured so that
any
given project is given a full URL i.e.: http://localhost/ (or any other vhosts
URL I configured?).
No. You just need to provide the path segment of the URL that will
resolve to dojo.
So, if http://localhost/scripts/dojo/dojo.js resolves, you pass
'/scripts/dojo/dojo.js' to setLocalPath().
2008/7/24 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 11:30 PM -0500):
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
?
html
head
?php
echo $this-headTitle();
echo $this-headMeta();
echo $this-headLink();
echo $this-headStyle();
?
?php if ($this-dojo()-isEnabled()):
You don't need to do the conditional here -- just echo the helper.
If
it's not enabled, nothing will be rendered.
Ok, I just commented that line.
One technique I've used is to do the setup below:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/
dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
Do you use it like that in your bootstrap?
I suggest that the documentation should include the part of the
bootstrap
that
took me a while to figure out... Setting the view helper like this:
$view = new Zend_View();
$view-addHelperPath('Zend/Dojo/View/Helper/', 'Zend_Dojo_View_Helper');
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer-setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
Is this snippet correct?
Yes. An alternative that shortens it up slightly:
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper
('ViewRenderer');
$viewRenderer-initView();
Zend_Dojo::enableView($viewRenderer-view);
but that only eliminates two lines. :)
in my bootstrap, and then disable the helper until I explicitly
enable
it in a view script. (I should probably put that in the manual.)
echo $this-dojo();
endif;
?
?php
echo $this-headScript();
?
/head
body class=tundra
h1?php echo $this-placeholder('title') ?/h1
?php echo $this-layout()-content ?
br /
br /
/body
/html
So, now my question is: is something not working for you here?
I just set an explicit localpath:
$this-dojo()-setLocalPath('http://localhost/dev/example/html/scripts/
dojo_f/
dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
but still doesn't work... I'll attach some pics to explain myself a
little
better though.
Your local path is still incorrect.
Let's say you're using the standard application layout, and have dojo
under public/scripts/dojo_f:
application/
controllers/
views/
library/
Zend/
public/
.htaccess
index.php
scripts/
dojo_f/
dojo/
dojo.js
Your vhost is pointing the DocumentRoot at your public directory. So,
you need so specify the local path as starting at that directory:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js');
Basically, the value you give to setLocalPath() should be the value of
the script's src attribute:
script src=/scripts/dojo_f/dojo/dojo.js
type=text/javascript/script
Make sense?
In dojopic1 is the original example from dojo docs without using ZF at
all. The
button is bigger and nicer...
Well, dojopic2 is the result with the localpath set like:
/scripts/dojo_f
/dojo/
dojo.js You can see the button there (a standard one...), but firebug
shows
that the the dojo.js wasn't found,
This tells me that you probably don't have the path right. What happens
when you go to /scripts/dojo_f/dojo/dojo.js on your site? Does it
actually resolve, or does it give you a 404?
so I changed the localpath to: http://
localhost/dev/example/html/scripts/dojo_f/dojo/dojo.js the result is in
the
dojopic3... But
Re: [fw-general] Trying Dojo Hello World
It worked matthew the problem was with the Dojo version included in the ZF
1.6 RC1... Thanks for answering, i know it was getting frustrating and
annoying :/
Thanks a lot Matt!!
2008/7/24 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Thursday, 24 July 2008, 04:50 PM -0500):
So, you're telling me that I _must_ have the vhosts file configured so
that any
given project is given a full URL i.e.: http://localhost/ (or any other
vhosts
URL I configured?).
No. You just need to provide the path segment of the URL that will
resolve to dojo.
So, if http://localhost/scripts/dojo/dojo.js resolves, you pass
'/scripts/dojo/dojo.js' to setLocalPath().
2008/7/24 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
(on Wednesday, 23 July 2008, 11:30 PM -0500):
2008/7/23 Matthew Weier O'Phinney [EMAIL PROTECTED]:
-- Christian Sanchez [EMAIL PROTECTED] wrote
?
html
head
?php
echo $this-headTitle();
echo $this-headMeta();
echo $this-headLink();
echo $this-headStyle();
?
?php if ($this-dojo()-isEnabled()):
You don't need to do the conditional here -- just echo the
helper. If
it's not enabled, nothing will be rendered.
Ok, I just commented that line.
One technique I've used is to do the setup below:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/
dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
Do you use it like that in your bootstrap?
I suggest that the documentation should include the part of the
bootstrap
that
took me a while to figure out... Setting the view helper like this:
$view = new Zend_View();
$view-addHelperPath('Zend/Dojo/View/Helper/',
'Zend_Dojo_View_Helper');
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer-setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
Is this snippet correct?
Yes. An alternative that shortens it up slightly:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper
('ViewRenderer');
$viewRenderer-initView();
Zend_Dojo::enableView($viewRenderer-view);
but that only eliminates two lines. :)
in my bootstrap, and then disable the helper until I explicitly
enable
it in a view script. (I should probably put that in the
manual.)
echo $this-dojo();
endif;
?
?php
echo $this-headScript();
?
/head
body class=tundra
h1?php echo $this-placeholder('title') ?/h1
?php echo $this-layout()-content ?
br /
br /
/body
/html
So, now my question is: is something not working for you here?
I just set an explicit localpath:
$this-dojo()-setLocalPath('
http://localhost/dev/example/html/scripts/
dojo_f/
dojo/dojo.js')
-addStyleSheetModule('dijit.themes.tundra');
but still doesn't work... I'll attach some pics to explain myself a
little
better though.
Your local path is still incorrect.
Let's say you're using the standard application layout, and have dojo
under public/scripts/dojo_f:
application/
controllers/
views/
library/
Zend/
public/
.htaccess
index.php
scripts/
dojo_f/
dojo/
dojo.js
Your vhost is pointing the DocumentRoot at your public directory. So,
you need so specify the local path as starting at that directory:
$this-dojo()-setLocalPath('/scripts/dojo_f/dojo/dojo.js');
Basically, the value you give to setLocalPath() should be the value
of
the script's src attribute:
script src=/scripts/dojo_f/dojo/dojo.js
type=text/javascript/script
Make sense?
In dojopic1 is the original example from dojo docs without using ZF
at
all. The
button is bigger and nicer...
Well, dojopic2 is the result with the localpath set like:
/scripts/dojo_f
/dojo/
dojo.js You can see the button there (a standard one...), but
firebug
shows
that the the dojo.js wasn't found,
Re: [fw-general] Zend_OpenId fails for yahoo openid
Hi All, I was attempting to connect to Yahoo from a localhost. Unfortunately, it seems like Yahoo does not allow this. See Yahoo! OpenID FAQ at http://developer.yahoo.com/openid/faq.html http://developer.yahoo.com/openid/faq.html Yahoo! Security Policies Yahoo! will only support Relying Parties running on webservers with real hostnames (IP addresses are not supported) running on standard ports (Port 80 for HTTP and Port 443 for HTTPS). Jerry Stev918 wrote: I worked with the guys from SourceForge a bit when they shipped Zend_OpenID. What version of Zend_OpenID are you using? The one that ships with the current stable version of Zend Framework is riddled with problems. So if you haven't already tried, I would highly recommend upgrading at least the Zend_OpenID component to a recent snapshot version. Steven Osborn Founding Software Developer, Vidoop LLC -- View this message in context: http://www.nabble.com/Zend_OpenId-fails-for-yahoo-openid-tp15910120p18644498.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Combining Zend_Auth with Zend_Auth_Adapter
I am at wits end with this, where most of the examples could be
instructive, they use phrases such as:
Other details, such as how the authentication service is queried,
have been omitted for brevity
Which these details are precisely what is ambiguous (at least to me).
I have a login form which takes username and password and passes them
to the login action called processAction. Within processAction, the
request is validated for POST and variables etc etc. Then comes the
actual authentication to check the database and verify the 'identity'
of the user.
The following code is giving me 'fatal error Call to a member function
isValid() on a non-object':
// Get authentication adapter to check input variables
$adapter = $this-getAuthAdapter($form-getValues());
$auth = Zend_Auth::getInstance();
$result = $auth-authenticate($adapter);
Then later isValid is called on $result like so: $result-isValid()
and blamo I get the error.
Now .. getAuthAdapter instantiates the following class:
class MyAuthAdapter implements Zend_Auth_Adapter_Interface
{
public function __construct($username, $password)
{
$this-username = $username;
$this-password = $password;
}
public function authenticate()
{
$db_config = array('host' = '127.0.0.1', 'username' =
'ioforgec_zend', 'password' = 'Pa55w0rD', 'dbname' =
'ioforgec_iofdb');
try
{
$db = Zend_Db::factory('Pdo_Mysql', $db_config);
$db-getConnection();
} catch (Zend_Db_Adapter_Exception $e) {
print // perhaps a failed login credential, or perhaps the
RDBMS is not running\n;
} catch (Zend_Exception $e) {
print // perhaps factory() failed to load the specified
Adapter class\n;
}
// Attempt to use fetchAll() - The first argument to this method
is a string containing a SELECT statement
// The second argument to fetchAll() is an array of values to
substitute for parameter placeholders in the SQL statement
$sql = SELECT * FROM users WHERE username = ? AND password = ?;
$result = $db-fetchAll($sql, array($this-username, $this-password));
// Return Zend_Auth_Result Object to determine success or
failure of authenticate attempt
if ($result[0]['auth']) { return Zend_Auth_Result::SUCCESS; }
return Zend_Auth_Result::FAILURE;
}
Ok .. so I used the Zend_Auth_Result because as I read it turns out
thats what the isValid() function is expecting. Other places I read I
need to call the Zend_Auth method Authenticate without any changes,
while others say I need to instantiate a Zend_Auth_Adapter and over
write the authenticate call with my own DB selects, etc.
What is going on here? How can I get so confused? Im following
directions (Or so I thought) from a tutorial on the zendframework
site:
http://weierophinney.net/matthew/archives/165-Login-and-Authentication-with-Zend-Framework.html
Could I get a little re-alignment? Thank you ;0)
