Re: [fw-general] Serve images from symlinked directory
I figured out what it was: There was another .htaccess lurking in the
target directory with a rule to allow from only one uri and deny everything
else.
--regards,
nathan
On Thu, Nov 21, 2013 at 6:34 PM, Nathan Garlington wrote:
> Here's my .htaccess:
>
>
> Options +FollowSymLinks
>
> RewriteEngine On
> RewriteBase /
> RewriteCond %{REQUEST_FILENAME} -s [OR]
> RewriteCond %{REQUEST_FILENAME} -l [OR]
> RewriteCond %{REQUEST_FILENAME} -d
> RewriteRule ^.*$ - [NC,L]
> RewriteRule ^.*$ index.php [NC,L]
>
>
> --regards,
> nathan
>
>
> On Thu, Nov 21, 2013 at 6:10 PM, Tim Lieberman wrote:
>
>> Can you confirm that you have:
>>
>> RewriteCond %{REQUEST_FILENAME} -l [OR]
>>
>> in your .htaccess ?
>>
>> Nathan Garlington
>> November 21, 2013 at 6:01 PM
>> I am trying to serve images out of a directory that is not in the public
>> directory where my zf installation is serving out of (hopefully that makes
>> sense).
>>
>> If I serve the images from the public directory where the .htaccess and
>> index.php are located, things work fine. But if I try to serve images
>> from a
>> symlinked directory under the public directory, I get:
>>
>> "Invalid controller specified (media)"
>>
>> The working path is: "mysite.com/media/images/album/myImg.jpg" where
>> "images/" is a real directory under "media/".
>>
>> The problematic path is: "mysite.com/media/albums/myAlbumName/myImg.jpg"
>> where "albums/" is a symlinked directory. I have Options +FollowSymlinks
>> in
>> /public/.htaccess, but I still get the error. Any suggestions?
>>
>>
>>
>> -
>> --regards,
>>
>> Nathan Garlington
>> Zend Framework + Dojo
>> http://www.tandrtrailer.com
>> --
>> View this message in context:
>> http://zend-framework-community.634137.n4.nabble.com/Serve-images-from-symlinked-directory-tp4661255.html
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>>
>
Re: [fw-general] Serve images from symlinked directory
Here's my .htaccess:
Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
--regards,
nathan
On Thu, Nov 21, 2013 at 6:10 PM, Tim Lieberman wrote:
> Can you confirm that you have:
>
> RewriteCond %{REQUEST_FILENAME} -l [OR]
>
> in your .htaccess ?
>
> Nathan Garlington
> November 21, 2013 at 6:01 PM
> I am trying to serve images out of a directory that is not in the public
> directory where my zf installation is serving out of (hopefully that makes
> sense).
>
> If I serve the images from the public directory where the .htaccess and
> index.php are located, things work fine. But if I try to serve images from
> a
> symlinked directory under the public directory, I get:
>
> "Invalid controller specified (media)"
>
> The working path is: "mysite.com/media/images/album/myImg.jpg" where
> "images/" is a real directory under "media/".
>
> The problematic path is: "mysite.com/media/albums/myAlbumName/myImg.jpg"
> where "albums/" is a symlinked directory. I have Options +FollowSymlinks in
> /public/.htaccess, but I still get the error. Any suggestions?
>
>
>
> -
> --regards,
>
> Nathan Garlington
> Zend Framework + Dojo
> http://www.tandrtrailer.com
> --
> View this message in context:
> http://zend-framework-community.634137.n4.nabble.com/Serve-images-from-symlinked-directory-tp4661255.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
>
[fw-general] Serve images from symlinked directory
I am trying to serve images out of a directory that is not in the public directory where my zf installation is serving out of (hopefully that makes sense). If I serve the images from the public directory where the .htaccess and index.php are located, things work fine. But if I try to serve images from a symlinked directory under the public directory, I get: "Invalid controller specified (media)" The working path is: "mysite.com/media/images/album/myImg.jpg" where "images/" is a real directory under "media/". The problematic path is: "mysite.com/media/albums/myAlbumName/myImg.jpg" where "albums/" is a symlinked directory. I have Options +FollowSymlinks in /public/.htaccess, but I still get the error. Any suggestions? - --regards, Nathan Garlington Zend Framework + Dojo http://www.tandrtrailer.com -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/Serve-images-from-symlinked-directory-tp4661255.html Sent from the Zend Framework mailing list archive at Nabble.com. -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com
[fw-general] [ZF2] ZfcUser issues
I am having some issues with Zf-Commons/ZfcUsr (installed via git) and wondered where the appropriate place to post issues/questions would be? Namely: 1) Had to manually change how the ZfcUser\src\ZfcUser\Controller\Plugin\ZfcUserAuthentication.php has it's dependencies injected (patched it myself using some of the patches from other git hub accounts) 2) After I got that working, had to remove $tablename from the constructor for Zend\Db\Sql\Select in ZfcUser\src\ZfcUser\Mapper\User getSelect(). Including $tablename in the constructor throws an exception that the table is readonly when an insert is attempted. 3) After fixed that and tried to submit new registration, postgres wouldn't allow a NULL inserted into user_id col (mine is defined with SERIAL datatype). Not sure if this is an issue with how the data is passed to the ZF classes by ZfcUser or if it is a ZF issue. My system: PostgreSQL 8.4.13 on i386-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 32-bit Centos6 Php 5.3.4 ZF2.0.* dev-master (via composer) Doctrine 2.02.* dev-master (via composer) - --regards, Nathan Garlington Zend Framework + Dojo http://www.tandrtrailer.com -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/ZF2-ZfcUser-issues-tp4657850.html Sent from the Zend Framework mailing list archive at Nabble.com. -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com
[fw-general] Zend_OpenId_Provider Help & Documentation
Hello, I'm looking for help with Zend_OpenId_Provider. The documentation (http://framework.zend.com/manual/en/zend.openid.provider.html) is very poor, and very hard to understand. Some notes: - The examples are filled with references to example-8.php, example-8-login.php, example-8-trust.php, etc ... But the content of those files is nowhere to be found. - It doesn't mention how to store to the database, and how to use existing user/passwords - It is lacking a complete real world example. It seems to me that the process of logging in via OpenId is almost always the same, so a complete real-world example would be very helpful. Step by step instructions... I've been stuck trying to understand it for a while now: http://stackoverflow.com/questions/3208905/creating-a-openid-provider-in-php PS. Yes, I've posted this in "documentation" as well, but it looks dead there. I guess documentation is not most exciting part of development :) -- Best Regards, Nathan
[fw-general] prefixDefaultModule and modules named 'default' in RC2 and RC3
Hello all, I opened ZF-3951 when a BC break RC2 broke my app. The behaviour I was relying on was set in 1.5.0. I was relying on 'prefixDefaultModule' to allow me to prefix the controllers of my default module, named "default", with *Default*_AsdfController and *Default*_View_Helper. Since 1.6.0RC2, helpers are now prefixed *Zend*_View_Helper, but controller prefixing remains the same. If using the prefixDefaultModule with a module named "default" was never intended, fair enough. But I think the behaviour should be consistent: The exception for modules named "default" should apply to controller class names as well. (With this behaviour, modules which are named "default" but aren't the default would still be functional. This was the only justification for the exception that I could come up with.) That said, it seems unwarranted to have any exception at all based on the module name. When I see 'prefixDefaultModule', I expect the default module to prefixed across the board, without any concern for what the prefix might be. After all, it doesn't say 'prefixDefaultModuleUnlessItsNameIsDefault'. My Issue: http://framework.zend.com/issues/browse/ZF-3951 Original issue for creating the 'prefixDefaultModule' param: http://framework.zend.com/issues/browse/ZF-1831 - Nathan
Re: [fw-general] Hardcoded form decorators and the FormLabel helper
Sorry if I what I said came across as being hostile or presumptuous, I
didn't mean to slight the hard work you've put into Zend_Form.
Your arguments are certainly convincing, I'd just like to mention that
this was the simple use case that my idea for static defaults came from:
Zend_Form_Element::setDefaultDecorators(array(new
Zend_Form_Decorator_ViewHelper));
However, I can certainly see how it might be unnecessarily complex and
confusing to have certain elements override that. I was stuck on
Zend_Form_Element instead of overloading the defaults from within
Zend_Form subclasses. Good call.
I'll submit a unit test and a use case for the FormLabel improvement
shortly.
Thanks for your time,
Nathan
On 03 Mar 2008, at 5:44 AM, Matthew Weier O'Phinney wrote:
-- Nathan <[EMAIL PROTECTED]> wrote
(on Tuesday, 11 March 2008, 04:00 PM -0700):
First and foremost, hard coded default decorators seems suboptimal.
Extending all the elements to define your own defaults isn't much
of an
option, since you'd have to subclass all the element classes. I
realize the
defaults can be bypassed by passing your own decorators to the
element's
constructor, but this isn't always ideal either.
I want to point out a few things here. First, it's hardly "hard
coding"
-- it's providing sane defaults. There *is* a difference -- hard
coding
means you wouldn't be able to change them, and, quite clearly from
your
own explanation, you can.
Let's look at the flexibility availalble here (forgive me if I'm
repeating you a little...):
* You can subclass and override the loadDefaultDecorators() method
* You can pass in decorators when creating elements/forms/etc, which
will prevent the default decorators from loading
* You can even prevent the default decorators from loading at all (by
passing a 'disableLoadDefaultDecorators' option at instantiation)
* You can set all element or display group decorators at once
(setElementDecororators(), setDisplayGroupDecorators())
I'm failing to see how this is not enough flexibility, but, whatever.
I propose that default decorators be loaded from a static array via
addDecorators(). Then the static array could be overridden by calling
Zend_Form_Element::setDefaultDecorators($array). Besides being more
flexible, this also has the potential to improve performance, since
it
would allow you to set your own decorator *instances* and save a
ton of
redundant pluginloader calls. Would this work or am I missing
something?
You're missing a couple fundamental things, actually. First off, not
all
elements use the same set of decorators. The Button, Submit, Reset,
and
Image elements each have a different set of decorators than the other
elements -- and users can define their own elements with their own
defaults. If we use a static member for defining this array, then we
actually *lose* flexibility, as all elements would, out of necessity,
have to use the same set (either that, or we then end up potentially
having more logic and duplicate entries in classes that don't use the
same defaults).
Additionally, your argument of using decorator instances will not
work:
class Foo
{
public static $decorators = array(
new Zend_Form_Decorator_ViewScript()
);
public function getDecorators()
{
return self::$decorators;
}
}
$foo = new Foo;
var_export($foo->getDecorators());
Try the above -- you'll get a parse error. It's not valid PHP. That
means that the only way that using decorator instances would work
with a
static member is if you add them in *MANUALLY* prior to
instantiating your objects. This sounds to me like about the same
amount
of work as doing this:
$decorators = array(
new Zend_Form_Decorator_Foo(),
new Zend_Form_Decorator_Bar(),
new Zend_Form_Decorator_Baz(),
);
$form->setElementDecorators($decorators);
Basically, statics tend to reduce flexibility in the long run as any
class with static members ends up becoming a de facto singleton.
They're
a pain to test, and even worse to extend.
Honestly, I think there's plenty of flexibility already. The thing
about
forms is, you create them once, and use them many times. Start
extending
Zend_Form, and put your logic in your extending class -- then you
have a
single place to debug it, it's not in your controller or model logic,
so you don't have to look at the details when debugging program flow.
My other thought was that the FormLabel View Helper should be able to
accept a Zend_Form_Element, thus saving you from manually calling
ZFE::getName() and ZFE::getLabel().
If you use the Label decorator, you don't have to do this anyways...
I've created an issue on the tracker for this improvement
(ZF-2865), and
included a work
[fw-general] Hardcoded form decorators and the FormLabel helper
Hello all, I'd like to say that after a few solid days of working with Zend_Form, I'm very impressed with its flexibility. I've been using it to create a set of reusable, pluggable form widgets, but that is another discussion altogether. Right now I'd like to discuss a few possible ways of making it more convenient to work with. First and foremost, hard coded default decorators seems suboptimal. Extending all the elements to define your own defaults isn't much of an option, since you'd have to subclass all the element classes. I realize the defaults can be bypassed by passing your own decorators to the element's constructor, but this isn't always ideal either. I propose that default decorators be loaded from a static array via addDecorators(). Then the static array could be overridden by calling Zend_Form_Element::setDefaultDecorators($array). Besides being more flexible, this also has the potential to improve performance, since it would allow you to set your own decorator *instances* and save a ton of redundant pluginloader calls. Would this work or am I missing something? My other thought was that the FormLabel View Helper should be able to accept a Zend_Form_Element, thus saving you from manually calling ZFE::getName() and ZFE::getLabel(). I've created an issue on the tracker for this improvement (ZF-2865), and included a working patch, but I'm a little unsure of the preferred protocol here. Should I assign this to myself? Write a unit test? I couldn't find anything on the dev wiki which explains what's involved nor how you can help to the process along. Any insights would be appreciated, as this is the first open source project I've taken an interest in contributing to. Thanks for reading, Nathan Wright
[fw-general] PluginLoader::load() invoking autoload?
Hello all, While profiling my application I discovered that the pluginloader invokes autoload when it calls class_exists() in the load method. Was this intentional? It could lead to some unexpected behaviour, by loading an ambiguously named class from the wrong location, and it means that Zend_Loader::isReadable() is being called twice as often as is necessary. I've created an issue in the tracker and even posted a patch (as frivolous as that may be) in hopes that this might be fixed before the code freeze tomorrow. http://framework.zend.com/issues/browse/ZF-2458 Thanks for your time, Nathan Wright
Re: [fw-general] Lucene index permissions
Doh--should've (re-)checked first. I updated to the release branch ZSL and it works perfectly. Thanks! On 20-Sep-07, at 9:37 AM, Alexander Veremyev wrote: Hi Nathan, It's ZF-1429. It's fixed and I just committed it to the release branch. So it's included into ZF 1.0.2 which is coming soon. With best regards, Alexander Veremyev. -Original Message- From: Nathan Wright [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2007 10:33 AM To: Zend Framework General Subject: [fw-general] Lucene index permissions Hi all, I have an index that's generated and queried by Apache's 'nobody' user (which works well), but I'm having trouble updating it from a cron job. There is a JIRA issue on this subject (JIRA's currently down so no link), but the workaround solution someone posted wasn't much help. It actually made the indexes inaccessible to both Apache & the cron job after the initial index creation. (Can't post the code as this attempt was some time ago, but I followed that example code *exactly*.) Maybe I need to route the cron job through apache so that the index is being accessed by the same user? I'm not sure how this would work though. I'm not so brilliant when it comes to this sort of *nix issue, so any help would be most appreciated. Cheers, ncw No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.487 / Virus Database: 269.13.25/1018 - Release Date: 19.09.2007 15:59 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.487 / Virus Database: 269.13.25/1018 - Release Date: 19.09.2007 15:59
[fw-general] Lucene index permissions
Hi all, I have an index that's generated and queried by Apache's 'nobody' user (which works well), but I'm having trouble updating it from a cron job. There is a JIRA issue on this subject (JIRA's currently down so no link), but the workaround solution someone posted wasn't much help. It actually made the indexes inaccessible to both Apache & the cron job after the initial index creation. (Can't post the code as this attempt was some time ago, but I followed that example code *exactly*.) Maybe I need to route the cron job through apache so that the index is being accessed by the same user? I'm not sure how this would work though. I'm not so brilliant when it comes to this sort of *nix issue, so any help would be most appreciated. Cheers, ncw
Re: [fw-general] create or manipulate excel documents from within your applications.
This doesn't have anything to do with ZF, but... CSV files are the way to go. http://php.net/fputcsv On 11-Sep-07, at 10:45 PM, rdpweb wrote: Hi All I have implemented an application with ZF.I want to generate bulk report of 500 employees in our organization.I want that report in excel sheet.As their is provision to use PDF with ZF library,like that i want report to be converted in excel sheet. Will anybody help me?How I am proceed? Thanks, Rohit -- View this message in context: http://www.nabble.com/create-or- manipulate-excel-documents-from-within-your-applications.- tf4427095s16154.html#a12628990 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Layout Status ?
Thanks for the quick response, I like how all this is sounding :)
On 11-Sep-07, at 2:33 PM, Matthew Weier O'Phinney wrote:
-- Nathan Wright <[EMAIL PROTECTED]> wrote
(on Tuesday, 11 September 2007, 02:20 PM -0700):
Will layouts still render when ViewRenderer::setNoRender(true) has
been called? That's one of the things I like about the ZVE approach--
you don't have to manipulate two helpers every time you want to
disable view rendering.
I'll take that into consideration. As a rule, I'm against such tight
coupling of components, but this one may make sense.
Will Zend_Layout be limited to 1 layout per request?
The default implementation renders the layout during
dispatchLoopShutdown(). However, Zend_Layout itself is simply a class
and can be instantiated as many times as you want -- so you could
theoretically render several layouts in a given request.
At first I was skeptical of Padriac Brady's talk of the controller-
centricity of ZF, but I think he's onto something. Why shouldn't you
be able to override the default layout from within a view script on a
case by case basis? [By calling $this->setLayout('non-default.phtml')
from a view.]
I plan on having a view helper that allows you to access the layout
instance registered with the controller plugin, so yes, you'll be able
to do this. The usage will most likely be:
$this->layout()->setLayout('non-default');
or something similar (i.e., returning the layout object, and then
allowing you to call methods on it).
Maybe I should be looking at implementing a full composite view or
something if this sort of use case falls outside 80/20.
Between ZVE and Zend_Layout, you should have everything you need. :-)
On 11-Sep-07, at 12:35 PM, Matthew Weier O'Phinney wrote:
-- Philip G <[EMAIL PROTECTED]> wrote
(on Tuesday, 11 September 2007, 02:25 PM -0500):
On 8/18/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:
-- PotatoBob <[EMAIL PROTECTED]> wrote
(on Friday, 17 August 2007, 11:33 PM -0700):
I sure hope default module layouts and a setConfig() feature are
added to
zend_layout :(
Ralph and I were discussing Zend_Layout yesterday. The current
design
we're looking at would have a default layout, and allow
specifying the
layout to use either via a setLayout() accessor or as an
argument to a
render() method.
Just jumping in to put my two cents in -- this is exactly what I'm
looking for (setLayout() option). I originally built a layout
support,
of this exact same model, on top of Zend_View in ZF ~0.6. In my
research to figure out Zend_View changes, I ran across this post.
I'm
still figuring out what changed in Zend_View, but this is what I'm
looking for. I'm actually rather shocked this option wasn't added
with
1.0.
To be clear, setLayout() will be part of a separate class,
Zend_Layout.
Zend_View will not have any concept of layouts by itself.
Layouts as created in most frameworks are simply views with
placeholders
for content -- in other words, a decorator for an application view.
Zend_Layout will operate in a similar fashion, and register a plugin
with dispatchLoopShutdown() to perform its work.
Layout support was not done for 1.0.0 as we'd only just finalized
things
like integrated view support for controllers (via the ViewRenderer),
and action helpers -- the building blocks on which a layout solution
will be based.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend_Layout Status ?
Will layouts still render when ViewRenderer::setNoRender(true) has
been called? That's one of the things I like about the ZVE approach--
you don't have to manipulate two helpers every time you want to
disable view rendering.
Will Zend_Layout be limited to 1 layout per request?
At first I was skeptical of Padriac Brady's talk of the controller-
centricity of ZF, but I think he's onto something. Why shouldn't you
be able to override the default layout from within a view script on a
case by case basis? [By calling $this->setLayout('non-default.phtml')
from a view.] Maybe I should be looking at implementing a full
composite view or something if this sort of use case falls outside
80/20.
Cheers,
ncw
On 11-Sep-07, at 12:35 PM, Matthew Weier O'Phinney wrote:
-- Philip G <[EMAIL PROTECTED]> wrote
(on Tuesday, 11 September 2007, 02:25 PM -0500):
On 8/18/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:
-- PotatoBob <[EMAIL PROTECTED]> wrote
(on Friday, 17 August 2007, 11:33 PM -0700):
I sure hope default module layouts and a setConfig() feature are
added to
zend_layout :(
Ralph and I were discussing Zend_Layout yesterday. The current
design
we're looking at would have a default layout, and allow
specifying the
layout to use either via a setLayout() accessor or as an
argument to a
render() method.
Just jumping in to put my two cents in -- this is exactly what I'm
looking for (setLayout() option). I originally built a layout
support,
of this exact same model, on top of Zend_View in ZF ~0.6. In my
research to figure out Zend_View changes, I ran across this post.
I'm
still figuring out what changed in Zend_View, but this is what I'm
looking for. I'm actually rather shocked this option wasn't added
with
1.0.
To be clear, setLayout() will be part of a separate class,
Zend_Layout.
Zend_View will not have any concept of layouts by itself.
Layouts as created in most frameworks are simply views with
placeholders
for content -- in other words, a decorator for an application view.
Zend_Layout will operate in a similar fashion, and register a plugin
with dispatchLoopShutdown() to perform its work.
Layout support was not done for 1.0.0 as we'd only just finalized
things
like integrated view support for controllers (via the ViewRenderer),
and action helpers -- the building blocks on which a layout solution
will be based.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Is there allready some kind of zf-create script ?
At our office we manage about 30 ZF applications and make a few new ones every month or so. We've made a set PHP classes to generate MVC classes for these new projects. The generator library is"ZF-compatable" (as in they can be autoloaded by ZF's autoloader and follow other ZF conventions). I'm currently slapping together a few basic HTML forms to drive the library so we can create new ZF projects from the browser. I don't think it'd be something that really fits well into the Framework it self, but if other people find it interesting I can package it up and make it available (I might need to modify some things, since it's coupled with some of our own library classes). Is anyone else offering "ZF compatible" libraries? If so, how are you packaging them and where are they available? If people are already doing this I'd like to follow convention. Also we've extended Zend_Db_Adapter (only Pdo_MySQL right now) to lookup the foreign keys in a database. We can then autogenerate the Zend_Db_Table classes for a particular database with relationships already filled in. I've intended to write up the describeForeignKeys() (or describeConstraints(), or whatever) functionality in a proposal, but haven't found the time to do so. -Nathan Truppe Steven wrote: Hi again, i wonder if there is a script that creates the basic directory structure and files needed for every new zend project. i think this would be a nice feature (when it can get a bit customized so that the user can set the structure like he wants and the script does the needed stuff for the bootstrap file!) i haven't found such a tool yet so i start writing one, at the moment only for my personal education, i hope this will help some people getting started with the zend framework much faster. maybe someone finds the idea interessting and reply to this message. best regards, Truppe Steven
Re: [fw-general] Problem in Router Rewrite
I do not remember if this is the case or not, but I believe you have to attach "/*" to the end of routes that you want to allow parameters on. For instance: Route: /:module/:lang/:controller/:action/* URL: /admin/en/employee/add/id/2 Should work as expected. With out that '/*' at the end, I believe the router will ignore the trailing parameters, or ignore your route all together and use the default route ( /:module/:controller/:action/* ) Hope that's relevant. -Nathan Bell ashish.sharma wrote: Hello, It's really a gr8 forum for a developer like me who is learning Zend and facing so many technical issues/problems. I have resolved many problems by my own using the help available and by the help of some members on this forum. Thanks to all. The problem now I am facing is related with Router rewrite .. here is the problem. I am creating a multi-lingual site and I am using the following router rewrite string in my BOOTSTRAP file. :module/:lang/:controller/:action Which results the URL as : admin/en/employee/add .. which is working fine and I am able to open the add section and can add records. In the above URL it is returning me the right names of module, controller & action if I use requests's methods to print them i.e. getModuleName, getControllerName etc .. Now the problem comes when i click on "edit entry" which is having a URl like admin/en/employee/edit/id/2 .. this is not working fine and redirect to Access denied page as i have implemented ACL. But I have provided "edit" permission to the User = "ADMIN" and i am logged in with the same User. When i print the Module & Controller name it is giving "en" as controller. I feel that this is causing the problem. On further tracking i found that whenever i use and parameter next to action .. add or edit it gives me the error. Any suggestions ? Thanks Ashish Sharma View this message in context: Problem in Router Rewrite <http://www.nabble.com/Problem-in-Router-Rewrite-tf4260472s16154.html#a12124134> Sent from the Zend Framework mailing list archive <http://www.nabble.com/Zend-Framework-f15440.html> at Nabble.com.
Re: [fw-general] Using Zend Studio 5.5.0 Debugger
Usually Zend Debugger works fine for me, but I've run into some strange problems like this too. Could never figure out what was actually causing it though. Once it happened when I extended Zend_Controller_Action. I got the same 'Cannot redeclare class' error even when using Zend_Loader::registerAutoload(). Eventually I tried adding the Zend folder itself to the root of my ZDE project and it worked. Another time I was trying out the proposal code of Zend_View Enhanced. I renamed everything to Zps_View but once again I got a 'cannot redeclare class' error with Zend_View_Abstract as the culprit. I stepped through the code, and it was occurring in Zps/View/ Abstract.php declaring Zps_View_Abstract. This time, adding the Zend and Zps folders to the root did nothing. I tried rebuilding inspection data but that didn't help any either. I'm using ZDE 5.2.0 on OSX. ncw On 30-Jul-07, at 10:33 AM, Liao, Kexiao wrote: Dear Zend Framework Development Team, I am trying to use Zend Studio 5.5.0 IDE to Debug the demo codes (ZFGridDemo) from zend.com/webinar. Following error message show up when I try to execute following statement from zfgrid/document_root/ index.php file: $db = Zend_Db::factory( $config->database->adapter, $config->database->params->toArray() ); Fatal error: Cannot redeclare class Zend_Db_Adapter_Abstract in / home/liaok/wwwroot/ZendFramework-1.0.0/library/Zend/Db/Adapter/ Abstract.php on line 51 The Demo codes work well without using Zend Studio 5.5.0 Debugger function. Does that mean that Zend Studio 5.5.0 Debugger can not work for Zend Framework? Thanks for your comment. Kevin === Cleveland Clinic is ranked one of the top hospitals in America by U.S. News & World Report (2007). Visit us online at http://www.clevelandclinic.org for a complete listing of our services, staff and locations. Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you.
[fw-general] Using a Zend_Db_Select object with Zend_Db_Table to return a Zend_Db_Table_Rowset object
My Zend_Db_Table classes seem more complicated to write than they have to be because when I write my own queries using Zend_Db_Select objects, I have to build my own Zend_Db_Table_Rowset objects. Does Zend_Db_Table_Abstract not provide methods for returning a Zend_Db_Table_Rowset object based on a Zend_Db_Select object? Is there a reason for this? Thanks -Nathan
Re: [fw-general] Zend_View_Helper_FormCheckbox
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
Re: [fw-general] Front controller
Tomek, You're in luck because that's how ZF typically routes requests. The manual really isn't the easiest way to get started, I recommend Rob Allen's tutorial http://akrabat.com/zend-framework-tutorial/ Nathan On 3-Jul-07, at 1:32 PM, Tomek Klas wrote: Hi, I have always planned to use ZF when it makes it to release 1, so here I am. it all looks pretty good, but I have a question. I need to be able to route the requests to different controllers, depending on the url, e.g. example.com/news/ example.com/blog/ example.com/contact/ I know it's being controlled by front controller (possibly different modules or use setControllerDirectory), but the example on http://framework.zend.com/manual/en/zend.controller.front.html does not seem to work Could someone shed some light on this for me please? it is stopping me from steaming ahead with my learning project. thank you Tomek
[fw-general] Routing issues
We're seeing issues with RC3 (RC2 and RC1 work as expected): http://example.com/controller/action routes to indexController -> indexAction http://example.com/index.php/controller/action routes properly to controllerController -> actionAction What has changed in RC3 that could cause this? Tried stripping our bootstrap file to the bare minimum, still having issues. [ .htaccess ] RewriteEngine on RewriteRule !\.(js|ico|GIF|JPG|gif|jpg|png|css|swf)$ index.php I notice at least two others have posted similiar issues here. Anyone able to fix it?
Re: [fw-general] An Alternative View
Most of what you're suggesting is already possible with the current view and front controller. I do like the view plugins idea. Although front controller plugins are capable of the same functions, this seems like it would make some tasks simpler. Whether or not its worth the added complexity is debatable. Views already have helpers, with which wrappers and 'filters' could be implemented. ViewRenderer can already be replaced with your own class with the Zend_Controller_Action_HelperBroker. Although I've never liked the way the ViewRenderer is named (34 characters is a tad verbose) its current implementation does have some real advantages. - Nathan. On 9-Jun-07, at 5:49 PM, pat wrote: To List, I’m not happy with the current View implementation. First I’ll layout my criticism, then suggest what I think may be an answer. I realize this won’t make it into the next release or anything like that but, I would like to know what people think about it Basically, what I want is for the View to be more like the Controller. I want it beefier, meatier, able to stand on its own as part of the MVC. The MVC needs more V. As things stand now, the View has all but disappeared into the Controller’s Action helper. It needs to be brought out and made a powerful component in its own right. The viewRenderer should be a plug-in for the View, not the other way around. The viewRenderer should be to the View, what the router is to the Front Controller. People could then use a default viewRenderer or slot in a custom viewRenderer, just as they now can change routers. The View should be able to host plug-ins like the Front Controller does. The plug-ins could have methods like preRender, postRender to allow for such things as selecting skins for the page (preRender) or running the page through tidy (postRender). The view should have helpers. In particular, there are two helper classes worth considering. View_Wrappers and View_Filters. Wrappers add to, filters take away. Suppose you have a row from a database and you only want the 1st, 3rd and 5th . You might write: $info = filter(array(‘1’,’3’,’5’), $row); A wrapper might follow the decorator pattern and do something like this: $list = wrap(‘list’,$array); // creates an html list out of an array Wrappers can be chained together. There are lots of things to be puzzled out, but the above is the gist. Implementation shouldn’t be too hard. Much of the design for plug- ins and such can come from the Front Controller. Instead of extending the view class, a new class named Zend_Alternative_View or something could be used. This way you could use the old View while proto-typing the new Zend_Alternative_View. So, what do you say? Could it be ready for Zend 2.0? Pat.
[fw-general] Preset style in Zend_View_Helper_FormRadio
I've been doing lots of work involving forms lately and thus far I've been pretty happy with the view helpers shipped with ZF. My only complaint is a trivial one. The radio helper wraps each option in a label, which is great, but it adds a 'style="white-space: nowrap;"' attribute which can't be (entirely) removed. I'm assuming this is so that the label is never bumped down to the following line, orphaning the checkbox? Whatever the reason, I think this attribute should be removed entirely OR enabled by default but fully removable. It belongs in a CSS file, not in the XHTML. Currently, passing the attribute 'label_style' => null just renders as . Is there ever a case where you would need an empty attribute in the XHTML? Like I said, trivial ;-) Nathan Wright.
[fw-general] Zend_Db_Expr
Is there plans to make Zend_Db_Expr work on insert data? It doesn't
appear to be evaluated currently:
$row = array (
'noble_title'=> 'King',
'first_name' => 'Arthur',
'created'=> new Zend_Db_Expr("NOW()")
);
$rows_affected = $db->insert('people', $row);
$last_insert_id = $db->lastInsertId();
[fw-general] quoteIdentifier not used in Zend_Db_Adapter_Abstract
Is there a reason that the function 'quoteIdentifier' is not used in the class Zend_Db_Adapter_Abstract? Shouldn't at least the methods 'insert' and 'update' be quoting the names of columns passed to them? We had a lot of problems migrating over an existing database application to the ZF because we had column names that had to be quoted before they could be used in queries. What is the reasoning behind not automatically quoting column names? Thanks, -Nathan
Re: [fw-general] List issues?
I was having trouble subscribing yesterday. Just got subscription confirmation (about 5 times) just now. -n8 Abu Hurayrah wrote: Is anyone else experiencing delayed messages coming from the list? I'm working with someone on a project using ZF, and she attempted to send a message to the list, and it never went through (yet). She just signed-up, so I don't know if her message needs to be moderated before it will post, or if there is just a delay for all messages. Let's see if this makes it through.
