Re: [fw-general] Zend_Form File Element / Decorator - Extremely Confuzzled
Thanks heaps Daniel and Thomas. I had actually visited that particular FAQ page before, but I thought it a dead-end or login-required page when in fact I now realise that it was due to the horrible internet connection that I have here that the FAQ questions failed to render as a link. In any case, the FAQ cleared up the confusion I had on the file element. At the moment, going through the slides to see what else I can learn. Thanks again! :) -- View this message in context: http://www.nabble.com/Zend_Form-File-Element---Decorator---Extremely-Confuzzled-tp25365664p25377044.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] zf tool: no way to delete yet?
Hey David, Are you on zftalk.dev? Both Benjamin and myself are typically in the room and I'd be more than happy to help you start tooling around with zend_tool in order to both become productive to it as well as extend and enhance it. Delete is actually probably pretty easy to implement and would love to see people start contributing all sorts of functionality and features. -ralph David Mintz wrote: On Tue, Sep 8, 2009 at 11:55 PM, Ralph Schindler mailto:ralph.schind...@zend.com>> wrote: Hey David, [delete] functionality is slated for 1.10. It was left out of the 1.8 and 1.9 release for a couple of good reasons. Since deleting is a pretty irreversible action, and sometimes is also a recursive action- we wanted to ensure that the console/cli interface at least had the capability to ask the user if deleting is OK, in other words confirming the decision to delete something. This way, people will not accidentally delete things they will not be able to recover. I wonder -- how hard is it to implement? I ask because I might like to contribute, but if you guys are black belts, I am like, a yellow belt -- maybe green on a good day -- so don't know if I am equal to the task. -- David Mintz http://davidmintz.org/ The subtle source is clear and bright The tributary streams flow through the darkness
Re: [fw-general] Zend_Entity: Using it in a fully model-driven manner
Chris Murray wrote: > > So I need to be able to dynamically set the property list in Zend_Entity > Another possible approach would be to create my own def object generator. I already have my definitions in my model and they are used for other purposes, such as form element configs, formatting, and display properties. So, I could build the def object and pass it to Zend_Entity_MetadataFactory_Code (rather than passing in a file path). That way, I don't have to create multiple def files for each unique combination of properties that are used in my application. Instead, just build the def object dynamically based on already existing, multi-purpose object property lists and their individual attributes. Is that a better way to do it? -- View this message in context: http://www.nabble.com/Zend_Entity%3A-Using-it-in-a-fully-model-driven-manner-tp25374495p25374989.html Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Zend_Entity: Using it in a fully model-driven manner
Zend_Entity looks promising so I dove into it today and was trying to figure out how to map my existing model-driven ORM architecture into it. My experimental goal is to use Entity as the (fatter) bottom layer of my base "Model" class and replace my abstracted CRUD methods, which currently call Db_Table, with abstracted Entity methods. My application determines its list of object properties at run time, based on the user's role and the action. As mentioned, the base Model class uses Db_Table for CRUD, but I'd like it to instead call a stub class for each entity and then dynamically build the Entity class based on the dynamic list of properties which of course are a subset of the metadata defs. The stub class will allow for easily overriding or adding to abstract methods if needed. So I need to be able to dynamically set the property list in Zend_Entity, perhaps in the constructor or by iterating over the properties and calling setters and getters as needed. My preference of course is that method names in Entity allow for complete abstraction, so that all calls can be abstracted into my base Model class (or at least as many as possible). It appears that this is currently doable, even encouraged, but I'd like to make sure this is an expected use of Zend_Entity so I don't run into incompatibilities later. Is this an expected use? Any comments on this approach? Thanks, Chris -- View this message in context: http://www.nabble.com/Zend_Entity%3A-Using-it-in-a-fully-model-driven-manner-tp25374495p25374495.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Form clearErrorMessages vs. clone the object
What exactly is the feature request?
For batch form operations, a new Zend_Form method named something like
"clearAndPrepForRePopulate()". It would recursively clearAllMessages(),
including those in all elements and subForms, as well as set _errorsExist to
FALSE.
So it would like:
$form = getForm();
foreach($dataSet as $record) {
$form->populate($record);
if($form->isValid)
// do CRUD...
else
// handle errors...
$form->clearAndPrepForRePopulate();
}
If you check out Zend_Form, it has been designed such that when its
> cloned, it will actually enforce cloning throughout all of its consumed
> objects (elements, sub-forms, and display groups). So it is already
> capable of being "safely" cloned.
Thanks for the confirmation that cloning is the best way. I'd guess that a
clearAndPrepForRePopulate() method would be faster than cloning, but for now
I'll just create a static $form and clone it for each iteration of the batch
operation. If performance is poor I'll extend Zend_Form and try my own
clearAndPrepForRePopulate().
Thanks!
Chris
--
View this message in context:
http://www.nabble.com/Zend_Form-clearErrorMessages-vs.-clone-the-object-tp25285029p25373853.html
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Default project structure - forms directory
On the manual page for default project structure (http://framework.zend.com/manual/en/project-structure.project.html), shouldn't there also be a /forms/ directory under "application"?
Re: [fw-general] zf tool: no way to delete yet?
On Wednesday 09 September 2009 06:47:49 pm David Mintz wrote: > On Wed, Sep 9, 2009 at 10:13 AM, Benjamin Eberlei wrote: > > Don't underestimate yourself :-) We are always happy for any help > > and ralph would probably mentor you through the process if you would > > dedicate yourself to implementing this (and he hasn't started yet). > > > > If you seperate the Provider and the actual deletion, you can probably > > get this working by writing some tests for all the possible cases you can > > up with without too many problems. > > > > You should check out the Trunk documentation on Writing Providers it got > > several updates that should help you with some of the details on how > > to write a provider. I am thinking about updating it further to include > > details on the Project specific provider options. > > First noob question: when you say check out the trunk documentation, you > mean svn checkout http://framework.zend.com/svn/framework/standard/trunk, > cd into documentation/manual/ and build as per the README. > Right? yes, but its only in EN right now, so =en. -- Benjamin Eberlei http://www.beberlei.de
Re: [fw-general] zf tool: no way to delete yet?
On Wed, Sep 9, 2009 at 10:13 AM, Benjamin Eberlei wrote: > > Don't underestimate yourself :-) We are always happy for any help > and ralph would probably mentor you through the process if you would > dedicate yourself to implementing this (and he hasn't started yet). > > If you seperate the Provider and the actual deletion, you can probably get > this working by writing some tests for all the possible cases you can up > with without too many problems. > > You should check out the Trunk documentation on Writing Providers it got > several updates that should help you with some of the details on how > to write a provider. I am thinking about updating it further to include > details on the Project specific provider options. > First noob question: when you say check out the trunk documentation, you mean svn checkout http://framework.zend.com/svn/framework/standard/trunk, cd into documentation/manual/ and build as per the README. Right? -- David Mintz http://davidmintz.org/ The subtle source is clear and bright The tributary streams flow through the darkness
Re: [fw-general] view helpers within a view helper
Thanks for all. yes I also think that this way is inefficient.I should use join for this purpose,Thanks again for all -- View this message in context: http://www.nabble.com/view-helpers-within-a-view-helper-tp25351769p25368712.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Controllers that respond to both "normal" requests and RESTful requests
-- Cameron wrote (on Wednesday, 09 September 2009, 05:35 PM +0800): > Hi, this is very likely to be a dumb question, but I'd really like to have my > controllers respond to "normal" requests (as in http://domain.com/product/ > display/id/1) and also the full range of RESTful requests (GET http:// > domain.com/product/1 and so on). Turning on Zend_Rest_Route across all my > controllers breaks regular requests, but does make them respond correctly to > REST, but yeah... I know this is unlikely to work, I was just wondering if > there's a way of somehow ordering the routes so that if regular ones don't > match then use the RESTful ones or something. Failing that, I suppose I'm just > going to have to come up with a nice clean way to link the separate REST > controllers back to the "normal" code. You can do it in a variety of ways. First, you can always use the default route in conjunction with the Rest route, though you run the risk of the actions being interpreted as IDs. Another option is to create an additional Zend_Controller_Router_Route instance that matches your controller: $route = new Zend_Controller_Router_Route( 'product/:action/*', array( 'controller' => 'product', ), array( 'action' => '^[a-z][a-z0-9.-]+', ) ); Assuming your IDs are numeric, the above will not match unless the action starts with an alphabetic character -- which should be safe for your purposes. (You can also use static and regexp routes in this fashion.) If you use such a route, make sure you register it *after* the REST route to ensure it's executed *before* it. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/
Re: [fw-general] Zend_Form File Element / Decorator - Extremely Confuzzled
Take a look into the FAQ where the problem, the reason and the solution is
described:
http://framework.zend.com/wiki/display/ZFFAQ/Forms
Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com
- Original Message -
From: "Jayawi"
To:
Sent: Wednesday, September 09, 2009 4:03 PM
Subject: [fw-general] Zend_Form File Element / Decorator - Extremely
Confuzzled
Hi there~
I'm relatively new to ZF but have enjoyed using it so far. The main issue
I've had with ZF is with it's Form and Decorator aspects. After going
through God knows how many articles/blogs/posts and what not, I thought I
finally had a grasp of it. Things were working okay.
I created a standard set of decorators (for Elements, Buttons and Forms)
based on an example I saw. Recently however, I realised that I needed to
add
in some File Input fields into one of the forms. None of the above
decorators worked with it. At which point, I decided to use ViewScripts on
all the forms since it provides greater room to stylise/organise the form.
The code I'm currently using, looks something like the following:
site/application/forms/RegisterForm.php
class ProjectStartContactPersonForm extends Gid_Form
{
public function init ()
{
$this->setAction('')
->setMethod('post')
->setAttrib('id','formStartProject')
->setAttrib('enctype', 'multipart/form-data');
$this->addElement('text', 'textName', array('label' => 'Given Name'));
$oName = $this->getElement('textName')
->setRequired(true)
->setDecorators(array('ViewHelper', 'Errors'));
$this->addElement('file', 'filePhotograph');
$oPhotograph = $this->getElement('filePhotograph')
->setRequired(true);
$this->addElement('submit', 'submitRegister', array('label' => 'Done'));
$oContactPersonSubmit = $this->getElement('submitRegister');
$oContactPersonSubmit->setDecorators(array('ViewHelper', 'Errors'));
$this->setDecorators(array(array('ViewScript', array('viewScript' =>
'forms/RegisterForm.phtml';
}
}
site/application/views/scripts/forms/RegisterForm.phtml
Name:
element->textName; ?>
Photo:
element->filePhotograph; ?>
element->submitRegister; ?>
From RegisterForm.php I had to change $this->addElement('file',
'filePhotograph', array('label' => 'Photo')); to get it to work. prior to
that, the File Input element was being displayed twice.
Additionally, if ->setDecorators(array('ViewHelper', 'Errors')) was
attached
to the File Input object, it would throw the error "Warning: No file
decorator found... unable to render file element in
C:\xampp\xampp\php\PEAR\Zend\Form\Element.php on line 1929".
I honestly can't understand what the issue is or how I'm supposed to
resolve
it. All the searching and reading I did lead me to more questions and no
solution. Some of them dealt with the lack of a File Input Class in ZF
(which I believe was a somewhat early release), while others used custom
classes for things which didn't really clarify anything for me.
Currently, the File Input Element is rendered as follows:
Photo:
I would like to get it outside of those dt/dd tags (which suggest the
default ZF Decorators are being applied).
ZF Documentation I find stragely lacking in the various
methods/variables/parameters to use. If anyone knows of a better
reference,
it's sure to help a great deal.
I would greatly appreciate any help anyone can provde me on this.
Thanks~
--
View this message in context:
http://www.nabble.com/Zend_Form-File-Element---Decorator---Extremely-Confuzzled-tp25365664p25365664.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Debug Warning Zend Loader line 165
Hi Ralph, Thanks - I really appreciate the response, the clarification, and knowing that it will be possible to address this in the future. -Ed > This is correct behavior. The debugger in studio is throwing a warning in a > situation where PHP has already suppressed the error. FYI, Zend_Loader is > using the only technique available in the php 5.2 series to locate a file on > the include_path. Other techniques are completely userland based and > extremely slow and non-performant. >> The second concern is that there might be some sort of overhead >> involved in generating these warnings. Wouldn't resolving this issue >> improve the overall performance of my application? > > As mentioned before, this is the most ideal solution for 5.2. Also, the > performance cost is negligible. When 5.3 rolls around as well as ZF 2.0, > there are several language level features we'll be able to leverage to > remove this limitation and warnings you are seeing.
Re: [fw-general] Zend_Form File Element / Decorator - Extremely Confuzzled
2009/9/9 Daniel Latter
> Hi,
>
> Have a look at this:
> http://www.slideshare.net/NickBelhomme/zend-framework-form-mastering-decorators
>
> Also regarding your code, the "HtmlTag" decorator is being applied so you
> can try and set that, also you can try and clear the default
> decorators.
>
> The *default* *decorators* on an element are:
>
> • ViewHelper
> • Errors
> • Description (only renders if a description is set)
> • HtmlTag
> • Label
>
> Try $element->*removeDecorator*('HtmlTag ');
>
> Thanks
> Daniel
>
> 2009/9/9 Jayawi
>
>
>> Hi there~
>>
>> I'm relatively new to ZF but have enjoyed using it so far. The main issue
>> I've had with ZF is with it's Form and Decorator aspects. After going
>> through God knows how many articles/blogs/posts and what not, I thought I
>> finally had a grasp of it. Things were working okay.
>>
>> I created a standard set of decorators (for Elements, Buttons and Forms)
>> based on an example I saw. Recently however, I realised that I needed to
>> add
>> in some File Input fields into one of the forms. None of the above
>> decorators worked with it. At which point, I decided to use ViewScripts on
>> all the forms since it provides greater room to stylise/organise the form.
>>
>> The code I'm currently using, looks something like the following:
>>
>> site/application/forms/RegisterForm.php
>> class ProjectStartContactPersonForm extends Gid_Form
>> {
>>public function init ()
>>{
>>$this->setAction('')
>>->setMethod('post')
>>->setAttrib('id','formStartProject')
>>->setAttrib('enctype',
>> 'multipart/form-data');
>>
>>$this->addElement('text', 'textName', array('label' =>
>> 'Given Name'));
>>$oName = $this->getElement('textName')
>>->setRequired(true)
>>
>> ->setDecorators(array('ViewHelper', 'Errors'));
>>
>>$this->addElement('file', 'filePhotograph');
>>$oPhotograph = $this->getElement('filePhotograph')
>>->setRequired(true);
>>
>>$this->addElement('submit', 'submitRegister', array('label'
>> => 'Done'));
>>$oContactPersonSubmit =
>> $this->getElement('submitRegister');
>>$oContactPersonSubmit->setDecorators(array('ViewHelper',
>> 'Errors'));
>>
>>$this->setDecorators(array(array('ViewScript',
>> array('viewScript' =>
>> 'forms/RegisterForm.phtml';
>>}
>> }
>>
>> site/application/views/scripts/forms/RegisterForm.phtml
>>
>>
>>
>>
>>> for='textName'>Name:
>>element->textName;
>> ?>
>>
>>
>>> for='filePhotograph'>Photo:
>>> $this->element->filePhotograph; ?>
>>
>>
>>
>>> $this->element->submitRegister; ?>
>>
>>
>>
>>
>>
>> From RegisterForm.php I had to change $this->addElement('file',
>> 'filePhotograph', array('label' => 'Photo')); to get it to work. prior to
>> that, the File Input element was being displayed twice.
>> Additionally, if ->setDecorators(array('ViewHelper', 'Errors')) was
>> attached
>> to the File Input object, it would throw the error "Warning: No file
>> decorator found... unable to render file element in
>> C:\xampp\xampp\php\PEAR\Zend\Form\Element.php on line 1929".
>> I honestly can't understand what the issue is or how I'm supposed to
>> resolve
>> it. All the searching and reading I did lead me to more questions and no
>> solution. Some of them dealt with the lack of a File Input Class in ZF
>> (which I believe was a somewhat early release), while others used custom
>> classes for things which didn't really clarify anything for me.
>>
>> Currently, the File Input Element is rendered as follows:
>>
>>Photo:
>>
>>
>>> id="filePhotograph">
>>
>>
>>
>> I would like to get it outside of those dt/dd tags (which suggest the
>> default ZF Decorators are being applied).
>> ZF Documentation I find stragely lacking in the various
>> methods/variables/parameters to use. If anyone knows of a better
>> reference,
>> it's sure to help a great deal.
>>
>> I would greatly appreciate any help anyone can provde me on this.
>> Thanks~
>> --
>> View this message in context:
>> http://www.nabble.com/Zend_Form-File-Element---Decorator---Extremely-Confuzzled-tp25365664p25365664.html
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>>
>
Re: [fw-general] zf tool: no way to delete yet?
Don't underestimate yourself :-) We are always happy for any help and ralph would probably mentor you through the process if you would dedicate yourself to implementing this (and he hasn't started yet). If you seperate the Provider and the actual deletion, you can probably get this working by writing some tests for all the possible cases you can up with without too many problems. You should check out the Trunk documentation on Writing Providers it got several updates that should help you with some of the details on how to write a provider. I am thinking about updating it further to include details on the Project specific provider options. Anyhow, if you ask on IRC #zftalk.dev you probably get all the details you need much faster on how you can help. greets, Benjamin On Wed, 9 Sep 2009 09:30:24 -0400, David Mintz wrote: > On Tue, Sep 8, 2009 at 11:55 PM, Ralph Schindler > wrote: > >> Hey David, >> >> [delete] functionality is slated for 1.10. It was left out of the 1.8 >> and >> 1.9 release for a couple of good reasons. Since deleting is a pretty >> irreversible action, and sometimes is also a recursive action- we wanted >> to >> ensure that the console/cli interface at least had the capability to ask >> the >> user if deleting is OK, in other words confirming the decision to delete >> something. This way, people will not accidentally delete things they >> will >> not be able to recover. >> >> > I wonder -- how hard is it to implement? I ask because I might like to > contribute, but if you guys are black belts, I am like, a yellow belt -- > maybe green on a good day -- so don't know if I am equal to the task.
Re: [fw-general] view helpers within a view helper
And I think you should consider using the Models (DbTable) and not the Helpers for those operations. rgds Armand > > neobeacon wrote: >> I create a view helper to show comments for a article.(by getting >> article_id >> from comments table and using foreach to get each comment). >> >> But in comment table only has commentator's id. >> >> I used a view helper to convert user_id to get the user name. >> >> With in a view helper can I call another view helper? >> >> How do I handle this case? >>
Re: [fw-general] view helpers within a view helper
You should really use a join query for this, so that the comment resultset has all the info available already in it, the way you are doing it is quite inefficient neobeacon wrote: I create a view helper to show comments for a article.(by getting article_id from comments table and using foreach to get each comment). But in comment table only has commentator's id. I used a view helper to convert user_id to get the user name. With in a view helper can I call another view helper? How do I handle this case?
[fw-general] Zend_Form File Element / Decorator - Extremely Confuzzled
Hi there~
I'm relatively new to ZF but have enjoyed using it so far. The main issue
I've had with ZF is with it's Form and Decorator aspects. After going
through God knows how many articles/blogs/posts and what not, I thought I
finally had a grasp of it. Things were working okay.
I created a standard set of decorators (for Elements, Buttons and Forms)
based on an example I saw. Recently however, I realised that I needed to add
in some File Input fields into one of the forms. None of the above
decorators worked with it. At which point, I decided to use ViewScripts on
all the forms since it provides greater room to stylise/organise the form.
The code I'm currently using, looks something like the following:
site/application/forms/RegisterForm.php
class ProjectStartContactPersonForm extends Gid_Form
{
public function init ()
{
$this->setAction('')
->setMethod('post')
->setAttrib('id','formStartProject')
->setAttrib('enctype', 'multipart/form-data');
$this->addElement('text', 'textName', array('label' => 'Given
Name'));
$oName = $this->getElement('textName')
->setRequired(true)
->setDecorators(array('ViewHelper', 'Errors'));
$this->addElement('file', 'filePhotograph');
$oPhotograph = $this->getElement('filePhotograph')
->setRequired(true);
$this->addElement('submit', 'submitRegister', array('label' =>
'Done'));
$oContactPersonSubmit = $this->getElement('submitRegister');
$oContactPersonSubmit->setDecorators(array('ViewHelper',
'Errors'));
$this->setDecorators(array(array('ViewScript',
array('viewScript' =>
'forms/RegisterForm.phtml';
}
}
site/application/views/scripts/forms/RegisterForm.phtml
Name:
element->textName; ?>
Photo:
element->filePhotograph;
?>
element->submitRegister;
?>
>From RegisterForm.php I had to change $this->addElement('file',
'filePhotograph', array('label' => 'Photo')); to get it to work. prior to
that, the File Input element was being displayed twice.
Additionally, if ->setDecorators(array('ViewHelper', 'Errors')) was attached
to the File Input object, it would throw the error "Warning: No file
decorator found... unable to render file element in
C:\xampp\xampp\php\PEAR\Zend\Form\Element.php on line 1929".
I honestly can't understand what the issue is or how I'm supposed to resolve
it. All the searching and reading I did lead me to more questions and no
solution. Some of them dealt with the lack of a File Input Class in ZF
(which I believe was a somewhat early release), while others used custom
classes for things which didn't really clarify anything for me.
Currently, the File Input Element is rendered as follows:
Photo:
I would like to get it outside of those dt/dd tags (which suggest the
default ZF Decorators are being applied).
ZF Documentation I find stragely lacking in the various
methods/variables/parameters to use. If anyone knows of a better reference,
it's sure to help a great deal.
I would greatly appreciate any help anyone can provde me on this.
Thanks~
--
View this message in context:
http://www.nabble.com/Zend_Form-File-Element---Decorator---Extremely-Confuzzled-tp25365664p25365664.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] zf tool: no way to delete yet?
On Tue, Sep 8, 2009 at 11:55 PM, Ralph Schindler wrote: > Hey David, > > [delete] functionality is slated for 1.10. It was left out of the 1.8 and > 1.9 release for a couple of good reasons. Since deleting is a pretty > irreversible action, and sometimes is also a recursive action- we wanted to > ensure that the console/cli interface at least had the capability to ask the > user if deleting is OK, in other words confirming the decision to delete > something. This way, people will not accidentally delete things they will > not be able to recover. > > I wonder -- how hard is it to implement? I ask because I might like to contribute, but if you guys are black belts, I am like, a yellow belt -- maybe green on a good day -- so don't know if I am equal to the task. -- David Mintz http://davidmintz.org/ The subtle source is clear and bright The tributary streams flow through the darkness
Re: [fw-general] How to: Zend Dojo Form Dependent Selects (e.g. Country/City)
Are there any plans for a Zend_Form Element which will handle it?
it would be great!
This works, but it isnt a very nice and clean solution :)
denormalized schrieb:
I've spent hours trying to figure out all the pieces to the puzzle of
dependent selects. Here's my solution, in part gathered form messages on
the zend framework mailing list.
Typical problem: A form with country and city selects. Selecting a country
should automatically populate the city select. Pre-existing values for
country and city should automatically be shown in the form.
Step 1. Define a country data source.
Country select will be based on data from a Zend_Db_Table_Abstract. I've
defined a generic "lookup table" resource which defines a getLookup method
for returning name/value pairs:
public function getLookup($filterName = null, $filterValue = null)
{
$select = $this->select();
if (null !== $filterName && null !== $filterValue)
{
$select->where($filterName.' = '.$filterValue);
}
$select->order($this->_order);
return $this->fetchAll($select);
}
So when you add your options in the form:
$country = new Community_Resource_Country();
$countrySelect = new
Zend_Dojo_Form_Element_FilteringSelect('countryId');
foreach ($country->getLookup() as $c) {
$countrySelect->addMultiOption($c->countryId, $c->name);
}
Step 2. Define a city data source which can be filtered by country ID.
You need a way to query and return JSON-formatted data sets. Create a
specialized controller or add an action to a controller that handles this:
public function lookupAction()
{
$filterName = $this->_request->getParam('filterName');
$filterValue = $this->_request->getParam('filterValue');
// Again we're using a generic lookup table class
$_model = new Community_Resource_City();
$data = $_model->getLookup($filterName, $filterValue);
if (null !== $data) {
$items = array();
foreach ($data as $row) {
$items[] = array('label' => $row->name, 'name' => $row->name, 'key' =>
$row->cityId);
}
$final = array(
'identifier' => 'key',
'items' => $items,
);
echo Zend_Json_Encoder::encode($final);
}
Because this controller or controller action doesn't need to return any
fancy stuff (layout, css, etc.), we can disable the layout and view
renderer:
public function preDispatch()
{
// Disable for entire controller. Otherwise, put these calls into your
action function
$this->_helper->layout()->disableLayout();
$this->_helper->viewRenderer->setNoRender(true);
}
Step 3. Ensure your form is dojo-enabled.
class Myproject_Form_Member_Base extends SF_Form_Abstract
{
public function init()
{
// Dojo-enable the form:
Zend_Dojo::enableForm($this);
Step 4. Configure your form elements to use the data sources:
// Country select using a lookup resource
$country = new Community_Resource_Country();
$countrySelect = new
Zend_Dojo_Form_Element_FilteringSelect('countryId');
$countrySelect->setLabel('Location')
->setRequired(true);
$countrySelect->addMultiOption('', '');
foreach ($country->getLookup() as $c) {
$countrySelect->addMultiOption($c->countryId, $c->name);
}
// IMPORTANT: Whenever the country is changed, the data store
// for the dependent city select should also change
$countrySelect->setAttrib('onchange', 'dijit.byId("cityId").store = new
dojo.data.ItemFileReadStore({ url:
"/data/lookup/table/city/filterName/countryId/filterValue/" +
dijit.byId("countryId").value });');
$this->addElement($countrySelect);
$city = new Community_Resource_City();
$citySelect = new Zend_Dojo_Form_Element_FilteringSelect('cityId');
$citySelect->setAutocomplete(true);
$citySelect->setLabel('City');
$citySelect->setRequired(true);
$citySelect->setStoreId('city');
$citySelect->setStoreType('dojo.data.ItemFileReadStore'); // important!
$this->addElement($citySelect);
Step 5. Pre-populate the city select with data.
At this point the city select won't be populated until the country select is
changed. But what if we already know the initial country ID? Zend_Form
won't automatically populate the city select for us!
Therefore, in the controller of our action, after we create the form we need
to programmatically populate the city select:
// set the dojo city lookup based on country id
$countryId = $this->_getParam('countryId',false);
// Note that for my project, id's can never be 0, so I can use the
empty function
if (!empty($countryId)) {
// memberForm is a reference to the form we will display
$this->view->memberForm->getElement('cityId')->setStoreParams(array('url' =>
'/data/lookup/table/city/filterName/countryId/filterValue/'.$memberValues['countryId']));
$this->view->defaultCityId = $countryId;
}
Step 6. Set the value of the city select. What if
Re: [fw-general] zend_form:display validation and error messages
riyas wrote:
>
everything works fine and mail is gone if I fill this form except that
the form is not validated. For example the mail may sent without ‘FullName’,
which is a required field
>
another problem is unable to display messages like ‘'Thank you’ .
>
this may because of $this->_helper->redirector method I used. The form
is redirected and hence lost the values. If I use $this->_helper->forwarded
or $this_forward() it also doesn’t work
>
> Any one can please suggest a method for me to dipsply validation message
> and other messages properly? Sorry for my poor English and thanks in
> advance
>
>
>
Strange validation should work ...
Use the flashMessenger helper to create your messages, something like this
...
class Form_ContactForm extends Zend_Form {
public function __construct($options = null, $moduleName = '',
$controllerName = '', $actionName = '') {
parent::__construct($options);
$this ->setName('testform')
->setAction('')
->setMethod('post')
->setAttrib('id', 'testform')
->setAttrib('accept-charset', 'UTF-8')
//->setAttrib('enctype', 'multipart/form-data');
->setAttrib('enctype',
'application/x-www-form-urlencoded');
$moduleName = $this->createElement('hidden','moduleName');
$moduleName->setValue(moduleName);
$controllerName = $this->createElement('hidden','controllerName');
$controllerName->setValue($controllerName);
$actionName = $this->createElement('hidden','actionName');
$actionName->setValue($actionName);
$FullName = $this->createElement('text','FullName');
$FullName->setLabel('Full Name')
->setRequired(true)
->addFilter('StripTags')
->addFilter('StringTrim')
->addValidator('NotEmpty');
$Email = $this->createElement('text','Email');
$Email->setLabel('Email')
->setRequired(true)
->addFilter('StringTrim')
->addValidator('EmailAddress')
->addValidator('NotEmpty');
$Message = $this->createElement('textarea','Message');
$Message->setLabel('Message')
->setAttribs( array('rows' => 3, 'cols' =>
20 ))
->setRequired(true)
->addFilter('StripTags')
->addFilter('StringTrim')
->addValidator('NotEmpty');
$submit = $this->createElement('submit','submit');
$submit->setLabel('Submit')
->setIgnore(true);
$this->addElements(array( $FullName,
$Email,
$Message,
$submit, ));
}
}
-
$front = Zend_Controller_Front::getInstance();
$moduleName = $front->getRequest()->getModuleName();
$controllerName = $front->getRequest()->getControllerName();
$actionName = $front->getRequest()->getActionName();
$options = null;
$this->view->form = $form;
-
public function indexAction() {
$options = null;
$this->_helper->layout()->disableLayout();
$this->_helper->viewRenderer->setNoRender();
$form = new Form_ContactForm($options, $moduleName, $controllerName,
$actionName);
if ($this->_request->isPost()) {
$formData = $this->_request->getPost();
if ($form->isValid($formData)) {
$moduleName = $formData['moduleName'];
$controllerName
= $formData['controllerName'];
$actionName =
$formData['actionName'];
$FullName = $formData['FullName'];
$Email = $formData['Email'];
$Message = $formData['Message'];
if( strlen(trim( $FullName) ) ){
$mailBody .= "Name:\r\n\t".$FullName
."\r\n\r\n";
$mailBody .= "Email:\r\n\t".$Email
."\r\n\r\n";
$mailBody .=
"Message:\r\n\t".$Message ."\r\n\r\n";
[fw-general] Controllers that respond to both "normal" requests and RESTful requests
Hi, this is very likely to be a dumb question, but I'd really like to have my controllers respond to "normal" requests (as in http://domain.com/product/display/id/1) and also the full range of RESTful requests (GET http://domain.com/product/1 and so on). Turning on Zend_Rest_Route across all my controllers breaks regular requests, but does make them respond correctly to REST, but yeah... I know this is unlikely to work, I was just wondering if there's a way of somehow ordering the routes so that if regular ones don't match then use the RESTful ones or something. Failing that, I suppose I'm just going to have to come up with a nice clean way to link the separate REST controllers back to the "normal" code.
