Re: [fw-general] 301 redirect
The Zend MVC helper is a pretty safe bet:- http://framework.zend.com/manual/en/zend.controller.actionhelpers.html#id4796449 Wouldn't this work? header(HTTP/1.1 301 Moved Permanently); header(Location: .$new_url); On Jul 17, 2007, at 5:47 AM, frosty1 wrote: my client is trying to set up 301 redirects for several highly rated pages on the site we are converting to zf.has anyone had any luck doing this? -- View this message in context: http://www.nabble.com/301-redirect-tf4096317s16154.html#a11647661 Sent from the Zend Framework mailing list archive at Nabble.com. -- Simon Mundy | Director | PEPTOLAB 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000 Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124 http://www.peptolab.com
Re: [fw-general] Problem with the Redirector helper
Nick --
The fix looks good, though I want to add some unit tests to verify.
Could you put this in the issue tracker, please?
Thanks!
-- Nick Howell [EMAIL PROTECTED] wrote
(on Monday, 16 July 2007, 08:03 PM -0400):
This seems like an error to me, but then again perhaps I am confused by the
expected functionality...
I am doing a $this-_redirector-goto(null,null,'admin'); inside my
Admin_ClassController-viewAction()
What I expect to happen here is for the page to redirect to
http://example.com/
admin but it goes to http://example.com/admin/class instead. Granted, I can do
a $this-_redirector-goto(null,'index','admin'); but then I get http://
example.com/admin/index (I'd prefer to not have the extra /index on the end).
Looks like a problem in Zend_Controller_Action_Helper_Redirector-setGoto();
...
if (null === $controller) {
$controller = $request-getControllerName();
if (empty($controller)) {
$controller = $dispatcher-getDefaultControllerName();
}
}
should be:
if (null === $controller) {
if (null !== $action) {
$controller = $request-getControllerName();
if (empty($controller)) {
$controller = $dispatcher-getDefaultControllerName();
}
}
}
The addition checks to see if the $action was set, THEN we can get the
$controller if it was not set - otherwise leave $controller as null.
I tested this change in my application and the problem was solved.
This also keeps the functionality consistent because you can now do a $this-
_redirector-goto(null); and be redirected to the current module index rather
than the controller you are currently in.
Can anyone confirm my logic behind this? If so, let's see this in the next
release pretty please :-)
Thanks,
Nick Howell
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] No output...
-- Drew Bertola [EMAIL PROTECTED] wrote (on Tuesday, 17 July 2007, 01:08 AM -0700): What's a bit strange is that in the manual, the example layout is given as: ( http://framework.zend.com/manual/en/zend.controller.modular.html ) docroot/ index.php application/ default/ controllers/ IndexController.php FooController.php blog/ controllers/ IndexController.php models/ views/ news/ controllers/ IndexController.php ListController.php models/ views/ Where are the models and views for the default module? Do they go directly beneath application/ or are they just missing? Just missing. They should be following the same pattern as the blog and news models listed there. I've put in a JIRA issue to fix this chapter: http://framework.zend.com/issues/browse/ZF-1730 -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Inconsistencies with the frontcontroller and the request's getBaseUrl
-- PotatoBob [EMAIL PROTECTED] wrote (on Tuesday, 17 July 2007, 01:53 AM -0700): This is more of an unexpected problem than a bug I guess, but just to let you guys know, the frontController sets the requests baseUrl if you set it via the controllers setBaseUrl method. You can then grab it via the getBaseUrl accessor, but the problem is the getBaseUrl method does not grab from the request object but from the $_baseUrl var which is only set if you set the base url using the front controllers setBaseUrl method. Good catch! Could you please post an issue in the tracker regarding this? -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Inconsistencies with the frontcontroller and the request's getBaseUrl
I'll add it to my todo list of stuff to report ;) Matthew Weier O'Phinney-3 wrote: -- PotatoBob [EMAIL PROTECTED] wrote (on Tuesday, 17 July 2007, 01:53 AM -0700): This is more of an unexpected problem than a bug I guess, but just to let you guys know, the frontController sets the requests baseUrl if you set it via the controllers setBaseUrl method. You can then grab it via the getBaseUrl accessor, but the problem is the getBaseUrl method does not grab from the request object but from the $_baseUrl var which is only set if you set the base url using the front controllers setBaseUrl method. Good catch! Could you please post an issue in the tracker regarding this? -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- View this message in context: http://www.nabble.com/Inconsistencies-with-the-frontcontroller-and-the-request%27s-getBaseUrl-tf4095633s16154.html#a11649931 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] FlashMessenger Patch - Completion of the API
I think I'd argue for keeping this stuff in the session, but maybe providing a way to specify different session back-ends, or maybe for specifying a different back-end for different namespaces. I also wonder how the hasMessages() and similar state reporting methods should work with multiple namespaces in FlashMessenger - should they also take an optional argument? Matthew Weier O'Phinney-3 wrote: -- Eric Coleman [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 12:52 PM -0400): way to rain on my parade I think the issue is valid; the question is how to approach it. Ralph brings up a good argument: some of the use cases indicate that a more generic, intra-action messaging system should probably be created (non-session based, used when _forward()ing between actions). However, if this is done, it would be better not to have two separate helpers, but one helper with multiple backends (one session based, one in-memory). As such, it's a very different thing that simply adding a flag to the flashmessenger. On 7/16/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: -- townxelliot [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 09:03 AM -0700): I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. A number of developers -- including Eric, whom you quote below, and myself -- have voiced frustration over how the FlashMessenger currently works in regards to namespaces. I've created a JIRA issue requesting that each of the various *Messages() methods take an optional $namespace parameter; this would simplify using the FlashMessenger in most cases as there would be no setup required to use alternate namespaces (other than the default namespace). The issue can be found at: http://framework.zend.com/issues/browse/ZF-1705 This will only deal with namespace usage, not with clearing a namespace after retrieval; that will be addressed separately. Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true -- 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/ -- View this message in context: http://www.nabble.com/FlashMessenger-Patch---Completion-of-the-API-tf3898116s16154.html#a11650730 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] FlashMessenger Patch - Completion of the API
-- townxelliot [EMAIL PROTECTED] wrote (on Tuesday, 17 July 2007, 08:11 AM -0700): I think I'd argue for keeping this stuff in the session, but maybe providing a way to specify different session back-ends, or maybe for specifying a different back-end for different namespaces. That's a debate for another day. If you're interested and willing, please create a new proposal indicating exactly what you'd like to see so we can evaluate and determine how to proceed. I also wonder how the hasMessages() and similar state reporting methods should work with multiple namespaces in FlashMessenger - should they also take an optional argument? Yes, and that's on the issue that has been reported on JIRA. Each of the following will have an optional additional argument for the namespace: addMessage() hasMessages() getMessages() clearMessages() hasCurrentMessages() getCurrentMessages() This will either happen for 1.0.1 or the following release. Matthew Weier O'Phinney-3 wrote: -- Eric Coleman [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 12:52 PM -0400): way to rain on my parade I think the issue is valid; the question is how to approach it. Ralph brings up a good argument: some of the use cases indicate that a more generic, intra-action messaging system should probably be created (non-session based, used when _forward()ing between actions). However, if this is done, it would be better not to have two separate helpers, but one helper with multiple backends (one session based, one in-memory). As such, it's a very different thing that simply adding a flag to the flashmessenger. On 7/16/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: -- townxelliot [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 09:03 AM -0700): I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. A number of developers -- including Eric, whom you quote below, and myself -- have voiced frustration over how the FlashMessenger currently works in regards to namespaces. I've created a JIRA issue requesting that each of the various *Messages() methods take an optional $namespace parameter; this would simplify using the FlashMessenger in most cases as there would be no setup required to use alternate namespaces (other than the default namespace). The issue can be found at: http://framework.zend.com/issues/browse/ZF-1705 This will only deal with namespace usage, not with clearing a namespace after retrieval; that will be addressed separately. Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true -- 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/ -- View this message in context: http://www.nabble.com/FlashMessenger-Patch---Completion-of-the-API-tf3898116s16154.html#a11650730 Sent from the Zend Framework mailing list archive at Nabble.com. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
Isn't the port for Gmail SMTP 587 not 465? -- Jack
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
And it should definitely be TLS not SSL. -- Jack
[fw-general] Proposal: Zend_Service_Yadis soliciting for comments
Afternoon all, http://framework.zend.com/wiki/pages/viewpage.action?pageId=20369 Pushing out another proposal for comments since it's Ready for Review. And yet again, it's OpenID related. Zend_Service_Yadis is a protocol for discovering the services associated with a URI based online Identity. It's nice, complicated, and likely incredibly vague to everyone as to what it's purpose is. It's attracted no comments since being published last February :). That must be some sort of achievement by itself, right? Most obscure proposal perhaps? Do I win something??? If anyone has a small sliver of time to quickly dash through the code, and find anything to comment on, please let me know. The source code has been in operation on a few sites already, and I recently polished it up for my originally intended OpenID proposal - the new Zend_OpenId proposal from Dmitry will more than likely make use of it (barring any repeat performance from June...ahem ;)). As such, given Zend's recent prioritisation of OpenID support, it's a an important Service component to get right, irrespective of how mind-numbingly boring it may appear (okay, is). I won't hold anyone to account for not commenting ;). Kind regards, Pádraic Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
[fw-general] Re: [fw-webservices] Proposal: Zend_Service_Yadis soliciting for comments
I've wanted to comment on it but, I'm scared :) I've heard a lot of good things about OpenID, the twit.tv guys love the idea. From what i've read and heard about it, this seems like a VERY welcome addition to ZF. I really like the single signon everywhere. I've looked through your proposals before, but I don't remember seeing that this is tied to Zend_Auth, which is what I would think it would be, or is this a lower level layer? Maybe a /Zend_(Service_|)OpenID/ would tie Zend_Service_Yadis to Zend_Auth? Like I said though, I'm scared to comment because I don't know that much about the inner workings, but I love the idea. Quick plug for my proposal: :D !! http://framework.zend.com/wiki/display/ZFPROP/Zend_Session_SaveHandler_Db+-+Jordan+Raub I'll be revamping it within the next couple days, since the 0.7.0 version I've had to redo a lot of the internal code for my sites. Its the only one currently in the 'Proposals Under Review.' BE GENTLE, PLEASE!!! Thank you, Jordan Raub Systems Adminstrator / Developer Novatex Solutions [EMAIL PROTECTED] 1.888.NTS.1.SEO He that teaches himself hath a fool for his master. -- Benjamin Franklin Poor is the pupil who does not surpass his master. -- Leonardo da Vinci
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
Jack Sleight wrote:
And it should definitely be TLS not SSL.
tried that:
$config = array(
'auth' = 'login',
'username' =
'[EMAIL PROTECTED]',
'password' = 'secret',
'ssl' = 'tls',
'port' = 587
);
$tr = new Zend_Mail_Transport_Smtp('smtp.googlemail.com', $config);
Zend_Mail::setDefaultTransport($tr);
still this error:
Warning: fgets() [function.fgets]: SSL: fatal protocol error in
D:\adat\awebsites\ev-manager\mvc-site\lib\Zend\Mail\Protocol\Abstract.php on
line 303
Fatal error: Exception thrown without a stack frame in Unknown on line 0
--
View this message in context:
http://www.nabble.com/Zend_Mail---how-to-use-Zend_Mail_Transport_Smtp-for-googlemail.com-tf4097373s16154.html#a11652871
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
I'm pretty sure the port is 465.
Also check that you have the correct stream wrappers compiled into PHP
(visible from phpinfo())
K
- Original Message -
From: mike55 [EMAIL PROTECTED]
To: fw-general@lists.zend.com
Sent: Tuesday, July 17, 2007 10:23 AM
Subject: Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp
for googlemail.com
Jack Sleight wrote:
And it should definitely be TLS not SSL.
tried that:
$config = array(
'auth' = 'login',
'username' = '[EMAIL PROTECTED]',
'password' = 'secret',
'ssl' = 'tls',
'port' = 587
);
$tr = new Zend_Mail_Transport_Smtp('smtp.googlemail.com', $config);
Zend_Mail::setDefaultTransport($tr);
still this error:
Warning: fgets() [function.fgets]: SSL: fatal protocol error in
D:\adat\awebsites\ev-manager\mvc-site\lib\Zend\Mail\Protocol\Abstract.php
on
line 303
Fatal error: Exception thrown without a stack frame in Unknown on line 0
--
View this message in context:
http://www.nabble.com/Zend_Mail---how-to-use-Zend_Mail_Transport_Smtp-for-googlemail.com-tf4097373s16154.html#a11652871
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
Kevin McArthur-2 wrote: I'm pretty sure the port is 465. it seems both ports 465 and 587 are ok: http://mail.google.com/support/bin/answer.py?answer=13287 Kevin McArthur-2 wrote: Also check that you have the correct stream wrappers compiled into PHP (visible from phpinfo()) stream wrappers? this is what i found, containing streams and wrappers Registered PHP Streams php, file, http, ftp, compress.zlib, https, ftps, zip Registered Stream Socket Transports tcp, udp, ssl, sslv3, sslv2, tls Registered Stream Filters convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, zlib.* zlibZLib Supportenabled Stream Wrapper support compress.zlib:// Stream Filter support zlib.inflate, zlib.deflate Compiled Version1.2.3 Linked Version 1.2.3 -- View this message in context: http://www.nabble.com/Zend_Mail---how-to-use-Zend_Mail_Transport_Smtp-for-googlemail.com-tf4097373s16154.html#a11653342 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
Your setup looks good, I'm out of ideas =P K - Original Message - From: mike55 [EMAIL PROTECTED] To: fw-general@lists.zend.com Sent: Tuesday, July 17, 2007 10:52 AM Subject: Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com Kevin McArthur-2 wrote: I'm pretty sure the port is 465. it seems both ports 465 and 587 are ok: http://mail.google.com/support/bin/answer.py?answer=13287 Kevin McArthur-2 wrote: Also check that you have the correct stream wrappers compiled into PHP (visible from phpinfo()) stream wrappers? this is what i found, containing streams and wrappers Registered PHP Streams php, file, http, ftp, compress.zlib, https, ftps, zip Registered Stream Socket Transports tcp, udp, ssl, sslv3, sslv2, tls Registered Stream Filters convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, zlib.* zlibZLib Support enabled Stream Wrapper support compress.zlib:// Stream Filter support zlib.inflate, zlib.deflate Compiled Version 1.2.3 Linked Version 1.2.3 -- View this message in context: http://www.nabble.com/Zend_Mail---how-to-use-Zend_Mail_Transport_Smtp-for-googlemail.com-tf4097373s16154.html#a11653342 Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] CLA
I don't want to be inpatient, but I've sent my CLA through facsimile (and also an email to [EMAIL PROTECTED]) nine days ago, than another mail, as I read on the Wiki (it says I should ask about it after seven days), but I haven't recieved any response so far. Could somebody tell me anything about the reason? Is there something I did wrong? Thanks, Ádám
Re: [fw-general] CLA
Adam... What are nine days ? I waited 5 weeks until my CLA was processed. :-o And we had not so much work 1,5 years ago ;-) I'm sure it will be processed soon. Greetings Thomas I18N Team Leader - Original Message - From: Joó Ádám [EMAIL PROTECTED] To: fw-general fw-general@lists.zend.com Sent: Tuesday, July 17, 2007 8:09 PM Subject: [fw-general] CLA I don't want to be inpatient, but I've sent my CLA through facsimile (and also an email to [EMAIL PROTECTED]) nine days ago, than another mail, as I read on the Wiki (it says I should ask about it after seven days), but I haven't recieved any response so far. Could somebody tell me anything about the reason? Is there something I did wrong? Thanks, Ádám
[fw-general] Using the Redirector helper outside of an Action Controller
I'm trying to implement a little routing in my bootstrap script (before the
dispatcher starts). Essentially, under very specific conditions, I need to
alter the controller that is invoked. I found
Zend_Controller_Action_HelperBroker and the Redirector, but I can't seem to
get them to function outside of an Action Controller. I've tried various
combinations of code similar to this -
$redirector =
Zend_Controller_Action_HelperBroker::getExistingHelper('Redirector');
$redirector-goto('index');
...but nothing seems to work. I've looked through the docs, and all of the
examples seem to function inside of a controller. Is there an easy way to
accomplish what I'm trying to do?
Thanks,
- Ryan
[fw-general] Re: Lifecycle Handling
Hi Thomas, My comments are inline below: Thomas Weidner wrote: Hy Zend'ers, I just read through the newly created lifecycle description from darby. So now I wanted to add my last changes as the next mini release is proposed. I was not able to see the branch 1.0.1... only the old branch 1.0 There is no 1.0.1 branch. The 1.0.1 release will be tagged from the release-1.0 branch. A 1.0.2 release, though we may not have one before 1.1.0, would also be produced from this branch. When 1.1.0 is approaching, we'll create a release-1.1 branch, from which 1.1.0, 1.1.1, etc. would be tagged. This is illustrated with an image in the lifecycle document. (We _could_ create further release branches, such as for 1.0.1 and 1.0.2 separately, but such additional complexity is probably not warranted for this project at this time.) And I dont want to loose my commit rights as stated in this description for not commiting the changes to the new branch only because the branch is not avaiable ;-) (who has to do the work if the team leader and main author gets suspended ? ;-) ) You aren't likely to lose your commit rights, Thomas, but we have to reserve the right to revoke committers' privileges should they decide to continually ignore our contribution policies. There will be plenty of questions, particularly during this initial stage of post-1.0.0 development, and I expect a high degree of leniency as everyone learns the process together. If anyone should have trouble with their SVN commit access, please contact me personally, and I will see to it that such issues are resolved. The next point is that we have first to find a zend member who looks through the changes before we commit them. No, in most cases, you can simply have another contributor review your work. Of course, you can always ask a Zend liaison to review your work, but we have limited bandwidth, and we have to delegate as much of this work as possible to the community itself. We just want to make sure that unit tests pass and that the changes have been reviewed for potential risks to stability before they are merged on to a release branch. Sounds a little bit complicated for bug fixes like the one I made yesterday. 3 lines added for an not reproducable race condition. No unit tests and no documentation possible or needed. It should also be clearified if issues can be closed when they are commited to trunk, or only after they were commited to branch. The PHP project is managed in much the same way, actually, where contributors are required to commit their changes to two places. The main point of the review requirement is to help maintain the stability of the release branches. JIRA issues can be resolved as soon as passing unit tests for the fix are committed to the trunk, though the issue should be marked as fixed for the affected versions. (For us right now this means that resolving an issue in the trunk fixes 1.1.0, and once the changes are merged to the release branch, it would also fix 1.1.1.) How about improvements to the documentation ??? I will improve the documentation of the I18N components from time to time. Add new pages to answer often asked questions and so on... How should we handle this ? Until now we commited them to trunk... Should they also be reviewed by a Zend member ? As mentioned in the lifecycle document, no documentation is to be merged to release branches. Documentation improvements will go out with minor and major releases (e.g., 1.1.0 and 2.0.0, respectively). Should improvements always be commited to incubator, reviewed and then commited to core ? Because I normally code all, write documentation and unit tests and then I commit the complete change to trunk. It depends on the scope of the work and how long you expect the work to take. We don't want you to be stuck holding back committing your incomplete work. If you write 200 lines of code today, you should have a place to commit it, even if it is not complete. This creates an instant backup and facilitates review before completion. So as I see it in sum the new workflow from now on is, to commit all to incubator, let verify through Zend and after all say, your 3 lines of code are ok, commit to trunk. No, minor and backward compatible changes may be made directly to the trunk, but they should be accompanied by passing unit tests to confirm the desired behavior from the changes. Also I will have to have two working copies in my eclipse... One for the trunk and one for the actual maintenance branch or is there a better way to handle this within eclipse ? I don't know about eclipse specifically, but you can switch a single working copy between two branches. Again, this is documented in the lifecycle document; perhaps some elaboration is needed to make it more clear? To strike a balance, we also do not want to be overwhelmingly verbose, but where clarifications can be made, all the better. :) Thanks for these questions! I'm sure you're not
Re: [fw-general] Re: Lifecycle Handling
Darby Felton wrote: Thomas Weidner wrote: JIRA issues can be resolved as soon as passing unit tests for the fix are committed to the trunk, though the issue should be marked as fixed for the affected versions. (For us right now this means that resolving an issue in the trunk fixes 1.1.0, and once the changes are merged to the release branch, it would also fix 1.1.1.) Oops - here 1.1.1 should be 1.0.1 instead. :)
Re: [fw-general] Using the Redirector helper outside of an Action Controller
-- Ryan Graciano [EMAIL PROTECTED] wrote
(on Tuesday, 17 July 2007, 03:00 PM -0400):
I'm trying to implement a little routing in my bootstrap script (before the
dispatcher starts). Essentially, under very specific conditions, I need to
alter the controller that is invoked. I found
Zend_Controller_Action_HelperBroker and the Redirector, but I can't seem to
get
them to function outside of an Action Controller. I've tried various
combinations of code similar to this -
$redirector = Zend_Controller_Action_HelperBroker::getExistingHelper
('Redirector');
$redirector-goto('index');
...but nothing seems to work. I've looked through the docs, and all of the
examples seem to function inside of a controller. Is there an easy way to
accomplish what I'm trying to do?
You've got three problems:
* The redirector won't yet be instantiated, so using
getExistingHelper() will not return the redirector object. Use
getStaticHelper() instead.
* The redirector actually sets headers in the response object instead
of emitting them immediately. This means that you have to tell the
response object to send the headers if you want to redirect
immediately (usually this is done automatically for you as part of
the dispatch() routine in the front controller).
* However, most likely, the response object is not even yet
initialized, and because no action controller is in play, the helper
has no way to retrieve it.
Maybe try the following:
class DummyController extends Zend_Controller_Action
{
}
$request = new Zend_Controller_Request_Http();
$response = new Zend_Controller_Response_Http();
$action = new DummyController($request, $response, array());
$redirector =
Zend_Controller_Action_HelperBroker::getStaticHelper('Redirector');
$redirector-setActionController($action);
$redirector-goto('index');
$response-sendHeaders();
However, honestly, it would probably be easier to simply call header()
yourself.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Problem with the Redirector helper
Added to the tracker: http://framework.zend.com/issues/browse/ZF-1734 Regards, Nick Howell
Re: [fw-general] Re: Lifecycle Handling
On Jul 17, 2007, at 1:31 PM, Thomas Weidner wrote: The next point is that we have first to find a zend member who looks through the changes before we commit them. No, in most cases, you can simply have another contributor review your work... And exact here is my personal problem ;-) I am the main author and only person who codes all the I18N classes. There is no other contributor. So I must ask Zend to review my code. There may be no other core contributors for the i18n classes, but there are dozens of contributors to the framework. I monitor the i18n list as I'm sure many others do. if you need a reviewer, I'm sure any one of us would be happy to look at your code. JIRA issues can be resolved as soon as passing unit tests for the fix are committed to the trunk,.. And what about fixes which do not include unit tests ? For example... I am not able to write tests for issues which are related to 64bit machines only or for race conditions. Then how can you be sure that the bug has been fixed? Bug fixing is where unit tests truly shine: before you fix a bug, you write a test that shows the bug exists. Then you fix the bug. In this way, you can be assured that you will never re-introduce the bug because there will always be a test for it. I don't know about eclipse specifically, but you can switch a single working copy between two branches. Again, this is documented in the lifecycle document; perhaps some elaboration is needed to make it more clear? To strike a balance, we also do not want to be overwhelmingly verbose, but where clarifications can be made, all the better. :) No I can not... For example Zend_Date I've integrated new features (array access). But when there is a new bug I have to integrate it in trunk (where the new feature resists) and in maintenance. Otherwise the maintenance branch would also have the new feature integrated which is not allowed. You should simply checkout two working copies, one from the branch, and one from the trunk. This is how I've handled maintenance branches for years. -- Willie Alberty, Owner Spenlen Media [EMAIL PROTECTED] http://www.spenlen.com/
Re: [fw-general] ZF 1.0.1 Mini Release
Hi Darby, [...] Therefore, once you have committed changes to the trunk with passing unit tests, please request review from a community member or a Zend liaison, and then merge the changes (except for documentation) to the release branch. [...] It doesn't sound very clear to me. Let's take an example. I commited some bug fixes into the trunk : - (1) some of them should be commited (IMHO) into the release branch - (2) some of them are not really important and can wait the 1.1.0 - (3) some of them are potentially dangerous All of them are available in JIRA. = May I commit (1) directly (without any review) ? (if not, it will be very frustrating think for personal contributors like me) = No problem for (2), they are waiting in the trunk = A review is mandatory to commit (3) Are you ok with these 3 points ? -- Fabien MARTY [EMAIL PROTECTED]
RE: [fw-general] Re: Lifecycle Handling
-Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] For example Zend_Date I've integrated new features (array access). But when there is a new bug I have to integrate it in trunk (where the new feature resists) and in maintenance. Otherwise the maintenance branch would also have the new feature integrated which is not allowed. This means there are a few choices: (a) Implement the same bug fix in a different way, to work with the code in the branch. But depending on the nature of the bug, this may be too much work. (b) Implement the bug fix in both trunk and branch, implemented in a way that doesn't rely on the new features. Sometimes this is possible, but sometimes it's not possible or it's too much work. (c) Fix the bug in the trunk but don't fix it in the branch. Users must wait until 1.1.0 to get some bug fixes. I think all cases will fit into the three choices above. :-) Regards, Bill Karwin
RE: [fw-general] Re: Lifecycle Handling
Btw, as Darby mentioned in his initial email, we are very open to feedback re: the lifecycle document. This is our stab at putting something out there which we think will not be too hard but will also enable high-quality. Any suggestions for tweaks/changes should definitely be voiced. We'll definitely need to strike a balance here (which we tried to do). Andi -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 2:08 PM To: Thomas Weidner; Darby Felton Cc: fw-general@lists.zend.com; Alexander Veremyev Subject: RE: [fw-general] Re: Lifecycle Handling Hi Thomas, The reason we asked for commits to the stable branch to be reviewed by another person (Zend or community) is so that we have another eye on commits that go into the stable releases. My past experience has been that sometimes bad fixes or API breaking fixes get commited (by accident) and I think this could help mitigate the risk. We intentionally don't limit this to Zenders. We think anyone who is well versed in the Zend Framework can be another helping eye on the commit. The person will not always be an expert on your code but might be able to catch some issues with the commit. Btw, you'd commit to trunk first so people would have an easy time to see the commit. In your case btw, Alex from our team would be a good person to have review the commits but anyone is fine. I know it's a bit of overhead but I think the additional process would help make sure we release high quality mini releases. Quality is really one of the key things which should set our project apart. Andi -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 1:31 PM To: Darby Felton Cc: fw-general@lists.zend.com; Alexander Veremyev Subject: [fw-general] Re: Lifecycle Handling Hy Darby, I was not able to see the branch 1.0.1... only the old branch 1.0 There is no 1.0.1 branch. The 1.0.1 release will be tagged from the release-1.0 branch. A 1.0.2 release, though we may not have one before 1.1.0, would also be produced from this branch. When 1.1.0 is approaching, we'll create a release-1.1 branch, from which 1.1.0, 1.1.1, etc. would be tagged. This is illustrated with an image in the lifecycle document. (We _could_ create further release branches, such as for 1.0.1 and 1.0.2 separately, but such additional complexity is probably not warranted for this project at this time.) So we should always use the Zend Branch 1.0 when committing as long as its for fixing bugs. Right ? But only if it has been reviewed by someone. The next point is that we have first to find a zend member who looks through the changes before we commit them. No, in most cases, you can simply have another contributor review your work. Of course, you can always ask a Zend liaison to review your work, but we have limited bandwidth, and we have to delegate as much of this work as possible to the community itself. We just want to make sure that unit tests pass and that the changes have been reviewed for potential risks to stability before they are merged on to a release branch. And exact here is my personal problem ;-) I am the main author and only person who codes all the I18N classes. There is no other contributor. So I must ask Zend to review my code. JIRA issues can be resolved as soon as passing unit tests for the fix are committed to the trunk, though the issue should be marked as fixed for the affected versions. (For us right now this means that resolving an issue in the trunk fixes 1.1.0, and once the changes are merged to the release branch, it would also fix 1.1.1.) And what about fixes which do not include unit tests ? For example... I am not able to write tests for issues which are related to 64bit machines only or for race conditions. Should they also be reviewed by a Zend member ? As mentioned in the lifecycle document, no documentation is to be merged to release branches. Documentation improvements will go out with minor and major releases (e.g., 1.1.0 and 2.0.0, respectively). But should new documentation be reviewed by Zend ??? It depends on the scope of the work and how long you expect the work to take. We don't want you to be stuck holding back committing your incomplete work. If you write 200 lines of code today, you should have a place to commit it, even if it is not complete. This creates an instant backup and facilitates review before completion. When I integrate new features to a class I can not committ only parts This would brake the existing class in the trunk or incubator. And I dont want to get flamed for things which I know not to work for now. Coding a new class for example is no problem... but
Re: [fw-general] Re: Lifecycle Handling
Hi All I've got some small commits for Zend_Mail that should be released ASAP, as it affects SMTP - it was revision 5724 Could someone please review these and give me a heads-up on the best way to merge into the 1.0.1 branch? Cheers Hi Thomas, My comments are inline below: Thomas Weidner wrote: Hy Zend'ers, I just read through the newly created lifecycle description from darby. So now I wanted to add my last changes as the next mini release is proposed. I was not able to see the branch 1.0.1... only the old branch 1.0 There is no 1.0.1 branch. The 1.0.1 release will be tagged from the release-1.0 branch. A 1.0.2 release, though we may not have one before 1.1.0, would also be produced from this branch. When 1.1.0 is approaching, we'll create a release-1.1 branch, from which 1.1.0, 1.1.1, etc. would be tagged. This is illustrated with an image in the lifecycle document. (We _could_ create further release branches, such as for 1.0.1 and 1.0.2 separately, but such additional complexity is probably not warranted for this project at this time.) And I dont want to loose my commit rights as stated in this description for not commiting the changes to the new branch only because the branch is not avaiable ;-) (who has to do the work if the team leader and main author gets suspended ? ;-) ) You aren't likely to lose your commit rights, Thomas, but we have to reserve the right to revoke committers' privileges should they decide to continually ignore our contribution policies. There will be plenty of questions, particularly during this initial stage of post-1.0.0 development, and I expect a high degree of leniency as everyone learns the process together. If anyone should have trouble with their SVN commit access, please contact me personally, and I will see to it that such issues are resolved. The next point is that we have first to find a zend member who looks through the changes before we commit them. No, in most cases, you can simply have another contributor review your work. Of course, you can always ask a Zend liaison to review your work, but we have limited bandwidth, and we have to delegate as much of this work as possible to the community itself. We just want to make sure that unit tests pass and that the changes have been reviewed for potential risks to stability before they are merged on to a release branch. Sounds a little bit complicated for bug fixes like the one I made yesterday. 3 lines added for an not reproducable race condition. No unit tests and no documentation possible or needed. It should also be clearified if issues can be closed when they are commited to trunk, or only after they were commited to branch. The PHP project is managed in much the same way, actually, where contributors are required to commit their changes to two places. The main point of the review requirement is to help maintain the stability of the release branches. JIRA issues can be resolved as soon as passing unit tests for the fix are committed to the trunk, though the issue should be marked as fixed for the affected versions. (For us right now this means that resolving an issue in the trunk fixes 1.1.0, and once the changes are merged to the release branch, it would also fix 1.1.1.) How about improvements to the documentation ??? I will improve the documentation of the I18N components from time to time. Add new pages to answer often asked questions and so on... How should we handle this ? Until now we commited them to trunk... Should they also be reviewed by a Zend member ? As mentioned in the lifecycle document, no documentation is to be merged to release branches. Documentation improvements will go out with minor and major releases (e.g., 1.1.0 and 2.0.0, respectively). Should improvements always be commited to incubator, reviewed and then commited to core ? Because I normally code all, write documentation and unit tests and then I commit the complete change to trunk. It depends on the scope of the work and how long you expect the work to take. We don't want you to be stuck holding back committing your incomplete work. If you write 200 lines of code today, you should have a place to commit it, even if it is not complete. This creates an instant backup and facilitates review before completion. So as I see it in sum the new workflow from now on is, to commit all to incubator, let verify through Zend and after all say, your 3 lines of code are ok, commit to trunk. No, minor and backward compatible changes may be made directly to the trunk, but they should be accompanied by passing unit tests to confirm the desired behavior from the changes. Also I will have to have two working copies in my eclipse... One for the trunk and one for the actual maintenance branch or is there a better way to handle this within eclipse ? I don't know about eclipse specifically, but you can switch a single working copy between two branches. Again,
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
Did you try TLS on port 25?
Since you're getting the error from the SSL stream itself it sounds
like it can't negotiate properly. Just to help solve the problem,
which version of ZF are you using and which version of PHP? I saw from
your later post that SSL is correctly compiled into your copy of PHP.
Cheers
Jack Sleight wrote:
And it should definitely be TLS not SSL.
tried that:
$config = array(
'auth' = 'login',
'username' =
'[EMAIL PROTECTED]',
'password' = 'secret',
'ssl' = 'tls',
'port' = 587
);
$tr = new Zend_Mail_Transport_Smtp('smtp.googlemail.com', $config);
Zend_Mail::setDefaultTransport($tr);
still this error:
Warning: fgets() [function.fgets]: SSL: fatal protocol error in
D:\adat\awebsites\ev-manager\mvc-site\lib\Zend\Mail\Protocol
\Abstract.php on
line 303
Fatal error: Exception thrown without a stack frame in Unknown on
line 0
--
View this message in context:
http://www.nabble.com/Zend_Mail---how-to-use-Zend_Mail_Transport_Smtp-for-googlemail.com-tf4097373s16154.html#a11652871
Sent from the Zend Framework mailing list archive at Nabble.com.
--
Simon Mundy | Director | PEPTOLAB
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654
4124
http://www.peptolab.com
Re: [fw-general] Re: Lifecycle Handling
Hy, And exact here is my personal problem ;-) I am the main author and only person who codes all the I18N classes. There is no other contributor. So I must ask Zend to review my code. There may be no other core contributors for the i18n classes, but there are dozens of contributors to the framework. I monitor the i18n list as I'm sure many others do. if you need a reviewer, I'm sure any one of us would be happy to look at your code. Would be great... As always I am of course speaking out loud what others dont want to say because they are to shy ;-) And what about fixes which do not include unit tests ? For example... I am not able to write tests for issues which are related to 64bit machines only or for race conditions. Then how can you be sure that the bug has been fixed? Bug fixing is where unit tests truly shine: before you fix a bug, you write a test that shows the bug exists. Then you fix the bug. In this way, you can be assured that you will never re-introduce the bug because there will always be a test for it. Speaking of the two mentioned cases: There was a bug within the gettext adapter which only occur on big endian encoding with particular 64bit machines. On other 64bit machines the problem did not show. The reason is a bug within php itself. How should I code a test, when I am not able to reproduce it ? And in my opinion the already written tests were broken within these machines. But the people who committed the bugs were not able to run unit tests on their machines. And I know that the bug was fixed because I gave the changed lines to the one who had the bug and he said it worked. The second bug I mentioned could not be reproduced... Wether by me nor by the one who wrote us the bug. I only added two exceptions for handling such impossible conditions. If this conditions arise someone has changed the locale source files and this is something I am not able to write a test for. Speaking of normal bugs, I am of course always writing the unit tests... If you look at the testbed for Zend_Date you will see that it is the biggest of the whole framework. This is normal coding process... No I can not... For example Zend_Date I've integrated new features (array access). But when there is a new bug I have to integrate it in trunk (where the new feature resists) and in maintenance. Otherwise the maintenance branch would also have the new feature integrated which is not allowed. You should simply checkout two working copies, one from the branch, and one from the trunk. This is how I've handled maintenance branches for years. That's exactly what I expected and asked for, but noone wanted to answer this definitly. Review: So I need review and integration of the following trunk changes: 5636 5720 5721 I would have to integrate them into the next tag release. All other changes could be reviewed 5693 5628 5618 5586 - 5613 and are for 1.1.0 Greetings Thomas I18N Team Leader
Re: [fw-general] Zend_Mail - how to use Zend_Mail_Transport_Smtp for googlemail.com
Hi, On 7/17/07, mike55 [EMAIL PROTECTED] wrote: hi, want to send an e-mail to [EMAIL PROTECTED] with Zend_Mail_Transport_Smtp. kepp getting the error: Warning: fgets() [function.fgets]: SSL: fatal protocol error in D:\adat\awebsites\ev-manager\mvc-site\lib\Zend\Mail\Protocol\Abstract.php on line 303 Fatal error: Exception thrown without a stack frame in Unknown on line 0 this is the code: I remember I got a fatal protocol error with Zend_Http_Client when the default SSL version was set to sslv2 or sslv3 instead of plain ssl inside the class file. This really had nothing to do with the configuration parameters I passed into the class on init. Now I did not have a chance to verify this with Zend_Mail_Transport_Smtp but you may look at the code directly and see if that is the case indeed. On Zend_Http_Client the fix was to use ssl because that autonegotiates the version during the handshake. Hope that helps, Till
Re: [fw-general] Re: Lifecycle Handling
Hy, The reason we asked for commits to the stable branch to be reviewed by another person (Zend or community) is so that we have another eye on commits that go into the stable releases. My past experience has been that sometimes bad fixes or API breaking fixes get commited (by accident) and I think this could help mitigate the risk. Yeah... I just remember the change which gavin made to the Zend_Date API which broke the complete class where I was nearly in giving up my work for Zend Framework. And it was a Zender who broke it. ;-) We intentionally don't limit this to Zenders. We think anyone who is well versed in the Zend Framework can be another helping eye on the commit. The person will not always be an expert on your code but might be able to catch some issues with the commit. Btw, you'd commit to trunk first so people would have an easy time to see the commit. I am with you in having things checked by minimum 4 eyes. But it seems that I am the only one who has questions on the practical useage for all... ;-) Better to have this questions answered early than too late ;-) In your case btw, Alex from our team would be a good person to have review the commits but anyone is fine. I know, otherwise I would have cc'ed my mails to another Zend'er ;-)) I know it's a bit of overhead but I think the additional process would help make sure we release high quality mini releases. Quality is really one of the key things which should set our project apart. Definitly... Just to mention: Dont only rely on code-quality... also documentation quality should be archived. Many of our contributors are no english natives. We should also think about having someone looking over documentation parts before they are integrated Greetings Thomas I18N Team Leader
Re: [fw-general] Re: Lifecycle Handling
Hy, which means that core-contributors have to have two released on their workstations. The trunk for new features and the branch for maintenance releases. That's what I asked for and noone was able to definitly say yes or no. I expect most people would not be very amused if I fix bugs only for 1.1 (trunk) instead of 1.0.x (branch) ;-) Greetings Thomas I18N Team Leader - Original Message - From: Bill Karwin [EMAIL PROTECTED] To: fw-general@lists.zend.com Sent: Tuesday, July 17, 2007 11:15 PM Subject: RE: [fw-general] Re: Lifecycle Handling -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] For example Zend_Date I've integrated new features (array access). But when there is a new bug I have to integrate it in trunk (where the new feature resists) and in maintenance. Otherwise the maintenance branch would also have the new feature integrated which is not allowed. This means there are a few choices: (a) Implement the same bug fix in a different way, to work with the code in the branch. But depending on the nature of the bug, this may be too much work. (b) Implement the bug fix in both trunk and branch, implemented in a way that doesn't rely on the new features. Sometimes this is possible, but sometimes it's not possible or it's too much work. (c) Fix the bug in the trunk but don't fix it in the branch. Users must wait until 1.1.0 to get some bug fixes. I think all cases will fit into the three choices above. :-) Regards, Bill Karwin
RE: [fw-general] Re: Lifecycle Handling
Yep this is the case. We do the same in the PHP project. Actually right now we have three (4.4.x, 5.2.x and 6.x). There's really no other way but we will try and aim to only have two at any given time (pray...). -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 3:00 PM To: Bill Karwin; fw-general@lists.zend.com Subject: Re: [fw-general] Re: Lifecycle Handling Hy, which means that core-contributors have to have two released on their workstations. The trunk for new features and the branch for maintenance releases. That's what I asked for and noone was able to definitly say yes or no. I expect most people would not be very amused if I fix bugs only for 1.1 (trunk) instead of 1.0.x (branch) ;-) Greetings Thomas I18N Team Leader - Original Message - From: Bill Karwin [EMAIL PROTECTED] To: fw-general@lists.zend.com Sent: Tuesday, July 17, 2007 11:15 PM Subject: RE: [fw-general] Re: Lifecycle Handling -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] For example Zend_Date I've integrated new features (array access). But when there is a new bug I have to integrate it in trunk (where the new feature resists) and in maintenance. Otherwise the maintenance branch would also have the new feature integrated which is not allowed. This means there are a few choices: (a) Implement the same bug fix in a different way, to work with the code in the branch. But depending on the nature of the bug, this may be too much work. (b) Implement the bug fix in both trunk and branch, implemented in a way that doesn't rely on the new features. Sometimes this is possible, but sometimes it's not possible or it's too much work. (c) Fix the bug in the trunk but don't fix it in the branch. Users must wait until 1.1.0 to get some bug fixes. I think all cases will fit into the three choices above. :-) Regards, Bill Karwin
RE: [fw-general] Re: Lifecycle Handling
Hi Thomas, You obviously can't do what you can't do. If you can't reproduce but had someone else validated that the fix is good then that's in the spirit of what we wrote. In most cases you should still be able to write a unit test that would fail on his system (otherwise how did he verify that it was fixed). Note: You did ask another person to verify your patch which is in the spirit of what we wrote. It's important to understand that these guidelines are trying to help everyone stick to a good high-quality process. We will have to tweak as we implement them in real-life. I think most would agree though that if we can follow this process we will end up a higher-quality project than most others. Just the notion of asking people to get peer review is something which is not implemented explicitly in most other projects. With the Zend Framework we don't only want to deliver best practices with the framework itself but also lead by example in how we develop, test and document. Andi -Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 2:34 PM To: Willie Alberty; Zend Framework Subject: Re: [fw-general] Re: Lifecycle Handling Hy, And exact here is my personal problem ;-) I am the main author and only person who codes all the I18N classes. There is no other contributor. So I must ask Zend to review my code. There may be no other core contributors for the i18n classes, but there are dozens of contributors to the framework. I monitor the i18n list as I'm sure many others do. if you need a reviewer, I'm sure any one of us would be happy to look at your code. Would be great... As always I am of course speaking out loud what others dont want to say because they are to shy ;-) And what about fixes which do not include unit tests ? For example... I am not able to write tests for issues which are related to 64bit machines only or for race conditions. Then how can you be sure that the bug has been fixed? Bug fixing is where unit tests truly shine: before you fix a bug, you write a test that shows the bug exists. Then you fix the bug. In this way, you can be assured that you will never re-introduce the bug because there will always be a test for it. Speaking of the two mentioned cases: There was a bug within the gettext adapter which only occur on big endian encoding with particular 64bit machines. On other 64bit machines the problem did not show. The reason is a bug within php itself. How should I code a test, when I am not able to reproduce it ? And in my opinion the already written tests were broken within these machines. But the people who committed the bugs were not able to run unit tests on their machines. And I know that the bug was fixed because I gave the changed lines to the one who had the bug and he said it worked. The second bug I mentioned could not be reproduced... Wether by me nor by the one who wrote us the bug. I only added two exceptions for handling such impossible conditions. If this conditions arise someone has changed the locale source files and this is something I am not able to write a test for. Speaking of normal bugs, I am of course always writing the unit tests... If you look at the testbed for Zend_Date you will see that it is the biggest of the whole framework. This is normal coding process... No I can not... For example Zend_Date I've integrated new features (array access). But when there is a new bug I have to integrate it in trunk (where the new feature resists) and in maintenance. Otherwise the maintenance branch would also have the new feature integrated which is not allowed. You should simply checkout two working copies, one from the branch, and one from the trunk. This is how I've handled maintenance branches for years. That's exactly what I expected and asked for, but noone wanted to answer this definitly. Review: So I need review and integration of the following trunk changes: 5636 5720 5721 I would have to integrate them into the next tag release. All other changes could be reviewed 5693 5628 5618 5586 - 5613 and are for 1.1.0 Greetings Thomas I18N Team Leader
RE: [fw-general] Re: Lifecycle Handling
-Original Message- From: Thomas Weidner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 2:58 PM To: Andi Gutmans; Darby Felton Cc: fw-general@lists.zend.com; Alexander Veremyev Subject: Re: [fw-general] Re: Lifecycle Handling Just to mention: Dont only rely on code-quality... also documentation quality should be archived. Many of our contributors are no english natives. We should also think about having someone looking over documentation parts before they are integrated yes, I agree. The only issue with that is that it should really be a technical writer and I don't have such a resource available right now. I will try and see what can be done though but not sure how much I can do. Andi
Re: [fw-general] Apply ajax in Zend Framework
1. /topath/application/controllers/VisitorController.php. Yes you can do it. 2. $this-getResponse()-setBody()... $this-getResponse()-setHeader()... minglee wrote: I am new to Zend Framework(ZF), and got confused when coding ajax: 1. Because ZF is using rewrite, how should I call the server-side action, for example: If I want to call registerAction in /topath/application/controllers/visitor.php, can I call like /visitor/register-- my .js file is in /topath/public/script/? 2. After handle the HttpRequest in visitor.php, how shall I output HTTP response, shall I use something $view-render() or just echo $response; ? Anyone can help with the above problems?! Many thanks! -- View this message in context: http://www.nabble.com/Apply-ajax-in-Zend-Framework-tf4101038s16154.html#a11662768 Sent from the Zend Framework mailing list archive at Nabble.com.
