Re: [fw-general] Any thoughts about Zend View Filters for Zend layout?
Ciao Vincent, I was using the word filter somewhat loosely. An example would be GIMP blur filters. They take an input image, modify it and pass it back, not merely filter out It might also function as a decorator. The response object is a choke point, almost every thing passes through the response object on its way to the layout, making it a good place to put a filter. The idea is to modify 'filter/decorate based on the named response segment rather than the content i.e. where its going rather than what it is. Also, we already have a filters directory in our modular directory layout but alas, no filters. ciao, *quetz* .
Re: [fw-general] Any thoughts about Zend View Filters for Zend layout?
Vincent,
Use cases might be :
$view--setFilter('content', 'box_it'); // content appears in box with
rounded corners
$view--setFilter('content', 'no_bad_words'); // naughty words become
nty w##ds
$view--setFilter('content', 'double_digit'); // all single digits get a
leading 0, 1 becomes 01
$view--setFilter('content', 'hide_IPs'); // ip address 23.23.23.23 becomes
23.XX.XX.XX.XX
By setting a filter in the Controller's init function, all 'content'
generated by that controller's actions would automatically get the filter
applied it.
ciao,
Quetz
[fw-general] Any thoughts about Zend View Filters for Zend layout?
Hola!
Since we are routing output through the response object, it makes zend view
filters feasible.
The idea is to attach a filter(s) to a named segment of the response object
and then, when the
response object renders to the view, it first runs the contents of the
named segments through a filter.
or possibly a filter chain on its way to the view object.
$view-myFilter('response_segment');
or maybe filters could be set by a viewHelper:
$view--setFilter('response_segment', 'filter_name');
It may be possible to do this without changing the response object
by using a view helper to set the filters and plugins to render the named
segments.
Or, perhaps a more integrated method may be used. We already have
/views/filters directory.
Anybody have thoughts on this issue?
Adios.
*quetzequatl*
Re: [fw-general] Extend acl to include modules
To Darby,
Thank you for response. I really would like to have the api I mentioned.
The current one is perfect for controller::action, but i think there is a
need
to be able to allow/deny at the modular level. There is a natural parental
relationship between module::controller::action. This allows you to specify
at each level exactly which resources are being allowed/denied.
Here are some things that bother me with the current non-modular ACL.
Modules may have controllers::actions with the same name. The
indexController comes to
mind. How do you ban some index::action and allow others?
Attempts to solve the above problems (and others) lead to complicated tests
at the use point.
i.e. first test the module then test the controller::action. instead of a
nice clean $acl-allow(...);
I realize that the current ACL api isn't specific to the controller::action,
but it does
map onto the controller::action very nicely. With one more level of
indirection it should
map onto the module::controller::action.
cheers,
Pat Veach
Hi Pat,
Though a major use of Zend_Acl is to restrict access to action
controllers, Zend_Acl is not limited to this purpose. Thus, its API is
not specific to controllers, actions, and modules.
Yes, Zend_Acl is extensible, so you should be able to define isAllowed()
in an extending class if you want to transform the API as you have
indicated.
I think that the underlying issue is how you identify and structure your
resources. Zend_Acl is flexible on how resources may be identified, so
maybe something like the following would work for you:
class My_Acl extends Zend_Acl
{
public function isAllowed($role, $module, $controller, $action)
{
return parent::isAllowed($role, $module.$controller, $action);
}
}
The dot separator is arbitrary, and Zend_Acl per se does not care about
what role and resource identifiers are used, only that they are unique.
So you can come up with your own resource naming schema however
appropriate for your needs.
Judging from your deny() and allow() usage examples, however, I suspect
that you need to organize the resources such that modules are parents of
controllers.
$acl-add(new Zend_Acl_Resource($module))
-add(new Zend_Acl_Resource($module.$controller), $module);
Alternatively, you could override these methods in an extending class if
you require a specific API (e.g., in your examples below).
Hope that helps!
Best regards,
Darby
Re: [fw-general] Extend acl to include modules
To Darby, I wasn't really sure about the nature of priveleges, but you cleared that up. Thank you. Thanks also to Matthew and Ralf pat
[fw-general] Action files
I use the following method:
Using conventional modular directory layout most controllers go into a
folder/directory named after the module.
controllers/admin
/testing
/etc
Controllers in the testing module might be cookies, pages and so on:
controllers/testing/CookiesController.php
controllers/testing/PagesController.php
Now, I create a subfolder in the testing folder named after the controller
controllers/testing
/pages
/cookies
I factor common utility functions used by the PagesController actions into a
file called pages_utilities.php.
The file page_utilities.php goes into the /pages subfolder, so we have:
controllers/testing/CookiesController.php // controller action scripts
controllers/testing/PagesController.php
controllers/testing// sub directory
/pages/pages_utilities.php // file containing page
controller utility functions
/pages/enroll_form.php // contains a function that
returns a form used by the page controller
controllers/cookies // same as above
/cookies_utilities.php
/cookies/test_form.php
Inside the PagesController.php require_once allows access to controller
specific files
require_once 'pages/pages_utilities.php';
require_once 'pages/enroll_form.php';
class Testing_PagesController{...}
This allows me to move the controller around to different modules as long as I
move its subdir along with it.
(and change the class name of course, Testing_PagesController would become
ModuleX_PagesController).
I should point that with this method you need to be on the alert for link rot
especially in forms.
If your form posts to /testing/pages/add and you move the controller to a new
module named 'working',
you should change your form to post to /working/pages/add.
This leads to module relative addressing stuff like:
$view-menu =
create_nav_menu(get_menu_items($this-getRequest()-module),'Delete Item');
The create_nav_menu function is in one of the directories in the php include
path making it available
to all controllers in all modules. Its first parameter is a function that
returns an array of menu items, like:
get_menu_items($mod) { $items = array ('Add Item' = $mod/pages/add,
'Delete Item' = $mod/pages/delete); return $items; }
The second parameter is a menu item so it can treat the selected menu item
different from the un-selected ones, hilite it maybe.
The function get_menu_items() is in the file 'pages/pages_utilities.php' its
only parameter (look closely) is the module name.
It injects the module name into the above $mod variable
Now, when the controller is moved to a new module the module relative address
can track automatically.
My controllers are much smaller now that I factor out common or complex
functions especially forms!
I hope this helps and if I am doing it wrong or backwards, please let me know.
Pat Veach
[fw-general] ZendFW chat
Did we ever set up a ZendFW chatroom? I know there was talk, but I don't know what was decided. thanks. pat
Re: [fw-general] Community chat
I would prefer freenode to efnet :-)
[fw-general] more on controller directories
To the list:
This worked:
$route = new
Zend_Controller_Router_Route('testing/:controller/:action/*',array('controller'
= 'test', 'action' = 'index'));
$router-addRoute('testing', $route);
$controller-addControllerDirectory(make_private_path('/app/controllers/testing'));
However, there are now two paths that work
1. * /testing/test/show*
2. */test/show*
Both go to the same Controller/Action. Is this a feature or a bug?
This also worked:
$controller-getDispatcher()-setWordDelimiter('-');
Allows one to map: */test/show-user* to TestController::showUserAction
Very nice:)
BTW I'm using Zend.70
pat
[fw-general] getting controllers into subdirectories
Greetings to Zend Framework team; Is there an example of getting the rewrite router to work with controllers in subdirectories? I have several controllers and I would like to group them into different functional areas and place them into subdirectories. I want the URL *' /testing/test/info' *to map to /testing/TestController.php. Where TestController.php contains infoAction.. I have tried several different urls similar to */testing_test/info. *I have tried using the 'useModules' switch (in both front controller and router) and then URL */testing/test/info* but nothing seems to work. Is there a code snippet that shows controller setup that works with subdirectories? A very plain example would be most appreciated. Thanks. pat
[fw-general] What is a back en controller?
What is a back end controller?
