Re: [fw-general] GET form submission - pretty URL
On Wed, Jul 14, 2010 at 4:06 PM, Hector Virgen djvir...@gmail.com wrote: By default, web browsers submit GET forms using the ?foo=bar syntax. There's nothing that ZF nor PHP can do to change this, because it all happens on the client side. So the only way to get pretty URLs is to use Javascript to override the default behavior. The only way to get this to work using server-side code is to perform a redirect, which is an expensive process, so I don't suggest it. Regarding a JS solution, you'll need to be sure that you implement this in a way that is consistent with how forms are normally submitted. For example, if your form has two inputs by the same name, only the value of the last input is submitted (it overwrites the previous ones). But if you use array notation, then you can have multiple values for the same name, and they will all be submitted and PHP will read them as an array. AFAIK this can be difficult to do with the ZF router because it doesn't turn multiple values into arrays. Also, if your form has multiple submit buttons, each with their own actions (like post versus cancel buttons) then you'll need to submit the value for the button that was clicked. And finally, supporting this may have an impact on your controllers. If you are using $this-_request-getQuery() to read the values, note that it only reads from $_GET (by default). So if you rewrite your URL using Javascript, you'll only be able to use $this-_request-getParam() because $_GET will be empty. With that being said, it's a lot of work for very little benefit. But if you have a simple form with only a few elements, then you may not run into any problems supporting it. Interesting points. My case is just a fairly simply search form for a roster of language interpreters. The user selects a language and submits, the controller action queries a db and uses Zend_Paginate for pagination. The pagination links give you pretty URLs but the initial form submission is of course contrastingly ugly. Not really a big deal. I think I will let it go for now and concentrate on more important areas. @Wil, thanks for the suggestion. I confess I don't quite get it but that's an opportunity for further RTFM. -- Support real health care reform: http://phimg.org/ -- David Mintz http://davidmintz.org/
[fw-general] Re: Zend_Form + Custom Element + PHP 5.3
Hector Virgen wrote:
I'm not sure if namespaces are supported by the plugin loader, can someone
else confirm?
Thanks for the help; however, I ended up building the custom element by
resetting and overriding decorators. It was as simple as:
// define the Save Add Another button
$this-addElement('button', 'cancel', array(
'description' = 'Cancel',
'isArray' = true,
'belongsTo' = 'goto', // this doesn't seem to work here -- is
it because I'm not using the ViewHelper decorator?
'decorators' = array(
array(array('Label' = 'Description'), array('tag' =
'span', 'class' = 'cancel')),
array(array('Button' = 'HtmlTag'),array('tag' =
'button', 'type' = 'submit', 'class' = 'cancel')),
)));
The above gives me:
lt;button class=cancel type=submitgt;
lt;span class=cancelgt;Cancellt;/spangt;
lt;/buttongt;
So the new question is:
Is there a better way to do this (besides creating a custom element) that I
should know about?
-
--
Wil Moore III
Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html
--
View this message in context:
http://zend-framework-community.634137.n4.nabble.com/Zend-Form-Custom-Element-PHP-5-3-tp2289497p2290467.html
Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] Model documentation page, explanation needed
I am still stuck with these issues, hoping to receive some advices :) --- Hello, I need some explanation of this documentation page: http://framework.zend.com/manual/en/learning.quickstart.create-model.html I've created some models following this documentation page, I need to get some content with fetchAll using some filter ( where this = 'that' ecc ) but the fetchAll method doesn't accept any arguments: it is because it is just an example ( and I have to edit fetchAll by myself providing arguments ) or is there any reason? And also, find method requires second parameter do be a Model instance, why? Cannot it be instanciated within the method ( like it happens in fetchAll )? Maybe they are just dumb questions, sorry about that! Any help is very appreciated! Thanks Sergio _ Avatar per Messenger e sfondo per il PC. Creali gratis! http://www.experience.windows.com/landing2.aspx?culture=it-it
Re: [fw-general] Model documentation page, explanation needed
I typically give my fetchAll() method a single, optional parameter called
$constraint. My constraints implement this interface:
interface Galahad_Model_DataMapper_ConstraintInterface
{
public function where($cond, $value = null, $type = null);
public function orWhere($cond, $value = null, $type = null);
public function order($spec);
public function limit($count = null, $offset = null);
public function limitPage($page, $rowCount);
}
Which you can see mirrors a portion of Zend_Db_Select. That way I can use
subclassed Zend_Db_Select objects with my Data Mappers, but if I ever move
away from Zend_Db, I just have to implement the same interface and I won't
have to change any consuming code.
Here's my constraint class:
class Galahad_Model_DataMapper_DbTable_Constraint
extends Zend_Db_Table_Select
implements Galahad_Model_DataMapper_ConstraintInterface
{
}
And here's my fetchAll code in a Zend_Db-based Data Mapper:
if (null !== $constraint !$constraint instanceof
Galahad_Model_DataMapper_DbTable_Constraint)
{
throw new InvalidArgumentException(__CLASS__ . '::' . __METHOD__ .
expects its constraint to be of type
'Galahad_Model_DataMapper_DbTable_Constraint');
}
$result = $this-getDbTable()-fetchAll($constraint);
return $result-toArray();
You can see a working implementation of my modeling system at
http://github.com/inxilpro/Galahad-FE
Cheers,
http://cmorrell.com/ *Chris Morrell* Web: http://cmorrell.com Twitter:
@inxilpro http://twitter.com/inxilpro
On Thu, Jul 15, 2010 at 1:47 PM, Sergio Rinaudo kaiohken1...@hotmail.comwrote:
I am still stuck with these issues,
hoping to receive some advices :)
---
Hello,
I need some explanation of this documentation page:
http://framework.zend.com/manual/en/learning.quickstart.create-model.html
I've created some models following this documentation page,
I need to get some content with fetchAll using some filter ( where this =
'that' ecc ) but the fetchAll
method doesn't accept any arguments: it is because it is just an example (
and I have to edit fetchAll by myself providing arguments ) or
is there any reason?
And also, find method requires second parameter do be a Model instance,
why?
Cannot it be instanciated within the method ( like it happens in fetchAll
)?
Maybe they are just dumb questions, sorry about that!
Any help is very appreciated!
Thanks
Sergio
--
Non sei a casa? Accedi a Messenger dal
Web.http://www.messenger.it/web/default.aspx
[fw-general] July Bughunt Starts Today!
Hey contributors ZFers, Just wanted to remind everyone that today, tomorrow and saturday are our monthly bughunt days. I'll be online to help anyone sort through bugs, or get their jira/svn accounts setup. So ping me on #zftalk.dev on Freenode. Below is the copy from the announcement earlier this week. Cheers! -ralph -- visit: http://devzone.zend.com/article/12304 for more info -- Yep, it's the third week of the month- you know what that means: Zend Framework Monthly Bughut! This Thursday, Friday and Saturday of July (the 15th, 16th and 17th 2010), we'll be hosting our monthly bug hunt. For those of you unfamiliar with the event, each month, we organize the community to help reduce the number of open issues reported against the framework. The last two months of bug hunts collectively closed 63 issues. The May bug hunt saw new first-time winner Jan Pieper step up and take first. Then in June, Christian Albrecht (a previous bug hunt winner) took home first again. Congratulations Jan Christian and thanks for making the bug hunt for May and June a success. If you have not already done so, please contact Ralph Schindler or Matthew Weier O'Phinney for details on claiming your prize. All in all, bug hunt days have helped us close 100's of issues in Zend Framework since their inception. These bug hunts have proved vital to keeping up the bug squashing momentum in this project. So, whether they are big bugs or small bugs, remember this: all bugs worthy of being squashed. Not convinced you should join in yet? Here are some more reasons: * Improve your coding skillz by being around some of PHP's top developers in #zftalk.dev while hunting for bugs. * Win a t-shirt -- the individual who resolves or assists in resolving the most issues wins a Zend Framework t-shirt! * Help improve the overall quality of the code you're already using. * Fix issues that have been affecting you. * Save you and your company time spent managing your own patches to ZF, and move the maintenance upstream by patching the framework itself. * Learn valuable Quality Assurance skills. * All the cool kids are doing it. Are you cool? If you want to help out, please make sure you have a CLA on file with us, and then join us in the #zftalk.dev channel on Freenode on Thursday, Friday, Saturday. If you would like more information on specifics of participating, read our guide. Looking forward to seeing you at this month's Bug Hunt Days!
