[fw-general] [apc-error] Cannot redeclare class
I've just updated my Zend Framework library on my test server to the latest SVN head and now I'm getting an APC error: [apc-error] Cannot redeclare class zend_dojo I've traced back the error and it starts with Revision 11629 which addressed ZF-4458 (Analyse bottlenecks in Zend_Loader and Zend_Loader_PluginLoader and attempt to fix). Thing is... on my development server I don't have any problems, even with the latest source. Dev server (no apc errors): Mac OS X / MAMP PHP Version 5.2.3 APC Version 3.0.14 Test server (with apc error above): CentOS release 5.2 (Final) PHP Version 5.2.6 APC Version 3.0.19 My test server is setup/configured as my final production server will be. Any ideas on how to fix this error? Any help will be greatly appreciated. Thanks, Todd
[fw-general] Depreciated fetchAll()/fetchRow() functionality
With all the talk of a Zend_Deprecation and the evolution of the
framework in general, I have a question about Zend_DB and fetchAll()/
fetchRow().
The documentation states that the depreciated usage (of not using a
Zend_Db_Table_Select object) of fetchRow() and fetchAll() will
continue to work.
I do like the simplicity (and already have many functions using this)
of being able to write a quick select like:
$rows = $table->fetchAll('bug_status = "NEW"', 'bug_id ASC', 10, 0);
Will we eventually lose this ability and have to migrate to the
updated usage of a Zend_Db_Table_Select like:
$rows = $table->fetchAll($table->select()->where('bug_status = ?',
'NEW')
->order('bug_id ASC')
->limit(10, 0));
This option has its place and use it when needed, but I still continue
to use the simpler method for quick selects.
So what I'm wondering... should I stop using the simple fetchAll() and
fetchRow() methods in favor of using them with the select object?
Thanks,
Todd
Re: [fw-general] Dojo library Layout
public/js would be a js folder under your server's document root (html
in your case).
You can in reality put the dojo source anywhere under the document
root (pulbic folder) and set the location in the dojo view helper.
i.e.
$view->dojo()->setLocalPath('/js/dojo/dojo.js')
->addStyleSheetModule('dijit.themes.tundra');
On Jul 18, 2008, at 11:45 AM, Christian Sanchez wrote:
2008/7/18 Matthew Weier O'Phinney <[EMAIL PROTECTED]>:
-- Christian Sanchez <[EMAIL PROTECTED]> wrote
(on Friday, 18 July 2008, 10:12 AM -0500):
> I was wondering if there is a best practice for the layout
considering the
> usage of the recent Zend_Dojo... I know it must be under the html
folder, but
> how do you recommend it should be implemented?
>
> >application
> >html
> >images
> >scripts
> >js
> >dojo
> >styles
> >library
>
> Or maybe?
>
> >application
> >html
> >images
> >scripts
> >dojo
> >styles
> >library
>
> Any suggestions?
Dojo is javascript, so it should be under public/js/
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
Just to make things clear, you say it should be:
>application
>html
>images
>scripts
>styles
>library
>js
>dojo
--
Christian Sánchez A.
Re: [fw-general] Dojo library Layout
I currently use a layout similar to your second option and I keep my Dojo modules in their own directory outside of the dojo source. - application - bootstrap - htdocs - images - scripts - dojo - dijit - dojo - dojox - util - mydojo - library - tmp On Jul 18, 2008, at 10:12 AM, Christian Sanchez wrote: I was wondering if there is a best practice for the layout considering the usage of the recent Zend_Dojo... I know it must be under the html folder, but how do you recommend it should be implemented? >application >html >images >scripts >js >dojo >styles >library Or maybe? >application >html >images >scripts >dojo >styles >library Any suggestions? -- Christian Sánchez A.
Re: [fw-general] Recent Component Promotions
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] Recent Component Promotions
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/
[fw-general] Extending Zend_Auth
I'm not sure as to the best way to go about this...
I'm building an application that will authenticate different types of
users (ie system admins and customers) and they are maintained in
different database tables. I'd like to have each type to use a
different storage namespace.
What I've done in the past is to extend Zend_Auth and override the
getInstance() method. I've also added helper methods such as getUser()
to return a Zend_Table_Row object of the authenticated user.
self::$_instance->setStorage(new
Zend_Auth_Storage_Session('Auth_Admin'));
}
return self::$_instance;
}
public function getUser()
{
$id = $this->getIdentity()->client_admin_id;
$table = new ClientAdmins();
return $table->find($id)->current();
}
}
?>
This has worked up until I tested my code on PHP v.5.2.6 and I get:
Fatal error: Call to private Zend_Auth::__construct() from context
'My_Auth_Client' in /var/www/vhosts/dev.dzcrs.com/library/My/Auth/
Client.php on line 9
Which after looking at the Zend_Auth code, makes sense (and I'm not
quite sure why it works on my 5.2.3 server).
My question is how to best accomplish this. I can extend Zend_Auth
and override getInstance to automatically set the storage by using
parent::getInstance() but then I lose any helper methods I create
since I'm returning a Zend_Auth instance rather than a My_Auth_Client
instance.
Thoughts? Am I going about this totally backwards?
Thanks,
Todd
Re: [fw-general] Multiple Auth Logins
Mike, thanks for the reply.
I've come up with something that works for my situation, but it
involves extending the Zend_Auth singleton class (which I know
probably isn't the best way to do things).
I do want to use Zend_Auth since I'm looking for the storage, which
was the oversight in my original logic. I was using the same
namespace in both classes, so of course each instance of the two
separate classes would return that it had an identity since it was
looking to the same session (one of those "oh, duh" moments).
The two types of users will be logging in at separate pages (actually
one is logging in via a 3rd party site that sends back a token).
I'll be able to tell the admins by using $myAuthAdmin->getIdentity()
and other users by $myAuthOtheruser->getIdentity();
This is what I ended up doing. I don't know if is the best way, but
it works:
class My_Auth_Otheruser extends Zend_Auth
{
protected static $_instance = null;
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
self::$_instance->setStorage(new Zend_Auth_Storage_Session
('Auth_Otheruser'));
}
return self::$_instance;
}
}
On Oct 11, 2007, at 9:15 PM, Michael B Allen wrote:
On 10/11/07, Todd Wolaver <[EMAIL PROTECTED]> wrote:
Hello,
I have implemented Zend_Auth for admin users to login and I'm
checking authentication and ACLs in a preDispatch plugin.
Now I need to authenticate a different type of user which has nothing
to do with the admins and uses a totally different storage engine and
auth adapter.
I'm trying to figure out how to keep these users separate and I can't
seem to figure it out.
At this point I'm thinking I need a new class which extends
Zend_Auth, but Zend_Auth being a singleton I'll always get back an
instance of Zend_Auth.
Hi Todd,
Note that you can use Zend_Auth_Adapters directly without using the
Zend_Auth class at all. Zend_Auth just provides a single point from
which you can retrieve information about an authentication.
Even if I extend the class as below, "hasIdentity()" will return
true if the admin has logged in under Zend_Auth:
I don't really understand this. Regardless of how Zend_Auth works, by
what mechanism will you determine if the user really is an admin or
not?
Note that you can of course overload hasIdentity / getIdenity and give
them intelligence about your different authentication mechanisms.
Does anyone have any suggestions on how to implement several
different authentication schemes? Do I need to extend Zend_Auth for
the admin and the other users and not use Zend_Auth directly?
From your description I really don't understand what the problem
really is but here are a few ideas that may or may not be pertinent.
Create a third adapter that negotiates which authentication method
should be used.
Extend Zend_Auth and add a getUser method that returns a bonified
My_User object that may be queried (e.g. $user->isAdmin()).
Mike
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
[fw-general] Multiple Auth Logins
Hello,
I have implemented Zend_Auth for admin users to login and I'm
checking authentication and ACLs in a preDispatch plugin.
Now I need to authenticate a different type of user which has nothing
to do with the admins and uses a totally different storage engine and
auth adapter.
I'm trying to figure out how to keep these users separate and I can't
seem to figure it out.
At this point I'm thinking I need a new class which extends
Zend_Auth, but Zend_Auth being a singleton I'll always get back an
instance of Zend_Auth.
Even if I extend the class as below, "hasIdentity()" will return
true if the admin has logged in under Zend_Auth:
class My_Auth_Otheruser extends Zend_Auth
{
protected static $_instance = null;
protected $_storage = null;
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
}
Does anyone have any suggestions on how to implement several
different authentication schemes? Do I need to extend Zend_Auth for
the admin and the other users and not use Zend_Auth directly?
Thanks,
Todd
[fw-general] Zend_DB findManyToManyRowset issue in latest snapshot (after commit 6251)
Hello,
I just checked out the latest code from Trunk and now I'm getting
errors within my application related to Zend_DB and
findManyToManyRowset. I've tried the samples in the documentation,
http://framework.zend.com/manual/en/zend.db.table.relationships.html
The sample code works. However... with a slight change in column
names it hoses the references.
The error:
Notice: Undefined index: product_id in /srv/sites/athweb-prt03/
library/Zend/Db/Table/Row/Abstract.php on line 839
When calling findManyToManyRowset the name of the column in the
lookup table now has to be the same as the column name in the
intersection table. You used to be able to specify any column names
here, however commit #6251 changed this. All of my tables have a
column of "id" as the primary key. Intersection columns are named
'tablename_id'. Is there any way to keep this functionality or do I
need to go back and change all my column names?
If I change the "id" column in both the products and bugs table to
'product_id' and 'bug_id' and make the corresponding changes in the
referenceMap, findManyToManyRowset works.
Thanks,
Todd
The db structure that fails is:
CREATE TABLE `bugs` (
`id` int(11) NOT NULL auto_increment PRIMARY KEY, <--- this would
need to be bug_id to work
`bug_description` varchar(100) default NULL,
`bug_status` varchar(20) default NULL,
);
CREATE TABLE `bugs_products` (
`id` int(11) NOT NULL auto_increment PRIMARY KEY, <-- this would
need to be product_id to work
`bug_id` int(11) NOT NULL,
`product_id` int(11) NOT NULL,
);
CREATE TABLE `products` (
`id` int(11) NOT NULL auto_increment PRIMARY KEY,
`product_name` varchar(100) default NULL,
);
The referenceMap is:
protected $_referenceMap= array(
'Bug' => array(
'columns' => array('bug_id'),
'refTableClass' => 'Bugs',
'refColumns'=> array('id') <--- this would need
to be bug_id to work
),
'Product' => array(
'columns' => array('product_id'),
'refTableClass' => 'Products',
'refColumns'=> array('id') <--- this would need
to be product_id to work
)
);
Re: [fw-general] Zend_View_Helper_FormCheckbox
I agree that this behavior seems odd... especially when the default
options are preset to 1 & 0.
It seems like you need to implement a hack to accomplish the basic
functionality.
1) you can (as Nathan mentioned) do a check yourself to see if the
checkbox should be checked and only pass the $value if it should be
checked. But this defeats the purpose of "If $value matches the
"checked" value, the box will be checked for you." when "the first
value is the "checked" value".
or
2) you can set $value to a fixed value (1 in my case) and alter the
first option to your variable data value. But then why set any
default options in the first place.
The documented use case makes it seam that if you set the value to
"no" you will still get a checkbox that has a value of yes (since
"yes" is the default checked value) if checked, but that is not the
case.
formCheckbox('opt_in', 'yes', null, array('yes',
'no')) ?>
I know there were some exceptions made to alter the api during the
release candidate phases, but I don't understand this one.
And yes, one tends to feel strongly about things when it directly
affects them. I've got a lot of forms that will need to be hacked to
get them to function now. I just want to understand why I'm doing
what I'm doing. I'd also like to see this made clear in the
documentation.
Thanks,
Todd
On Jul 5, 2007, at 8:38 PM, Nathan Wright wrote:
I ran into the same thing just recently.
A simple workaround for the old behaviour: Only pass the value
argument if the checkbox is meant to be ticked. You could create
another view helper which proxies formCheckbox() and handles that
condition.
The behaviour seems very bizarre so I'm interested to hear the
reasoning behind it.
ncw.
On 5-Jul-07, at 3:27 PM, Todd Wolaver wrote:
Maybe I'm missing something here, but there was a change to the
FormCheckbox helper from RC3 to v 1.0 and I'm not sure as to the
usage now.
When I specify:
$isPublished = 0;
$this->formCheckbox('content[published]', $isPublished);
In RC3 I'd get a form field like:
In v 1.0 I get:
In RC3 I'd get a form field like:
The problem being, if I check the checkbox using the v1.0 code,
and I get back a value of 0. I know this was changed for a reason
but shouldn't the checkbox contain a value of 1 (the default
checked value)?
Thanks,
Todd
[fw-general] Zend_View_Helper_FormCheckbox
Maybe I'm missing something here, but there was a change to the
FormCheckbox helper from RC3 to v 1.0 and I'm not sure as to the
usage now.
When I specify:
$isPublished = 0;
$this->formCheckbox('content[published]', $isPublished);
In RC3 I'd get a form field like:
In v 1.0 I get:
In RC3 I'd get a form field like:
The problem being, if I check the checkbox using the v1.0 code, and I
get back a value of 0. I know this was changed for a reason but
shouldn't the checkbox contain a value of 1 (the default checked value)?
Thanks,
Todd
Re: [fw-general] Custom Error Pages
I should have looked a little harder, but I didn't see the changes
that were added today:
http://www.nabble.com/New-features-added-today-tf3768852s16154.html
Answered my question.
Todd
On May 17, 2007, at 9:05 AM, Todd Wolaver wrote:
I am currently displaying custom error pages by checking for
exceptions in the dispatchLoopShutdown(), which works fine with 9.3.
After checking out the current trunk (4837) it seems that
dispatchLoopShutdown() not run before I get a fatal error.
Is this a bug or a planed & expected result which I should refactor
into my code?
public function dispatchLoopShutdown()
{
$response = Zend_Controller_Front::getInstance()->getResponse();
if ($response->isException()) {
... send to error page ...
}
}
Fatal error: Uncaught exception 'Exception' with message 'Cannot
find page' in /var/www/html/application/modules/default/controllers/
IndexController.php:25 Stack trace: #0 /var/www/html/library/Zend/
Controller/Action.php(438): IndexController->norouteAction() #1 /
var/www/html/library/Zend/Controller/Dispatcher/Standard.php(230):
Zend_Controller_Action->dispatch('norouteAction') #2 /var/www/html/
library/Zend/Controller/Front.php(863):
Zend_Controller_Dispatcher_Standard->dispatch(Object
(Zend_Controller_Request_Http), Object
(Zend_Controller_Response_Http)) #3 /var/www/html/htdocs/index.php
(66): Zend_Controller_Front->dispatch() #4 {main} thrown in /var/
www/html/application/modules/default/controllers/
IndexController.php on line 25
Thanks,
Todd
-
Todd Wolaver
[EMAIL PROTECTED]
1505 Park PL., Apt 20
College Station, TX 77840
Phone: 979-739-3256
AIM: miribota
MSN: [EMAIL PROTECTED]
-
[fw-general] Custom Error Pages
I am currently displaying custom error pages by checking for
exceptions in the dispatchLoopShutdown(), which works fine with 9.3.
After checking out the current trunk (4837) it seems that
dispatchLoopShutdown() not run before I get a fatal error.
Is this a bug or a planed & expected result which I should refactor
into my code?
public function dispatchLoopShutdown()
{
$response = Zend_Controller_Front::getInstance()->getResponse();
if ($response->isException()) {
... send to error page ...
}
}
Fatal error: Uncaught exception 'Exception' with message 'Cannot find
page' in /var/www/html/application/modules/default/controllers/
IndexController.php:25 Stack trace: #0 /var/www/html/library/Zend/
Controller/Action.php(438): IndexController->norouteAction() #1 /var/
www/html/library/Zend/Controller/Dispatcher/Standard.php(230):
Zend_Controller_Action->dispatch('norouteAction') #2 /var/www/html/
library/Zend/Controller/Front.php(863):
Zend_Controller_Dispatcher_Standard->dispatch(Object
(Zend_Controller_Request_Http), Object
(Zend_Controller_Response_Http)) #3 /var/www/html/htdocs/index.php
(66): Zend_Controller_Front->dispatch() #4 {main} thrown in /var/www/
html/application/modules/default/controllers/IndexController.php on
line 25
Thanks,
Todd
-
Todd Wolaver
[EMAIL PROTECTED]
1505 Park PL., Apt 20
College Station, TX 77840
Phone: 979-739-3256
AIM: miribota
MSN: [EMAIL PROTECTED]
-
Re: [fw-general] _forward() Question
Matthew,
Thanks for your feedback on this,
Your solution put into an Action Helper has turned out to be what
seems to be a nice clean way to protect actions from direct access.
To check I just run the following in the init() function of the
controller:
public function init()
{
$this->_helper->CheckForward(array('protectedAction1',
'protectedAction2'));
}
Thanks again.
Todd
On May 5, 2007, at 1:29 PM, Matthew Weier O'Phinney wrote:
-- Maurice Fonk <[EMAIL PROTECTED]> wrote
(on Saturday, 05 May 2007, 08:03 PM +0200):
You are right. That's what you get for thinking out loud, you can be
wrong, I don't quote Socrates for nothing ;). You can't use
attributes
of the object (controller instance) that does the forwarding to keep
track of the forwarding process. In one of your controllers, try the
following (also try adding test_request/abc to your url):
public function indexAction() {
$this->_test = 'test';
//attribute
$this->getFrontController()->setParam('test_front', true);
//in front controller
$this->getRequest()->setParam('test_request', true);
//in request parameters
$this->_forward('forward');
}
public function forwardAction() {
var_dump($this->_test);
//$this->_test isn't defined (NULL)
var_dump($this->getFrontController()->getParam('test_front'));
//bool(true)
var_dump($this->_getParam('test_request'));
//bool(true)
}
Setting a parameter in the front controller may be a good way to
check
for forwards, but it does mean you have to include an additional
line of
code.
Not necessarily. I've been thinking on this, and what I think is
needed
is a routeShutdown() plugin, and then a check in the controller's
preDispatch() method.
As for the routeShutdown() plugin, the reason I suggest this is that
routing happens exactly once during the request cycle, so after the
routing has happened we know exactly what the original request was.
You
can then use a routeShutdown() plugin to register that request with
the
front controller:
class OriginalRequestPlugin extends
Zend_Controller_Plugin_Abstract
{
public function routeShutdown
(Zend_Controller_Request_Abstract $request)
{
Zend_Controller_Front::getInstance()->setParam
('origRequest', clone $request);
}
}
Then, in your controllers that have actions that should only be run
during via _forward(), do some checks in the preDispatch() method:
class FooController extends Zend_Controller_Action
{
// Actions which should only be called via _forward()
public $forwardOnly = array('commit', 'revert');
public function preDispatch()
{
$request = $this->getRequest();
$action = $request->getActionName();
if (in_array($action, $this->forwardOnly)) {
$origRequest = $this->getInvokeArg('origRequest');
if ($origRequest->getActionName() == $action) {
throw new Exception($action . ' action may only
be called via _forward()');
}
}
}
}
The above could actually be placed in an Action Helper as well, so
that
it doesn't need to be written for every controller needing the
functionality or require a Zend_Controller_Action subclass.
You don't have to use the request params, whicht may collide with
params your application actually uses. I'm not sure whether this
is the
intended use of the setParam method of the front controller. The
params
you set in it will be passed to __construct of the action controller.
If you put the forwardAction in another controller (even module) you
should still get the same results, if you modify the forward.
Maurice
Todd Wolaver wrote:
I agree that there should be a standard way to check for forwards or
what actions have already been called. Possibly keeping track of
this
in the Front controller?
As far as the forward, even it were not marked final (just for my
own
understanding):
Wouldn't setting a parameter when calling _forward() only live
within
the current action's lifetime and not persist to the action being
forwarded to.
Todd
On May 5, 2007, at 11:17 AM, Maurice Fonk wrote:
Indeed, that makes perfect sense. Enforcing compatibility between
modules does sound kind of important ;).
Still, having to add aditional parameters to the request, or
checking
whether the action name is in the path info feels like a bit of a
hack to me. Furthermore, if I have an index action, the word
'index'
may not even be in the path info (because it's the default
controller/action), so checking for it wouldn't always tell you
whether it was called
Re: [fw-general] Invoke Arg in Plugin
Yes, I've just run into this myself and I ended up using the
Zend_Controller_Front::getInstance()
i.e.
$this->_config = Zend_Controller_Front::getInstance()->getParam
('config');
Todd
On May 7, 2007, at 2:10 PM, Maurice Fonk wrote:
Because the front controller follows a singleton pattern, can't you
just use $controller = Zend_Controller_Front::getInstance(); and
retrieve parameters from $controller then (with getParam())?
MF
Ian Warner wrote:
Hi
Can I get at Parameters I have set within the front controller
within a plugin?
ie in bootstrap
$controller->setControllerDirectory($controllers)
->throwExceptions(true)
->setParam('config', $config)
->setParam('db', $db)
->setParam('site_name', $site_name)
->setParam('translate', $translate)
->setParam('view', $view)
->registerPlugin(new Zend_Plugin_Auth())
->registerPlugin(new Zend_Plugin_Translation());
what i want to do in a plugin is:
$this->_config= $this->getInvokeArg('config');
is this possible?
Cheers
Ian
--
Maurice Fonk
[EMAIL PROTECTED]
http://naneau.nl/
Scio me nihil scire
Re: [fw-general] _forward() Question
I agree that there should be a standard way to check for forwards or
what actions have already been called. Possibly keeping track of this
in the Front controller?
As far as the forward, even it were not marked final (just for my own
understanding):
Wouldn't setting a parameter when calling _forward() only live
within the current action's lifetime and not persist to the action
being forwarded to.
Todd
On May 5, 2007, at 11:17 AM, Maurice Fonk wrote:
Indeed, that makes perfect sense. Enforcing compatibility between
modules does sound kind of important ;).
Still, having to add aditional parameters to the request, or
checking whether the action name is in the path info feels like a
bit of a hack to me. Furthermore, if I have an index action, the
word 'index' may not even be in the path info (because it's the
default controller/action), so checking for it wouldn't always tell
you whether it was called directly. On the other hand, you probably
wouldn't have an index action that shouldn't be callable directly.
It would be nice if there was a standard way to check for forwards,
and enforce some actions to be callable only that way.
Maurice
Matthew Weier O'Phinney wrote:
-- Maurice Fonk <[EMAIL PROTECTED]> wrote
(on Saturday, 05 May 2007, 03:57 PM +0200):
Interesting. I wonder why the method is marked final? It seems to
me like extending it might come in useful, because in your case
you have to perform additional steps (adding validComponent to
the params) as well.
It was originally marked final because PHP doesn't enforce that
subclasses use the same parameter signature (not following it will
raise
an E_STRICT, but it's still allowed), and the only way to enforce
consistency in how it works was to mark it final.
The primary reason I feel it should remain final is due to the
modular functionality introduced in the 0.8.0 - 0.9.0 releases. When
developers start sharing application modules, there has to be some
base
functionality that will continue to work between them. _forward()
is one
of those.
The point is that this method, and a handful of others in the action
controller, have functionality that should likely not change between
implementations so that applications
Todd Wolaver wrote:
Sorry about that last post... premature sending
The _forward() method is marked final in Zend_Controller_Action
so I can't add an attribute by extending the class.
This is what I've ended up doing, where validComponent is added
to the params passed to the _forward() method.
public function indexAction()
{
if($this-> _getParam('validComponent') !== true) throw
new Exception('Can not find page.');
edit processing
Ath_Component::addContent($this-> _getParam('divId'),
$this-> parse());
}
Thanks,
Todd
On May 4, 2007, at 5:28 PM, Maurice Fonk wrote:
I'm just thinking out loud here, but couldn't you add an
attribute to your controller base class, say _beenForwarded =
false; , then add a method:
protected function _forward(...) {
$this-> _beenForwarded = true;
parent::_forward(...);
}
This way you can easily check whether there the request has
been forwarded or not. Is this too short-sighted?
MF
Todd Wolaver wrote:
Thanks Matthew,
Unfortunately this will be a fairly large site with content
managers managing the content & URLs. In addition there could
be several _forwards() from a single "page" and the
opportunity to have a action/controller name somewhere in the
path is too great.
At this point I'm probably going to add a parameter to the
user defined parameters that are passed to the action, then
check for the parameter in the action. Not my ideal solution,
but I can't find anything better.
Thanks again,
Todd
On May 4, 2007, at 4:08 PM, Matthew Weier O'Phinney wrote:
-- Todd Wolaver <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> wrote
(on Friday, 04 May 2007, 03:21 PM -0500):
I have actions that are only intended to be called from a
_forward().
I'd like to put a security check at the head of the action
to check and see if the action is being called by a _forward
() or by URL. If it is being called by URL I'll display an
appropriate error.
I can think of ways to protect these actions by using
routes, mod_rewrite, passing params and other hacks... but
would like to have everything contained inside the action
and not rely on other methods.
Is there any way to tell if an action is being called from a
_forward()?
Check to see if the action name is in the request path:
if (strstr($this-> _request-> getPathInfo(), $this->
_request-> getActionName())) {
// action name is in the path info -- probably called
directly
}
Not entirely fool-proof, but it could work.
--
Maurice Fonk
[EMAIL PROTECTED]
http://naneau.nl/
Scio me nihil scire
Re: [fw-general] _forward() Question
Sorry about that last post... premature sending
The _forward() method is marked final in Zend_Controller_Action so I
can't add an attribute by extending the class.
This is what I've ended up doing, where validComponent is added to
the params passed to the _forward() method.
public function indexAction()
{
if($this->_getParam('validComponent') !== true) throw new
Exception('Can not find page.');
edit processing
Ath_Component::addContent($this->_getParam('divId'), $this-
>parse());
}
Thanks,
Todd
On May 4, 2007, at 5:28 PM, Maurice Fonk wrote:
I'm just thinking out loud here, but couldn't you add an attribute
to your controller base class, say _beenForwarded = false; , then
add a method:
protected function _forward(...) {
$this->_beenForwarded = true;
parent::_forward(...);
}
This way you can easily check whether there the request has been
forwarded or not. Is this too short-sighted?
MF
Todd Wolaver wrote:
Thanks Matthew,
Unfortunately this will be a fairly large site with content
managers managing the content & URLs. In addition there could be
several _forwards() from a single "page" and the opportunity to
have a action/controller name somewhere in the path is too great.
At this point I'm probably going to add a parameter to the user
defined parameters that are passed to the action, then check for
the parameter in the action. Not my ideal solution, but I can't
find anything better.
Thanks again,
Todd
On May 4, 2007, at 4:08 PM, Matthew Weier O'Phinney wrote:
-- Todd Wolaver <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote
(on Friday, 04 May 2007, 03:21 PM -0500):
I have actions that are only intended to be called from a
_forward().
I'd like to put a security check at the head of the action to
check and see if the action is being called by a _forward() or
by URL. If it is being called by URL I'll display an
appropriate error.
I can think of ways to protect these actions by using routes,
mod_rewrite, passing params and other hacks... but would like to
have everything contained inside the action and not rely on
other methods.
Is there any way to tell if an action is being called from a
_forward()?
Check to see if the action name is in the request path:
if (strstr($this->_request->getPathInfo(), $this->_request-
>getActionName())) {
// action name is in the path info -- probably called
directly
}
Not entirely fool-proof, but it could work.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
Zend - The PHP Company | http://www.zend.com/
--
Maurice Fonk
[EMAIL PROTECTED]
http://naneau.nl/
Scio me nihil scire
Re: [fw-general] _forward() Question
The _forward() method is marked final in Zend_Controller_Action
public function indexAction()
{
if($this->_getParam('validComponent') !== true) throw new
Exception('Can not find page.');
edit processing
Ath_Component::addContent($this->_getParam('divId'), $this-
>parse());
}
Component
---------
Todd Wolaver
[EMAIL PROTECTED]
1505 Park PL., Apt 20
College Station, TX 77840
Phone: 979-739-3256
AIM: miribota
MSN: [EMAIL PROTECTED]
-
On May 4, 2007, at 5:28 PM, Maurice Fonk wrote:
I'm just thinking out loud here, but couldn't you add an attribute
to your controller base class, say _beenForwarded = false; , then
add a method:
protected function _forward(...) {
$this->_beenForwarded = true;
parent::_forward(...);
}
This way you can easily check whether there the request has been
forwarded or not. Is this too short-sighted?
MF
Todd Wolaver wrote:
Thanks Matthew,
Unfortunately this will be a fairly large site with content
managers managing the content & URLs. In addition there could be
several _forwards() from a single "page" and the opportunity to
have a action/controller name somewhere in the path is too great.
At this point I'm probably going to add a parameter to the user
defined parameters that are passed to the action, then check for
the parameter in the action. Not my ideal solution, but I can't
find anything better.
Thanks again,
Todd
On May 4, 2007, at 4:08 PM, Matthew Weier O'Phinney wrote:
-- Todd Wolaver <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote
(on Friday, 04 May 2007, 03:21 PM -0500):
I have actions that are only intended to be called from a
_forward().
I'd like to put a security check at the head of the action to
check and see if the action is being called by a _forward() or
by URL. If it is being called by URL I'll display an
appropriate error.
I can think of ways to protect these actions by using routes,
mod_rewrite, passing params and other hacks... but would like to
have everything contained inside the action and not rely on
other methods.
Is there any way to tell if an action is being called from a
_forward()?
Check to see if the action name is in the request path:
if (strstr($this->_request->getPathInfo(), $this->_request-
>getActionName())) {
// action name is in the path info -- probably called
directly
}
Not entirely fool-proof, but it could work.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
Zend - The PHP Company | http://www.zend.com/
--
Maurice Fonk
[EMAIL PROTECTED]
http://naneau.nl/
Scio me nihil scire
Re: [fw-general] _forward() Question
Thanks Matthew,
Unfortunately this will be a fairly large site with content managers
managing the content & URLs. In addition there could be several
_forwards() from a single "page" and the opportunity to have a action/
controller name somewhere in the path is too great.
At this point I'm probably going to add a parameter to the user
defined parameters that are passed to the action, then check for the
parameter in the action. Not my ideal solution, but I can't find
anything better.
Thanks again,
Todd
On May 4, 2007, at 4:08 PM, Matthew Weier O'Phinney wrote:
-- Todd Wolaver <[EMAIL PROTECTED]> wrote
(on Friday, 04 May 2007, 03:21 PM -0500):
I have actions that are only intended to be called from a _forward().
I'd like to put a security check at the head of the action to check
and see if the action is being called by a _forward() or by URL. If
it is being called by URL I'll display an appropriate error.
I can think of ways to protect these actions by using routes,
mod_rewrite, passing params and other hacks... but would like to have
everything contained inside the action and not rely on other methods.
Is there any way to tell if an action is being called from a
_forward()?
Check to see if the action name is in the request path:
if (strstr($this->_request->getPathInfo(), $this->_request-
>getActionName())) {
// action name is in the path info -- probably called directly
}
Not entirely fool-proof, but it could work.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
[fw-general] _forward() Question
Hello, I have actions that are only intended to be called from a _forward(). I'd like to put a security check at the head of the action to check and see if the action is being called by a _forward() or by URL. If it is being called by URL I'll display an appropriate error. I can think of ways to protect these actions by using routes, mod_rewrite, passing params and other hacks... but would like to have everything contained inside the action and not rely on other methods. Is there any way to tell if an action is being called from a _forward()? Thanks, Todd
[fw-general] PDO, MSSQL and FreeTDS
Hi,
I'm using FreeTDS under Linux to access MSSQL databases, which won'
t work with the framework since the PDO driver is dblib not mssql.
$db = Zend_Db::factory('pdo_mssql', $params);
will return:
"The mssql driver is not currently installed"
This is set in the Mssql.php PDO adapter (Zend_Db_Adapter_Pdo_Mssql):
43:protected $_pdoType = 'mssql';
If this is changed to dblib then it works. What would be the best way
of implementing the dblib driver without changing the core code of
the framework?
Thanks
Todd Wolaver
