Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Christopher Thompson]

Rob has very nicely broken down the use cases pretty much exactly as I 
see them as well.



Rob Allen wrote:

Andi Gutmans wrote:

Hi Ralf and all,

Bill and I spent some time reviewing all the proposals and also
brainstorming on what we think is right for Zend Framework. Our
suggestion is very close to what Ralf is suggesting but with a few
minor tweaks.


Good to see movement on this issue :)



Breaking them each out into separate classes
and files would probably lead to a real performance hit and would
require people to require_once() all those components over and over
again (which would also be a PITA).


I don't understand the "real performance hit". Could you elaborate?


I'd also be interested to see use-cases that show people having to
require_once() "over and over again" too. With autoload you just need to:
require('Zend/Loader.php');
spl_autoload_register(array('Zend_Loader', 'loadClass'));

If you don't want to autoload, then you care about performance to such a
degree that you probably only want to require the exact classes you need
when you need them and will manage that accordingly.



library/Zend/Core.php:
--

class Zend_Registry {
static public function register($index, $newval) null);
static public function registry($index = null);
static public function isRegistered($index);
static public function initRegistry($registry = 'Zend_Registry');
static public function __unsetRegistry();
}


I don't see the registry as core functionality unless another component
relies on it?

Also we already have a Zend/Registry.php containing Zend_Registry. If a
static interface is required for the registry, then we may as well just
add it to the current class.



class Zend_Loader {
  static public function loadClass($class, $dirs = null);
  static public function loadFile($filename, $dirs = null, $once = false);
  static public function isReadable($filename);
}


I can see the argument that this is core as other components rely on it.



class Zend_Framework {
static public function compareVersion($version)
const VERSION = '0.8.0dev';
}



I can see the argument for the VERSION const. I'm not 100% sure that
it's core, but can live with it.

I don't think Zend_Framework is a good class name though. Zend_Version
or Zend_FrameworkVersion would at least stop me thinking the class was
actually a Framework in itself. I'm easy on this though.


class Zend_Exception { ... }


Not core. It's not in Zend.php at the moment and seems to load itself
when needed.



// Could live with the following outside of Core.php but it's so small
it really isn't a big deal to keep it for convenience
class Zend_Debug {
static public function dump($var, $label=null, $echo=true)
}


Definitely not core. This will limit our ability to put in a more "fully
featured" Zend/Debug.php at a later date. Better to do that now and put
this class in its own file.


Regards,

Rob...

Re: [fw-general] Internationalization and the Zend Framework

[Thomas Weidner]

Now that conventional modular layouts are supported in the default 
configuration, for those using only one hostname, what about the 
following?

1. /:lang/:module/:controller/:action
2. /:module/:lang/:controller/:action
3. /:module/:controller/:action/lang/

I'm keenly interested in what others think here, since the ZF demo 
tutorial app. must choose one of these.  So far, it seems like #1 offers a 
clean approach.


I would propose the following layout...

/module/controller/action

And then additionaly redirectings like this

/de/module/controller/action -> /module/controller/action
/en/module/controller/action -> /module/controller/action
or simpler
/de/* -> /*


within
/language/*
The only thing you have to do is to change the standard language
$locale = new Zend_Locale($language);
-> redirect to /module/controller/action
and store it within the session cache


When you have to change a view it is then changed for all languages.
But, of course, you have to translate ALL output but this should be
standard for all multilingual sites.

Greetings
Thomas
I18N Team Leader 

Re: [fw-general] Internationalization and the Zend Framework

[Ralf Eggert]

Hi,

> Now that conventional modular layouts are supported in the default 
> configuration, for those using only one hostname, what about the following?
> 1. /:lang/:module/:controller/:action
> 2. /:module/:lang/:controller/:action
> 3. /:module/:controller/:action/lang/

For my project I will use the so-called "Wikipedia/Yahoo" approach, i.e.
keep the language in a sub domain. This approach shortens the URLs a
little and is used in many big international sites:

www.myproject.com  // international, i.e. English
de.myproject.com   // German
es.myproject.com   // Spanish
fr.myproject.com   // French

The route can simple be :module/:controller/:action then and the
language is read in my configuration script which is called by my
bootstrap file. Then the language is passed to the request object as a
parameter.

Best Regards,

Ralf

Re: [fw-general] Internationalization and the Zend Framework

[Thomas Weidner]

Well...

Our multilingual application has the language of the user within the 
session...

There would be no need to have a directory structure like

/de/controller/action
/en/controller/action

a

/controller/action

would also work.

The only question you have to know yourself is, if a user should always see 
which language he has from the URL displayed...


Btw:
Having identical views, one for each language is no good solution.
If you change the layout or the content you have always to change the other 
languages exact the same way... unnecessary.


Greetings
Thomas
I18N Team Leader

- Original Message - 
From: "Kevin McArthur" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, February 28, 2007 12:51 AM
Subject: [fw-general] Internationalization and the Zend Framework


I'm wondering if anyone has done a multi-lingual site using the ZF yet and 
is willing to share their setup.


I'm currently developing a site for both English and Canadian French, both 
output and text-input. I'm fairly well versed on the input side, but how are 
you guys developing the templating side.


I'm thinking a url-based approach to en/fr content following a new default 
route like ':lang/:controller/:action', then splitting the views into two 
identical structures, but translated.


However, others have pointed out the xml:lang attribute, and suggested 
http://www.w3.org/TR/REC-xml/#sec-lang-tag style 
multiple-languages-in-a-single-file approach. Has anyone had success at 
this?


Anyone want to share their setup?

Kevin McArthur 

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Rob Allen]

Andi Gutmans wrote:
> Hi Ralf and all,
>
> Bill and I spent some time reviewing all the proposals and also
> brainstorming on what we think is right for Zend Framework. Our
> suggestion is very close to what Ralf is suggesting but with a few
> minor tweaks.

Good to see movement on this issue :)


> Breaking them each out into separate classes
> and files would probably lead to a real performance hit and would
> require people to require_once() all those components over and over
> again (which would also be a PITA).

I don't understand the "real performance hit". Could you elaborate?


I'd also be interested to see use-cases that show people having to
require_once() "over and over again" too. With autoload you just need to:
require('Zend/Loader.php');
spl_autoload_register(array('Zend_Loader', 'loadClass'));

If you don't want to autoload, then you care about performance to such a
degree that you probably only want to require the exact classes you need
when you need them and will manage that accordingly.


> library/Zend/Core.php:
> --
> 
> class Zend_Registry {
> static public function register($index, $newval) null);
> static public function registry($index = null);
> static public function isRegistered($index);
> static public function initRegistry($registry = 'Zend_Registry');
> static public function __unsetRegistry();
> }

I don't see the registry as core functionality unless another component
relies on it?

Also we already have a Zend/Registry.php containing Zend_Registry. If a
static interface is required for the registry, then we may as well just
add it to the current class.


> class Zend_Loader {
>   static public function loadClass($class, $dirs = null);
>   static public function loadFile($filename, $dirs = null, $once = false);
>   static public function isReadable($filename);
> }

I can see the argument that this is core as other components rely on it.


> class Zend_Framework {
> static public function compareVersion($version)
> const VERSION = '0.8.0dev';
> }
> 

I can see the argument for the VERSION const. I'm not 100% sure that
it's core, but can live with it.

I don't think Zend_Framework is a good class name though. Zend_Version
or Zend_FrameworkVersion would at least stop me thinking the class was
actually a Framework in itself. I'm easy on this though.

> class Zend_Exception { ... }

Not core. It's not in Zend.php at the moment and seems to load itself
when needed.


> // Could live with the following outside of Core.php but it's so small
> it really isn't a big deal to keep it for convenience
> class Zend_Debug {
> static public function dump($var, $label=null, $echo=true)
> }

Definitely not core. This will limit our ability to put in a more "fully
featured" Zend/Debug.php at a later date. Better to do that now and put
this class in its own file.


Regards,

Rob...

RE: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Andi Gutmans]

If we separate it into separate files, what files do you see yourself
requiring? What would you think the typical user will do?

We could just go down the separation path. I'm just worried it's going
to be a PITA to require the various classes. It also doesn't give us a
centralized bootstrap if we require it down the road (I don't expect all
to use the MVC).

Btw, in an answer to that Wiki entry of yours (and not necessarily
related to this argument) I definitely don't want to be overly rigid in
the framework if it comes at the expense of ease-of-use. That's exactly
what Java preferred and hence it became too complicated. Actually
everything we are trying to do is to be lax with the features set so
that we provide a simple and easy-to-use solution.


Andi

> -Original Message-
> From: Ralph Schindler [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 27, 2007 10:15 PM
> To: fw-general@lists.zend.com
> Subject: Re: [fw-general] Request for feedback: moving 
> Zend.php to Zend/Zend.php
> 
> I gotta agree with Christopher on this one.. I have zero 
> intentions of using the 'Registry' in 80%+ of my projects.. I 
> find that the controllers invoke params suit all my needs.  
> As for debug, I simply cant find any justification for 
> loading that into production/runtime..
> 
> To reiterate a very important point I've made in the past 
> (actually 2):
> http://www.nabble.com/Re%3A-Request-for-feedback%3A-moving-Zen
> d.php-to-Zend-Zend.php-p9152637s16154.html
> 
> 1) this adds to the schizophrenic nature of the class. (what 
> does it really do?) and,
> 2) its a bad thing that the first file presented to a new 
> ZendFrameworker is an 'exception to the rules'
> 
> I think we should still set aside performance hacks until 
> later.. which ultimately seems to be the only reason for doing this.
> 
> my 2cents.
> -ralph
> 
> Christopher Thompson wrote:
> > The only real reason given for Zend/Core.php containing 
> four classes 
> > is for performance, but I think it will actually have the 
> opposite effect.
> > The only class really used in the framework is Zend_Loader. 
> Exceptions 
> > are lazy loaded, the Registry is a userland thing, and the 
> > Zend_Framework class is only informational. All that is minimally 
> > needed is Zend_Loader, so with Zend/Core.php you are 
> actually loading 
> > a bunch of possibly unused code every request.
> > 
> > 
> 
> 

RE: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Andi Gutmans]

First of all it's not only performance. I also mentioned ease-of-use and
simplicity. Not requiring to require_once() few files (which is one
reason we did Zend:: to begin with).
Second, Zend_Exception is not lazy loaded, Zend_Registry is used all the
time, 
Third, with a byte code cache it won't matter. The overhead is per-file
not really per-class.

Andi 

> -Original Message-
> From: Christopher Thompson [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 27, 2007 9:56 PM
> Cc: fw-general@lists.zend.com
> Subject: Re: [fw-general] Request for feedback: moving 
> Zend.php to Zend/Zend.php
> 
> The only real reason given for Zend/Core.php containing four 
> classes is for performance, but I think it will actually have 
> the opposite effect. 
> The only class really used in the framework is Zend_Loader. 
> Exceptions are lazy loaded, the Registry is a userland thing, 
> and the Zend_Framework class is only informational. All that 
> is minimally needed is Zend_Loader, so with Zend/Core.php you 
> are actually loading a bunch of possibly unused code every request.
> 
> 
> Andi Gutmans wrote:
> > Hi Ralf and all,
> > 
> > Bill and I spent some time reviewing all the proposals and also 
> > brainstorming on what we think is right for Zend Framework. Our 
> > suggestion is very close to what Ralf is suggesting but with a few 
> > minor tweaks.
> > 
> > We still believe having all the core functionality in one file is 
> > beneficial. While we want to keep the framework as loosely 
> coupled as 
> > possible there are some key APIs which are pretty much used 
> > universally throughout the framework. Breaking them each out into 
> > separate classes and files would probably lead to a real 
> performance 
> > hit and would require people to require_once() all those components 
> > over and over again (which would also be a PITA).
> > We therefore suggest that these key classes (previously known as 
> > Zend::) all are put in the Zend/Core.php file.
> > This would not only retain good performance but it would 
> also fit the 
> > simplicity goal and make it easy for people to get all the 
> necessary 
> > infrastructure. Also, we think it'd make sense to stick 
> Zend_Exception 
> > there too as it also falls into the category of a class 
> which is used 
> > everywhere. To be clear: We are not suggesting a file which 
> is bloated 
> > by lots and lots of classes which aren't necessarily used. 
> We want to 
> > keep it lean-and-mean but with the stuff that really matters.
> > 
> > So the following is what it'd look like (pretty much in the 
> spirit of 
> > what Ralf proposed):
> > 
> > library/Zend/Core.php:
> > --
> > 
> > class Zend_Registry {
> > static public function register($index, $newval) null);
> > static public function registry($index = null);
> > static public function isRegistered($index);
> > static public function initRegistry($registry = 
> 'Zend_Registry');
> > static public function __unsetRegistry(); }
> > 
> > class Zend_Loader {
> > static public function loadClass($class, $dirs = null);
> > static public function loadFile($filename, $dirs = 
> null, $once = 
> > false);
> > static public function isReadable($filename); }
> >  
> > class Zend_Framework {
> > static public function compareVersion($version)
> > const VERSION = '0.8.0dev';
> > }
> > 
> > class Zend_Exception { ... }
> > 
> > 
> > // Could live with the following outside of Core.php but 
> it's so small 
> > it really isn't a big deal to keep it for convenience class 
> Zend_Debug 
> > {
> > static public function dump($var, $label=null, $echo=true) }
> > 
> > We have two weeks to finalize this and make all the changes 
> (shouldn't 
> > be too hard as it can be done with a script). We don't want 
> to change 
> > any APIs anymore once 0.9 is shipped but only focus on bug 
> fixes, and 
> > improving documentation and unit tests.
> > 
> > Andi
> > 
> >> -Original Message-
> >> From: Ralf Eggert [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, February 26, 2007 1:58 AM
> >> To: fw-general@lists.zend.com
> >> Subject: Re: [fw-general] Request for feedback: moving Zend.php to 
> >> Zend/Zend.php
> >>
> >> Hi,
> >>
> >> I personally think that the proposed renaming of the Zend class to 
> >> Zend_Framework is very misleading. I would expect that a 
> >> Zend_Framework class will set up the whole framework and 
> not be just 
> >> a funny conglomeration of methods who did not find their way to a 
> >> proper component.
> >>
> >> Here are my suggestions:
> >>
> >> - move Zend::register(), Zend::registry(), Zend::isRegistered(),
> >>   Zend::initRegistry() and Zend::__unsetRegistry() to Zend_Registry
> >>
> >> - drop Zend::exception() and Zend::loadInterface()
> >>
> >> - move Zend::loadClass(), Zend::loadFile() and 
> Zend::isReadable() to
> >>   a new Zend_Loader class
> >>
> >> - as suggested by others, move Zend::dump() to Zend_Debug
> >>
> >> - the onl

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Rob Allen]

Nick Lo wrote:
> I noticed a few comments to the effect that Zend.php makes a good entry
> point into the framework. I really don't see how this is the case. The
> entry point for anyone wanting to get a grasp on the framework is the
> bootstrap file not Zend.php.

I agree. To understand the MVC framework , then you need to start with
the bootstrap. To understand any of the "peripheral" components, then
you need to start with the manual!

> If anything Zend.php is a confusing class that immediately presents
> beginners with exceptions to the general framework setup. 

Yes. I tried explaining Zend.php to a colleague who's building our next
ZF app and failed. I ended up saying that it's a bucket of stuff useful
stuff, because there's no logical explanation for the list of
responsibilities that Zend.php has.

Regards,

Rob...

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Ralph Schindler]

I gotta agree with Christopher on this one.. I have zero intentions of 
using the 'Registry' in 80%+ of my projects.. I find that the 
controllers invoke params suit all my needs.  As for debug, I simply 
cant find any justification for loading that into production/runtime..


To reiterate a very important point I've made in the past (actually 2):
http://www.nabble.com/Re%3A-Request-for-feedback%3A-moving-Zend.php-to-Zend-Zend.php-p9152637s16154.html

1) this adds to the schizophrenic nature of the class. (what does it 
really do?) and,
2) its a bad thing that the first file presented to a new 
ZendFrameworker is an 'exception to the rules'


I think we should still set aside performance hacks until later.. which 
ultimately seems to be the only reason for doing this.


my 2cents.
-ralph

Christopher Thompson wrote:
The only real reason given for Zend/Core.php containing four classes is 
for performance, but I think it will actually have the opposite effect. 
The only class really used in the framework is Zend_Loader. Exceptions 
are lazy loaded, the Registry is a userland thing, and the 
Zend_Framework class is only informational. All that is minimally needed 
is Zend_Loader, so with Zend/Core.php you are actually loading a bunch 
of possibly unused code every request.

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Christopher Thompson]

The only real reason given for Zend/Core.php containing four classes is 
for performance, but I think it will actually have the opposite effect. 
The only class really used in the framework is Zend_Loader. Exceptions 
are lazy loaded, the Registry is a userland thing, and the 
Zend_Framework class is only informational. All that is minimally needed 
is Zend_Loader, so with Zend/Core.php you are actually loading a bunch 
of possibly unused code every request.



Andi Gutmans wrote:

Hi Ralf and all,

Bill and I spent some time reviewing all the proposals and also
brainstorming on what we think is right for Zend Framework. Our
suggestion is very close to what Ralf is suggesting but with a few minor
tweaks.

We still believe having all the core functionality in one file is
beneficial. While we want to keep the framework as loosely coupled as
possible there are some key APIs which are pretty much used universally
throughout the framework. Breaking them each out into separate classes
and files would probably lead to a real performance hit and would
require people to require_once() all those components over and over
again (which would also be a PITA).
We therefore suggest that these key classes (previously known as Zend::)
all are put in the Zend/Core.php file.
This would not only retain good performance but it would also fit the
simplicity goal and make it easy for people to get all the necessary
infrastructure. Also, we think it'd make sense to stick Zend_Exception
there too as it also falls into the category of a class which is used
everywhere. To be clear: We are not suggesting a file which is bloated
by lots and lots of classes which aren't necessarily used. We want to
keep it lean-and-mean but with the stuff that really matters.

So the following is what it'd look like (pretty much in the spirit of
what Ralf proposed):

library/Zend/Core.php:
--

class Zend_Registry {
static public function register($index, $newval) null);
static public function registry($index = null);
static public function isRegistered($index);
static public function initRegistry($registry = 'Zend_Registry');
static public function __unsetRegistry();
}

class Zend_Loader {
static public function loadClass($class, $dirs = null);
static public function loadFile($filename, $dirs = null, $once =
false);
static public function isReadable($filename);
}
 
class Zend_Framework {

static public function compareVersion($version)
const VERSION = '0.8.0dev';
}

class Zend_Exception { ... }


// Could live with the following outside of Core.php but it's so small
it really isn't a big deal to keep it for convenience
class Zend_Debug {
static public function dump($var, $label=null, $echo=true)
}

We have two weeks to finalize this and make all the changes (shouldn't
be too hard as it can be done with a script). We don't want to change
any APIs anymore once 0.9 is shipped but only focus on bug fixes, and
improving documentation and unit tests.

Andi


-Original Message-
From: Ralf Eggert [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 26, 2007 1:58 AM

To: fw-general@lists.zend.com
Subject: Re: [fw-general] Request for feedback: moving 
Zend.php to Zend/Zend.php


Hi,

I personally think that the proposed renaming of the Zend 
class to Zend_Framework is very misleading. I would expect 
that a Zend_Framework class will set up the whole framework 
and not be just a funny conglomeration of methods who did not 
find their way to a proper component.


Here are my suggestions:

- move Zend::register(), Zend::registry(), Zend::isRegistered(),
  Zend::initRegistry() and Zend::__unsetRegistry() to Zend_Registry

- drop Zend::exception() and Zend::loadInterface()

- move Zend::loadClass(), Zend::loadFile() and Zend::isReadable() to
  a new Zend_Loader class

- as suggested by others, move Zend::dump() to Zend_Debug

- the only method I am not sure about yet is 
Zend::compareVersion() but

  I bet we will find a solution for this as well

Like others I would also suggest to implement these changes 
before the 0.9.0 beta release gets launched.


Best Regards,

Ralf

RE: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Andi Gutmans]

Hi Ralf and all,

Bill and I spent some time reviewing all the proposals and also
brainstorming on what we think is right for Zend Framework. Our
suggestion is very close to what Ralf is suggesting but with a few minor
tweaks.

We still believe having all the core functionality in one file is
beneficial. While we want to keep the framework as loosely coupled as
possible there are some key APIs which are pretty much used universally
throughout the framework. Breaking them each out into separate classes
and files would probably lead to a real performance hit and would
require people to require_once() all those components over and over
again (which would also be a PITA).
We therefore suggest that these key classes (previously known as Zend::)
all are put in the Zend/Core.php file.
This would not only retain good performance but it would also fit the
simplicity goal and make it easy for people to get all the necessary
infrastructure. Also, we think it'd make sense to stick Zend_Exception
there too as it also falls into the category of a class which is used
everywhere. To be clear: We are not suggesting a file which is bloated
by lots and lots of classes which aren't necessarily used. We want to
keep it lean-and-mean but with the stuff that really matters.

So the following is what it'd look like (pretty much in the spirit of
what Ralf proposed):

library/Zend/Core.php:
--

class Zend_Registry {
static public function register($index, $newval) null);
static public function registry($index = null);
static public function isRegistered($index);
static public function initRegistry($registry = 'Zend_Registry');
static public function __unsetRegistry();
}

class Zend_Loader {
static public function loadClass($class, $dirs = null);
static public function loadFile($filename, $dirs = null, $once =
false);
static public function isReadable($filename);
}
 
class Zend_Framework {
static public function compareVersion($version)
const VERSION = '0.8.0dev';
}

class Zend_Exception { ... }


// Could live with the following outside of Core.php but it's so small
it really isn't a big deal to keep it for convenience
class Zend_Debug {
static public function dump($var, $label=null, $echo=true)
}

We have two weeks to finalize this and make all the changes (shouldn't
be too hard as it can be done with a script). We don't want to change
any APIs anymore once 0.9 is shipped but only focus on bug fixes, and
improving documentation and unit tests.

Andi

> -Original Message-
> From: Ralf Eggert [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 26, 2007 1:58 AM
> To: fw-general@lists.zend.com
> Subject: Re: [fw-general] Request for feedback: moving 
> Zend.php to Zend/Zend.php
> 
> Hi,
> 
> I personally think that the proposed renaming of the Zend 
> class to Zend_Framework is very misleading. I would expect 
> that a Zend_Framework class will set up the whole framework 
> and not be just a funny conglomeration of methods who did not 
> find their way to a proper component.
> 
> Here are my suggestions:
> 
> - move Zend::register(), Zend::registry(), Zend::isRegistered(),
>   Zend::initRegistry() and Zend::__unsetRegistry() to Zend_Registry
> 
> - drop Zend::exception() and Zend::loadInterface()
> 
> - move Zend::loadClass(), Zend::loadFile() and Zend::isReadable() to
>   a new Zend_Loader class
> 
> - as suggested by others, move Zend::dump() to Zend_Debug
> 
> - the only method I am not sure about yet is 
> Zend::compareVersion() but
>   I bet we will find a solution for this as well
> 
> Like others I would also suggest to implement these changes 
> before the 0.9.0 beta release gets launched.
> 
> Best Regards,
> 
> Ralf
> 
> 

Re: [fw-general] catching xml document errors with Zend_Rest_Client_Result

[Michael Depetrillo]

After some more research I realized I could check the status of the response
by accessing the response object directly.

What I am still unsure of is how to calculate the string size of the Request
Body.  I've commented out the Content-Length header in the following
example.  Does anyone know how I could do this?

   $aim = new Zend_Rest_Client('
http://www.domain.com/providers/service.asmx/Action');
   $aim->providerID()->userName('mike');
   $aim->getHttpClient()->setHeaders(array(
  'Content-Type'   => 'application/x-www-form-urlencoded',
  //'Content-Length' => 'length',
   ));
   // Execure soap request
   $result = $aim->get();

   // Check if response returned correctly
   if ($aim->getHttpClient()->getLastResponse()->isError()) {
   // Log errors
   } else {
   // Continue normally.
   }

On 2/27/07, Pádraic Brady <[EMAIL PROTECTED]> wrote:


It's down to getting the class to check whether SimpleXML could parse the
document (creating an object of type SimpleXMLElement) and throwing an
exception you could catch in your own code. Have you added this as an issue
to the issue tracker for Zend_Rest_Client?

I'd agree it's "bad" behaviour, there nothing to catch so one could handle
the error more appropriately before execution is halted and the user gets a
blank page or something just as annoying.

Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Michael Depetrillo <[EMAIL PROTECTED]>
To: Zend Framework General 
Sent: Tuesday, February 27, 2007 6:31:11 PM
Subject: [fw-general] catching xml document errors with
Zend_Rest_Client_Result

Hello

Our business works works with numerous third-party soap services.
Sometimes these companies screw up and return an improperly formated XML
document.  Using Zend_Rest_Client a PHP warning will occur followed by a
fatal error.

I was wondering how I might be able to catch these types of errors so they
could be properly dealt with.

Here is an example error message that occurs when improperly formated XML
is returned.

Warning: simplexml_load_string(): Entity: line 1: parser error : Start tag
expected, '<' not found in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 44
Warning: simplexml_load_string(): System.InvalidOperationException: There
was an error generating the XML document in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 44
Warning: simplexml_load_string(): ^ in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 44
Fatal error: Call to a member function xpath() on a non-object in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 71

--
Michael DePetrillo
[EMAIL PROTECTED]
Home:  (858) 926-5761
Mobile: (858) 761-1605
AIM: klassicd


--
The fish are biting.
 Get more 
visitorson
 your site using Yahoo!
Search Marketing.





--
Michael DePetrillo
[EMAIL PROTECTED]
Home:  (858) 926-5761
Mobile: (858) 761-1605
AIM: klassicd

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Christopher Thompson]

+1 (belated) to Ralf's suggestions.


Ralf Eggert wrote:

Hi,

I personally think that the proposed renaming of the Zend class to
Zend_Framework is very misleading. I would expect that a Zend_Framework
class will set up the whole framework and not be just a funny
conglomeration of methods who did not find their way to a proper component.

Here are my suggestions:

- move Zend::register(), Zend::registry(), Zend::isRegistered(),
  Zend::initRegistry() and Zend::__unsetRegistry() to Zend_Registry

- drop Zend::exception() and Zend::loadInterface()

- move Zend::loadClass(), Zend::loadFile() and Zend::isReadable() to
  a new Zend_Loader class

- as suggested by others, move Zend::dump() to Zend_Debug

- the only method I am not sure about yet is Zend::compareVersion() but
  I bet we will find a solution for this as well

Like others I would also suggest to implement these changes before the
0.9.0 beta release gets launched.

Best Regards,

Ralf

Re: [fw-general] Internationalization and the Zend Framework

[Kevin McArthur]

When serving any logical page using the same URL, but with dynamically 
chosen language content on the page, I would carefully test the results 
against the search engines you care about, before using that approach. 
Sometimes practical matters interfere with academics.


Good point.

Now that conventional modular layouts are supported in the default 
configuration, for those using only one hostname, what about the 
following?

1. /:lang/:module/:controller/:action
2. /:module/:lang/:controller/:action
3. /:module/:controller/:action/lang/


I'd vote for #1.

Kevin 

Re: [fw-general] Internationalization and the Zend Framework

[Gavin Vess]

When serving any logical page using the same URL, but with dynamically 
chosen language content on the page, I would carefully test the results 
against the search engines you care about, before using that approach.  
Sometimes practical matters interfere with academics.


Now that conventional modular layouts are supported in the default 
configuration, for those using only one hostname, what about the following?

1. /:lang/:module/:controller/:action
2. /:module/:lang/:controller/:action
3. /:module/:controller/:action/lang/

I'm keenly interested in what others think here, since the ZF demo 
tutorial app. must choose one of these.  So far, it seems like #1 offers 
a clean approach.


Cheers,
Gavin

Kevin McArthur wrote:
I'm wondering if anyone has done a multi-lingual site using the ZF yet 
and is willing to share their setup.
 
I'm currently developing a site for both English and Canadian French, 
both output and text-input. I'm fairly well versed on the input side, 
but how are you guys developing the templating side.
 
I'm thinking a url-based approach to en/fr content following a new 
default route like ':lang/:controller/:action', then splitting the 
views into two identical structures, but translated.
 
However, others have pointed out the xml:lang attribute, and suggested 
http://www.w3.org/TR/REC-xml/#sec-lang-tag style 
multiple-languages-in-a-single-file approach. Has anyone had success 
at this?
 
Anyone want to share their setup?
 
Kevin McArthur

[fw-general] Lucene: using delete and add on a doc .. then doc not avail untill optimize() are used.. how come ++?

[bongobongo]

Hi.

Testing on Win XP and Zend Framework 0.8.0...

Have some questions about zend search lucene 

When I use the delete and add methods to simulate an update, then, from my
experience, I have to use
optimize method to make that document visible for a query.

Actually, when working on an exisiting index, adding a doc also require the
use of optimize for the doc to turn up in the hit list.

Is it supposed to be like this, or is it a bug?

>From the add and update example from the manual I cannot see any mention
that I should have to use optimize to make the newly added docs "visible" in
the index for a query.

Now, if we have to use optimize() to make the docs visible in index 
(maybe nice if you say in that example as well as for add example that the
optimize has to be used to make it searcable.)
what is actually happening when the segment files are merged?
What time frames are we talking about here?
Are the "old" index searchable while the merge is taking place?
How are existing queries being handled in a merge situation?

Is there any plans on rewriting this zend lucene into core PHP functions as
to speed up the
indexing and search functionality at a laiter stage... when the zend search
has matured?

Regards
-- 
View this message in context: 
http://www.nabble.com/Lucene%3A-using-delete-and-add-on-a-doc-..-then-doc-not-avail-untill-optimize%28%29-are-used..-how-come-%2B%2B--tf3306025s16154.html#a9196278
Sent from the Zend Framework mailing list archive at Nabble.com.

[fw-general] Internationalization and the Zend Framework

[Kevin McArthur]

I'm wondering if anyone has done a multi-lingual site using the ZF yet and is 
willing to share their setup.

I'm currently developing a site for both English and Canadian French, both 
output and text-input. I'm fairly well versed on the input side, but how are 
you guys developing the templating side.

I'm thinking a url-based approach to en/fr content following a new default 
route like ':lang/:controller/:action', then splitting the views into two 
identical structures, but translated.

However, others have pointed out the xml:lang attribute, and suggested 
http://www.w3.org/TR/REC-xml/#sec-lang-tag style 
multiple-languages-in-a-single-file approach. Has anyone had success at this?

Anyone want to share their setup?

Kevin McArthur

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Nick Lo]

I noticed a few comments to the effect that Zend.php makes a good  
entry point into the framework. I really don't see how this is the  
case. The entry point for anyone wanting to get a grasp on the  
framework is the bootstrap file not Zend.php.


If anything Zend.php is a confusing class that immediately presents  
beginners with exceptions to the general framework setup. I think  
Ralf Eggert has nailed it in his component breakdown and in  
comparison to "Zend" would be easier to understand since...


Zend_Registry
Zend_Loader
Zend_Debug

...are relatively self explanatory. They are also the kind of classes  
that many of us probably already have in previous frameworks to one  
degree or another.


Nick

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Andries Seutens]

Right...

Don't forget the very essence of a framework. Yes, that is correct, a 
framework, not a package repository. The framework will always be 
released as a "whole", not in separated packages.


Current naming conventions are just fine. It's just Zend.php that could 
use some reorganisation, as we "all" agreed.


Best,

Andriesss

Philip Iezzi schreef:

I'd prefer Zend_Filtered_Filthy_Fill_Filter_Filter_Filter !
This would make life so much easier.
To cache a cache may also be more efficient, who knows. I'd definitely use 
Zend_Cache_Cache. We also do zip our jpegs, right?


Stanislav Malyshev wrote:

Really no need to tell if a given name represents a package or not.  Zend
..Filter
Filter.php contains Zend_Filter_Filter
Alpha.php contains Zend_Filter_Alpha

Zend_Filter_Filter? So instead of Zend_Json we'd have Zend_Json_Json? I
don't like it at all.


It really does make sense and except for doubling up some of the top
level
class names has no impact on the current design.

I'm afraid Zend_Filter_Filter doesn't make any sense to me.

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Philip Iezzi]

I'd prefer Zend_Filtered_Filthy_Fill_Filter_Filter_Filter !
This would make life so much easier.
To cache a cache may also be more efficient, who knows. I'd definitely use 
Zend_Cache_Cache. We also do zip our jpegs, right?


Stanislav Malyshev wrote:
>> Really no need to tell if a given name represents a package or not.  Zend
>> ..Filter
>> Filter.php contains Zend_Filter_Filter
>> Alpha.php contains Zend_Filter_Alpha
> 
> Zend_Filter_Filter? So instead of Zend_Json we'd have Zend_Json_Json? I
> don't like it at all.
> 
>> It really does make sense and except for doubling up some of the top
>> level
>> class names has no impact on the current design.
> 
> I'm afraid Zend_Filter_Filter doesn't make any sense to me.

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Stanislav Malyshev]

Zend_Acl_Role  => Zend_Acl_Role_Role
Zend_Acl_Resource  => Zend_Acl_Resource_Resource
Zend_Cache => Zend_Cache_Cache


That's really no good... What should Cache-Cache mean?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Stanislav Malyshev]

Really no need to tell if a given name represents a package or not.  
Zend

..Filter
Filter.php contains Zend_Filter_Filter
Alpha.php contains Zend_Filter_Alpha


Zend_Filter_Filter? So instead of Zend_Json we'd have Zend_Json_Json? I 
don't like it at all.



It really does make sense and except for doubling up some of the top level
class names has no impact on the current design.


I'm afraid Zend_Filter_Filter doesn't make any sense to me.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Simon Mundy]

I don't quite see the point of this at all.

How is a Zend_Cache_Cache more useful than a Zend_Cache? It reduced  
the clarity of a component name if you start adding unnecessary  
suffixes to it.


It seems the only benefit here is to 'clean up' the core Zend folder  
and I don't see that as much of a benefit.


As I said before, I _can_ see the benefit of moving Zend.php to  
Zend_Core.php so that the entire framework can be encapsulated within  
one folder, but the idea of moving all the other top-level components  
doesn't make too much sense, has litle benefit and will cause a huge  
amount of work to developers who have existing code.


Here are a few more examples of renaming the top-level class/sub- 
class names:


Zend_Acl_Role  => Zend_Acl_Role_Role
Zend_Acl_Resource  => Zend_Acl_Resource_Resource
Zend_Cache => Zend_Cache_Cache
Zend_Cache_Backend => Zend_Cache_Cache_Backend_Backend
Zend_Db=> Zend_Db_Db
Zend_Db_Profiler   => Zend_Db_Profiler_Profiler
Zend_Db_Select => Zend_Db_Select_Select
Zend_Db_Statement  => Zend_Db_Statement_Statement
Zend_Db_Adapter_Oracle => Zend_Db_Adapter_Oracle_Oracle
Zend_Db_Table_Row  => Zend_Db_Table_Row_Row
Zend_Locale_Data   => Zend_Locale_Data_Data
...
...


--

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] Request for feedback: moving Zend.php to Zend/Zend.php

[Matthew Ratzloff]

> Here are a few more examples of renaming the top-level class/sub-class
> names:
>
>   Zend_Acl_Role  => Zend_Acl_Role_Role
> Zend_Acl_Resource  => Zend_Acl_Resource_Resource
> Zend_Cache => Zend_Cache_Cache
> Zend_Cache_Backend => Zend_Cache_Cache_Backend_Backend
> Zend_Db=> Zend_Db_Db
>  Zend_Db_Profiler   => Zend_Db_Profiler_Profiler
>
> [...]

This isn't intuitive or desirable in my view.  While modularization has
always been a positive aspect of Zend Framework (the ability to just use
Zend_Mail in your application, for example), it doesn't mean each
component is standalone.  Zend_Mail depends on Zend_Mime, Zend_Exception,
and maybe some other things.  Upgrading just Zend_Mail might break your
application if you fail to account for the other dependencies.

Packaging it in this way has a very small benefit for a single use case
(svn:externals) at the expense of a much less intuitive API.  I mean, even
you were tripped up by Zend_Cache_Backend_Backend.  Plus, class names are
long enough already.  If loadClass() were revamped to accomodate this
alternate file scheme and the class names were kept the same (i.e.,
Zend_Cache_Backend refers to Zend/Cache/Backend/Backend.php), that is even
worse.

-Matt

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Shekar C Reddy]

Here are a few more examples of renaming the top-level class/sub-class
names:

 Zend_Acl_Role  => Zend_Acl_Role_Role
Zend_Acl_Resource  => Zend_Acl_Resource_Resource
Zend_Cache => Zend_Cache_Cache
Zend_Cache_Backend => Zend_Cache_Cache_Backend_Backend
Zend_Db=> Zend_Db_Db
Zend_Db_Profiler   => Zend_Db_Profiler_Profiler
Zend_Db_Select => Zend_Db_Select_Select
Zend_Db_Statement  => Zend_Db_Statement_Statement
Zend_Db_Adapter_Oracle => Zend_Db_Adapter_Oracle_Oracle
Zend_Db_Table_Row  => Zend_Db_Table_Row_Row
Zend_Locale_Data   => Zend_Locale_Data_Data
...
...


As you can see, it's just the top-level class/sub-class names that are
getting renamed while the directories are getting more and more organized.
For instance, currently the Zend/Db/Adapter/Db2, Zend/Db/Adapter/Oracle and
Zend/Db/Table/Row folders have just one file each: Exception.php. After the
change, they would additionally have Db2.php, Oracle.php and Row.php -
relevantly. It's like taking the PEAR naming-convention to the next (Java
packages) level.

Regards,




On 2/27/07, Art Hundiak <[EMAIL PROTECTED]> wrote:



Really no need to tell if a given name represents a package or not.
Zend
..Filter
Filter.php contains Zend_Filter_Filter
Alpha.php contains Zend_Filter_Alpha

So the only change is the name of the top level class in a package.  The
autoload routine remains unchanged.

And of course if there was a module that was more or less independent from
the other filter modules (perhaps some code for a specific language) then
you could make is a subpackage.

It really does make sense and except for doubling up some of the top level
class names has no impact on the current design.



Stanislav Malyshev wrote:
>
>> The problem is that in Zend/ directory there are a lot of php files:
>
> Ok, there is. Why it is a problem though?
>
>> It would be much better to move them to:
>> Acl/Acl.php
>
> Ok, and Zend_Acl_Adapter would be in Acl/Adapter/Adapter.php or in
> Acl/Adapter.php? If the former - how it's not directory per file? If the
> latter, why Zend_Acl gets subdirectory and Zend_Acl_Adapter not and how
> one is to know that by the name?
>
>> So this means that all package files would be in package directory. If
u
>> need only one package u take the package directory.
>
> How do I know Zend_Foo_Bar_Baz is a package or part of Zend_Foo_Bar
> package or part of Zend_Foo package?
>
>> If file is in a directory - it is in package, and u know package
>> name[directory name]
>
> How do I know the directory name? You seem to have different rules for
> "packages" and "not packages" but I fail to see how do you know the name
> is package or not.
> --
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED]  http://www.zend.com/
>
>
>

--
View this message in context:
http://www.nabble.com/Request-for-feedback%3A-moving-Zend.php-to-Zend-Zend.php-tf3290016s16154.html#a9190465
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Gavin Vess]

Even if not everyone wants the features below, certainly many developers 
will implement similar capabilities, if not found in the ZF.  My 
intention behind http://framework.zend.com/wiki/x/j1 is merely to find a 
mutually-agreeable way to support the possibility of adding 
*utility-like* features (e.g. the ones suggested below) without bloating 
up a "hello world" ZF app.  I'm just trying to get the ball rolling, so 
if some of you have strong opinions, I encourage you to directly edit or 
comment on the proposal above.


There are many possible approaches (I'm vague on purpose, because I 
don't want to get stuck on any particular approach):

- multiple sub-directories
- single collective subdirectory
- packaging of the related utility functions into files, classes, or 
subclasses implementing extensions, "modules", or "packages", or 
"plugins" in some form or other for Zend.php


Personally, I'm not as concerned about the mechanism used to dynamically 
add "utility" functions to the "bootstrap", so long as there is 
something better than just dumping more functions into the Zend class in 
Zend.php.  I'm also more concerned about future additions than any 
"problems" posed by current functionality in Zend.php, although a 
cleanup/reorganization before ZF 1.0 would be nice.


Cheers,
Gavin

P.S.
> .. it's possible to have customized registries for different parts of 
large ... Passing it as an object ...


You read my mind .. I have high hopes that Zend_Registry will become 
more useful and used in future versions of the ZF, per your example ;)


Matthew Ratzloff wrote:

For what it's worth, it is ideal to retain the Zend.php instead of
splitting it up so the framework could build more utility functions into
it in future - that does not fit anywhere. How about renaming it to
Zend_Util, instead?



I can't imagine any utility methods that would be needed that could not be
put into a more full-fledged class.  Looking at the existing methods:

Zend::loadClass() => Zend_FileSystem::loadClass()

Zend_FileSystem could include recursive directory iterators, regular
expressions-based file manipulation, etc.

Zend::dump() => Zend_Debug::dump()

Zend_Debug could include a whole host of additional debugging information,
interaction with Zend_Log for trace messages, pseudo-breakpoints, etc.

And Zend_Registry already exists.  With a separate Zend_Registry class,
it's possible to have customized registries for different parts of large
applications--providing a scaled-down version of the registry for plug-in
developers, for instance.  Passing it as an object through the
controller's setParam() method also makes it easier to test, say,
individual actions.

In all cases, the framework benefits from individual, specialized components.

If we keep Zend.php (or whatever it would become), I think it'll be there
forever.  If it were removed at some point in the future, it would really
slow adoption of whatever version removed it.  People will have
Zend::register() or Zend::loadClass() calls throughout their applications
and be sluggish to invest the time in changing them.  It's like PHP
deciding to change array declaration to $array = [1, 2, 3] and deprecating
(and eventually removing) the array() construct.  They could never do it.

-Matt

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Shekar C Reddy]

Oops! I agree - the code in Zend.php could be split up into specialized
components and obsolete code could be eliminated. I just over-looked the
earlier discussions on this thread while posting my message.




On 2/27/07, Matthew Ratzloff <[EMAIL PROTECTED]> wrote:


> For what it's worth, it is ideal to retain the Zend.php instead of
> splitting it up so the framework could build more utility functions into
> it in future - that does not fit anywhere. How about renaming it to
> Zend_Util, instead?

I can't imagine any utility methods that would be needed that could not be
put into a more full-fledged class.  Looking at the existing methods:

Zend::loadClass() => Zend_FileSystem::loadClass()

Zend_FileSystem could include recursive directory iterators, regular
expressions-based file manipulation, etc.

Zend::dump() => Zend_Debug::dump()

Zend_Debug could include a whole host of additional debugging information,
interaction with Zend_Log for trace messages, pseudo-breakpoints, etc.

And Zend_Registry already exists.  With a separate Zend_Registry class,
it's possible to have customized registries for different parts of large
applications--providing a scaled-down version of the registry for plug-in
developers, for instance.  Passing it as an object through the
controller's setParam() method also makes it easier to test, say,
individual actions.

In all cases, the framework benefits from individual, specialized
components.

If we keep Zend.php (or whatever it would become), I think it'll be there
forever.  If it were removed at some point in the future, it would really
slow adoption of whatever version removed it.  People will have
Zend::register() or Zend::loadClass() calls throughout their applications
and be sluggish to invest the time in changing them.  It's like PHP
deciding to change array declaration to $array = [1, 2, 3] and deprecating
(and eventually removing) the array() construct.  They could never do it.

-Matt

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Matthew Ratzloff]

> For what it's worth, it is ideal to retain the Zend.php instead of
> splitting it up so the framework could build more utility functions into
> it in future - that does not fit anywhere. How about renaming it to
> Zend_Util, instead?

I can't imagine any utility methods that would be needed that could not be
put into a more full-fledged class.  Looking at the existing methods:

Zend::loadClass() => Zend_FileSystem::loadClass()

Zend_FileSystem could include recursive directory iterators, regular
expressions-based file manipulation, etc.

Zend::dump() => Zend_Debug::dump()

Zend_Debug could include a whole host of additional debugging information,
interaction with Zend_Log for trace messages, pseudo-breakpoints, etc.

And Zend_Registry already exists.  With a separate Zend_Registry class,
it's possible to have customized registries for different parts of large
applications--providing a scaled-down version of the registry for plug-in
developers, for instance.  Passing it as an object through the
controller's setParam() method also makes it easier to test, say,
individual actions.

In all cases, the framework benefits from individual, specialized components.

If we keep Zend.php (or whatever it would become), I think it'll be there
forever.  If it were removed at some point in the future, it would really
slow adoption of whatever version removed it.  People will have
Zend::register() or Zend::loadClass() calls throughout their applications
and be sluggish to invest the time in changing them.  It's like PHP
deciding to change array declaration to $array = [1, 2, 3] and deprecating
(and eventually removing) the array() construct.  They could never do it.

-Matt

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Shekar C Reddy]

Yes, this reduces the clutter in the Zend folder and improves
file-organization.

And Zend.php could be renamed to Core.php or Main.php and moved into Zend
folder with Zend_Core/Zend_Main class in it. Alternatively, Zend.php can be
safely moved into Zend folder (without any exceptions) and that file would
have Zend_Zend class :-)

For what it's worth, it is ideal to retain the Zend.php instead of splitting
it up so the framework could build more utility functions into it in future
- that does not fit anywhere. How about renaming it to Zend_Util, instead?

With ZF at 0.8, it's not too late to implement this. Newbies do not like
exceptions - however trivial they are.




On 2/27/07, Art Hundiak <[EMAIL PROTECTED]> wrote:



Really no need to tell if a given name represents a package or not.
Zend
..Filter
Filter.php contains Zend_Filter_Filter
Alpha.php contains Zend_Filter_Alpha

So the only change is the name of the top level class in a package.  The
autoload routine remains unchanged.

And of course if there was a module that was more or less independent from
the other filter modules (perhaps some code for a specific language) then
you could make is a subpackage.

It really does make sense and except for doubling up some of the top level
class names has no impact on the current design.



Stanislav Malyshev wrote:
>
>> The problem is that in Zend/ directory there are a lot of php files:
>
> Ok, there is. Why it is a problem though?
>
>> It would be much better to move them to:
>> Acl/Acl.php
>
> Ok, and Zend_Acl_Adapter would be in Acl/Adapter/Adapter.php or in
> Acl/Adapter.php? If the former - how it's not directory per file? If the
> latter, why Zend_Acl gets subdirectory and Zend_Acl_Adapter not and how
> one is to know that by the name?
>
>> So this means that all package files would be in package directory. If
u
>> need only one package u take the package directory.
>
> How do I know Zend_Foo_Bar_Baz is a package or part of Zend_Foo_Bar
> package or part of Zend_Foo package?
>
>> If file is in a directory - it is in package, and u know package
>> name[directory name]
>
> How do I know the directory name? You seem to have different rules for
> "packages" and "not packages" but I fail to see how do you know the name
> is package or not.
> --
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED]  http://www.zend.com/
>
>
>

--
View this message in context:
http://www.nabble.com/Request-for-feedback%3A-moving-Zend.php-to-Zend-Zend.php-tf3290016s16154.html#a9190465
Sent from the Zend Framework mailing list archive at Nabble.com.

[fw-general] Zend_DB and UTF-8

[mysticav]

Is there a straight way to set the Database Charset from the Zend_Db::factory
?
I need UTF-8. I'm using MySQL.

I don't want to modify the PDO/Abstract.php class by adding
$this->query('SET NAMES utf8'); in the _connect method.

I guess there's someting I missing regarding charsets. The Zend_DB
Documentation doesn't mention nothing about that.
-- 
View this message in context: 
http://www.nabble.com/Zend_DB-and-UTF-8-tf3304041s16154.html#a9190754
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Art Hundiak]

Really no need to tell if a given name represents a package or not.  
Zend
..Filter
Filter.php contains Zend_Filter_Filter
Alpha.php contains Zend_Filter_Alpha

So the only change is the name of the top level class in a package.  The
autoload routine remains unchanged.

And of course if there was a module that was more or less independent from
the other filter modules (perhaps some code for a specific language) then
you could make is a subpackage.  

It really does make sense and except for doubling up some of the top level
class names has no impact on the current design.



Stanislav Malyshev wrote:
> 
>> The problem is that in Zend/ directory there are a lot of php files:
> 
> Ok, there is. Why it is a problem though?
> 
>> It would be much better to move them to:
>> Acl/Acl.php
> 
> Ok, and Zend_Acl_Adapter would be in Acl/Adapter/Adapter.php or in 
> Acl/Adapter.php? If the former - how it's not directory per file? If the 
> latter, why Zend_Acl gets subdirectory and Zend_Acl_Adapter not and how 
> one is to know that by the name?
> 
>> So this means that all package files would be in package directory. If u 
>> need only one package u take the package directory.
> 
> How do I know Zend_Foo_Bar_Baz is a package or part of Zend_Foo_Bar 
> package or part of Zend_Foo package?
> 
>> If file is in a directory - it is in package, and u know package 
>> name[directory name]
> 
> How do I know the directory name? You seem to have different rules for 
> "packages" and "not packages" but I fail to see how do you know the name 
> is package or not.
> -- 
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED]  http://www.zend.com/
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Request-for-feedback%3A-moving-Zend.php-to-Zend-Zend.php-tf3290016s16154.html#a9190465
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Tautvydas Andrikys]

Nico Edtinger wrote:

[27.02.2007 19:04] Tautvydas Andrikys wrote:
So this means that all package files would be in package directory. 
If u need only one package u take the package directory.


Won't work. The unit that you call packages are not (always) 
independent  and just because some files are in one directory doesn't 
make it a package. There's only one real package: Zend Framework.
It could work if all dependent packages would be listed in package 
description.
Well as much as i see from api Zend Framework is a collection of 
packages just file organization is a bit strange to me.


ok, lets end this discussion, couse as much i see it is already dead for 
Zend Framework:)


nico




--
Pagarbiai,
Tautvydas Andrikys aka esminis 
www.esminis.lt 
www.bajeriai.lt 

Re: [fw-general] Zend_Locale

[Gavin Vess]

Hi Ian,

I added examples and docs for this to the Subversion copy of the manual 
to synchronize with the latest code in SVN.


Unfortunately, we are not yet done with some changes to the manual, and 
the wiki version of the core manual is currently offline.


I generated a static HTML set, and the examples below "15.2.6. Obtaining 
localized strings" highlight the new usage:

http://gavin.zfdev.com/zftrunk/documentation/manual/en/html/zend.locale.functions.html

Cheers,
Gavin

Ian Warner wrote:

In your example I get an error:

require_once 'Zend/Locale.php';
$locale = new Zend_Locale('de');

$country = $locale->getList('country');
$territory = $locale->getList('territory'); $connection =
$locale->getList('territory_detail');

print_r($country);
print_r($territory);
print_r($connection);


Fatal error: Call to undefined method Zend_Locale::getList() in
C:\AWebEnvironment\htdocs\HoTxt\index.php on line 13

I have version .8 Is this a new feature on SVN?

Can you point that out in examples that it is available in version ###

I will update now and see if it is there.

Cheers

Ian

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Stanislav Malyshev]

The problem is that in Zend/ directory there are a lot of php files:


Ok, there is. Why it is a problem though?


It would be much better to move them to:
Acl/Acl.php


Ok, and Zend_Acl_Adapter would be in Acl/Adapter/Adapter.php or in 
Acl/Adapter.php? If the former - how it's not directory per file? If the 
latter, why Zend_Acl gets subdirectory and Zend_Acl_Adapter not and how 
one is to know that by the name?


So this means that all package files would be in package directory. If u 
need only one package u take the package directory.


How do I know Zend_Foo_Bar_Baz is a package or part of Zend_Foo_Bar 
package or part of Zend_Foo package?


If file is in a directory - it is in package, and u know package 
name[directory name]


How do I know the directory name? You seem to have different rules for 
"packages" and "not packages" but I fail to see how do you know the name 
is package or not.

--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Nico Edtinger]

[27.02.2007 19:04] Tautvydas Andrikys wrote:
So this means that all package files would be in package directory.  
If u need only one package u take the package directory.


Won't work. The unit that you call packages are not (always)  
independent  and just because some files are in one directory doesn't  
make it a package. There's only one real package: Zend Framework.


nico

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Ralph Schindler]

Tautvydas Andrikys wrote:



If Alpha would be in differenet package it would be moved to that 
package directory


How I know by its name if it's a package or not?

If file is in a directory - it is in package, and u know package 
name[directory name]





I don't becoming a PEAR-like repository of code or packagages is a goal 
of the ZF.  The ultimate goal is provide a cohesive framework that is 
intended to be distributed as a whole.  This ensures that at any given 
iteration or distribution, developers can be aware that all classes in a 
given distribution DO work together if that is desired.


That being said, the current naming of these classes, files and 
directories represents the best practices approach to fulfilling ZF 
goals; more specifcally, we have a simple and programtic way to derive 
file locations from class names.


-ralph

[fw-general] catching xml document errors with Zend_Rest_Client_Result

[Michael Depetrillo]

Hello

Our business works works with numerous third-party soap services.  Sometimes
these companies screw up and return an improperly formated XML document.
Using Zend_Rest_Client a PHP warning will occur followed by a fatal error.

I was wondering how I might be able to catch these types of errors so they
could be properly dealt with.

Here is an example error message that occurs when improperly formated XML is
returned.

Warning: simplexml_load_string(): Entity: line 1: parser error : Start tag
expected, '<' not found in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 44
Warning: simplexml_load_string(): System.InvalidOperationException: There
was an error generating the XML document in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 44
Warning: simplexml_load_string(): ^ in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 44
Fatal error: Call to a member function xpath() on a non-object in
C:\Users\mike\workspace\domain.com\library\Zend\library\Zend\Rest\Client\Result.php
on line 71

--
Michael DePetrillo
[EMAIL PROTECTED]
Home:  (858) 926-5761
Mobile: (858) 761-1605
AIM: klassicd

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Tautvydas Andrikys]

Stanislav Malyshev wrote:

why we need to repeat Zend_Filter twice?
Zend_Filter would not be repeated twice. Zend/Zend_Filter.php would 
be moved to Zend/Filter/Zend_Filter.php


I clearly see Zend and Filter repeated twice right in front of me. Do 
you?

oh u mean file name repeat :) i dont think this is a great problem.
And the filename would be: Zend/Filter/Filter.php[my mistake in prev. 
letters]


Every package would be strictly separated. Now all packages are mixed 
up in Zend directory. And this solution is time tested in Java, where 
each 


I don't really udnerstand what do you mean by "mixed up". They reside 
in Zend directory, because that's where framework is. It's intended to 
be so, what's the problem in it?

The problem is that in Zend/ directory there are a lot of php files:
Acl.php
Cache.php
Config.php
Date.php
Db.php
Exception.php
Feed.php
Filter.php
Gdata.php
Json.php
Locale.php
Log.php
Mail.php
Measure.php
Mime.php
Pdf.php
Registry.php
Session.php
Uri.php
View.php

It would be much better to move them to:
Acl/Acl.php
Cache/Cache.php
Config/Config.php
Date/Date.php
Db/Db.php
Exception/Exception.php
Feed/Feed.php
Filter/Filter.php
Gdata/Gdata.php
Json/Json.php
Locale/Locale.php
Log/Log.php
Mail/Mail.php
Measure/Measure.php
Mime/Mime.php
Pdf/Pdf.php
Registry/Registry.php
Session/Session.php
Uri/Uri.php
View/View.php

So this means that all package files would be in package directory. If u 
need only one package u take the package directory.


If Alpha would be in differenet package it would be moved to that 
package directory


How I know by its name if it's a package or not?

If file is in a directory - it is in package, and u know package 
name[directory name]


--
Pagarbiai,
Tautvydas Andrikys aka esminis 
www.esminis.lt 
www.bajeriai.lt 

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Tautvydas Andrikys]

Ya, sorry, my mistake[too much use of __autoload :)]

Shekar C Reddy wrote:

Hi Tautvydas,
 
You are confusing Stanislav with the mis-typed file-names:
 
Zend/Filter.php => Zend/Filter/Filter.php [not: Zend_Filter.php, 
Zend_Filter is the name of the class]

Zend/Filter/Filter/Alnum.php [no change, couse it is same package]
Zend/Filter/Filter/Alpha.php [no change, couse it is same package]
Zend/Filter/Filter/Digits.php [no change, couse it is same package]

 

 
On 2/27/07, *Tautvydas Andrikys* <[EMAIL PROTECTED] 
> wrote:


Stanislav Malyshev wrote:
>> Now every package has its own directory and one file in parent
>> directory, so i offer to move all files to package directory:
>> Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
>> Zend/Filter/Zend_Filter_Alnum.php [no change, couse it is same
package]
>> Zend/Filter/Zend_Filter_Alpha.php [no change, couse it is same
package]
>> Zend/Filter/Zend_Filter_Digits.php [no change, couse it is same
package]
>
> why we need to repeat Zend_Filter twice?
Zend_Filter would not be repeated twice. Zend/Zend_Filter.php would be
moved to Zend/Filter/Zend_Filter.php

> What good would it make?
Every package would be strictly separated. Now all packages are
mixed up
in Zend directory. And this solution is time tested in Java, where
each
package is in its own directory. This is solution to svn:externals
too.

> And how we know Zend and Filter get its own directory but Alpha
does not?
If Alpha would be in differenet package it would be moved to that
package directory

And yes it would require quite some work to refactor to this
structure... so i dont think this will be implemented in ZF:(

Tautvydas Andrikys aka esminis





--
Pagarbiai,
Tautvydas Andrikys aka esminis 
www.esminis.lt 
www.bajeriai.lt 

Re: [fw-general] JSON encoding problem

[Dmitry Shirokov]

On 27/02/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:


-- Dmitry Shirokov <[EMAIL PROTECTED]> wrote
(on Tuesday, 27 February 2007, 04:11 PM +):
> hello guys, i had weird problem with code like that (zf 0.7.0):
>
> foreach ($this->_subSites->fetchAll() as $subSite)
> {
>  $resRow = new StdClass;
>
>  $resRow->id = $subSite->id;
>
>  $resRow->subDomain  = $subSite->subDomain;
>
>  $resRow->image  = $subSite->image;
>
>  $res[] = $resRow;
>
> }
>
> echo Zend_Json::encode($res);
>
> on my home machine with php 5.2.0 return:
>
> [{"id":"19","subDomain":"one","image":"\/images\/sub\/image1.jpg"},
> {"id":"13","subDomain":"test","image":"\/images\/sub\/ee.jpg"},
> {"id":"1","subDomain":"two","image":"\/images\/sub\/test.jpg"}]
>
> on the server with php 5.1.4:
>
[{"__className":"stdClass","id":"19","subDomain":"one","image":"/images/sub/
> image1.jpg
"},{"__className":"stdClass","id":"13","subDomain":"test","image":"/
> images/sub/ee.jpg"},
>
{"__className":"stdClass","id":"1","subDomain":"two","image":"/images/sub/
> test.jpg"}]
>
> not same...
>
>
> any ideas?

When encoding objects with Zend_Json, it adds an extra key at the
beginning indicating the class name; this is done to hint to the JS
consumer a JS class to instantiate (should that be desired).

Now, that said, with ZF release 0.7.0, a change was made to use ext/json
if detected. ext/json basically simply casts objects to arrays prior to
encoding them -- which is why the two versions are different.

If you want the to function the same for your example, do one of the
following:

* cast objects to arrays prior to encoding:
  Zend_Json::encode((array) $res);

* or use Zend_Json's encoder explicitly:
  Zend_Json_Encoder::encode($res);

(this latter is true of the decoder, too)

--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/



Thanks man.

--
Thanks, Dmitry

Re: [fw-general] ROR Flash in ZF

[Philip Iezzi]

I'd like to pick up this topic again.
Even though I didn't really understand the PHP problem that still persists in 
PHP 5.2.1(*), I found my own workaround.

(*) Notice: Indirect modification of overloaded property 
Zend_Session_Namespace::$default has no effect in Ralph_FlashMessage.php on 
line 89

Here's my diff to Ralph's 
http://svn.ralphschindler.com/repo/ZendFramework/library/FlashMessage.php:

-
# diff Ralph_FlashMessage.php FlashMessage.php
51c51
< self::$_session = new Zend_Session(__CLASS__);
---
> self::$_session = new Zend_Session_Namespace(__CLASS__);
84c84,86
< self::$_session->{$namespace} = array();
---
> $messages = array();
> } else {
> $messages = self::$_session->{$namespace};
85a88
> $messages[] = $message;
87c90
< self::$_session->{$namespace}[] = $message;
---
> self::$_session->{$namespace} = $messages;
-

Tested on PHP 5.2.1 & latest ZF svn revision.
It may be an ugly workaround to use a local temp variable $messages inside the 
addMessage method, but like this it works wonderful. Let me know if I'm missing 
something here in this rather complex implementation of a simple thing.

Cheers,
Philip


Ralph Schindler wrote:
> Right, the Zend_Session API has changed very significantly yesterday,
> and we are in the stages of finializing the would be ZF 1.0 Zend_Session
> api.  I will update FlashMessage to work with whats currently in svn,
> but do know that it could change only slightly more since we are in the
> finializing stages.. and there is one decision to make and is open to
> the community for comments.
> 
> -ralph
> 
> Christian Wittwer wrote:
>>> http://svn.ralphschindler.com/repo/ZendFramework/library/
>>>
>>> It currently uses Zend_Session, also implementing countable,
>>> iteratable interface.  I use it to add messages in my controllers,
>>> and also to retrieve messages in my view scripts.
>>>
>>> FlashMessage::add($message);
>>>
>>> if (FlashMessage::hasMessages()) {
>>> $messages = FlashMessage::getMessages();
>>> foreach ($messages as $message) { echo $message; }
>>> }
>>>
>>> It also supports namespacing so that multiple components can use
>>> FlashMessage and keep their messages separated, this is good if you
>>> know certain (named) messages will have to be directed to a specific
>>> part of the view.
>>
>> Hi Ralph,
>> Your FlashMessage Class don't work with the latest svn revision (3290).
>>
>> Fatal error: Call to private Zend_Session::__construct() from context
>> 'FlashMessage'
>>
>> Chris
>>
>>
> 

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Stanislav Malyshev]

why we need to repeat Zend_Filter twice?
Zend_Filter would not be repeated twice. Zend/Zend_Filter.php would be 
moved to Zend/Filter/Zend_Filter.php


I clearly see Zend and Filter repeated twice right in front of me. Do you?

Every package would be strictly separated. Now all packages are mixed up 
in Zend directory. And this solution is time tested in Java, where each 


I don't really udnerstand what do you mean by "mixed up". They reside in 
Zend directory, because that's where framework is. It's intended to be 
so, what's the problem in it?


If Alpha would be in differenet package it would be moved to that 
package directory


How I know by its name if it's a package or not?

--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/

Re: [fw-general] Forward method

['Matthew Weier O'Phinney']

-- Ian Warner <[EMAIL PROTECTED]> wrote
(on Tuesday, 27 February 2007, 04:35 PM -):
> Worked fine thank you very much

Just for the historical record (for those who may search for this), what
worked for you -- using the response object, or updating how you called
_forward()?

> > > I am trying to make sense of the Forward command.
> > >
> > > I am utilizing QuickForm in a join form
> > >
> > > The user fills in the form if it validates I want to forward to a
> > validate
> > > Action - just for separation.
> > >
> > > // Try to validate a form
> > > if ($form->validate()) {
> > >
> > >   // Email and store in DB
> > > // Forward to the Verification controller
> > > self::_forward('validate');
> > 
> > First, Zend_Controller_Action::_forward() is not a static method.
> > Second, make sure you understand its signature:
> > 
> > protected function _forward($action, $controller = null, $module =
> > null, array $params = array());
> > 
> > It works like this:
> > 
> > * If only an $action is provided, it forwards to that action in the
> >   current controller and module
> > * If an $action and a $controller are provided, it forwards to that
> >   action and controller in the current module
> > * If an $action, $controller, and $module are provided, it forwards
> >   to that action and controller in the provided module.
> > * $params may be provided at any time (pass null to any unneeded
> >   parameter), and will be used to set parameters in the request
> >   object.
> > 
> > >
> > > } else {
> > > $string = $form->toHtml();
> > > }
> > >
> > > Now in my validate action I want to forward again to the second stage of
> > the
> > > form
> > >
> > > // Show second stage
> > > public function validateAction()
> > > {
> > > //$post = Zend::registry('post');
> > > //echo ''; print_r($post); echo '';
> > > //echo ''; print_r($_POST); echo '';
> > >
> > > // Forward to the Verification controller
> > > self::_forward('index', 'verification');
> > > }
> > >
> > > Which involves verification
> > >
> > > However when I get here I have the output of all the previous pages.
> > >
> > > So my question is
> > >
> > > 1. How do I stop output from the action the script forwarded from. Is
> > this
> > > something to do with the Dispatch stuff - can I clear this before I
> > forward
> > > maybe?
> > 
> > Use the response object's setBody() and appendBody() methods for
> > displaying content. So, instead of:
> > 
> > echo '', print_r($post, 1, '';
> > 
> > You'd use:
> > 
> > $this->_response->appendBody('' . print_r($post, 1) . '');
> > 
> > // or
> > $this->getResponse()->appendBody('' . print_r($post, 1) .
> > '');
> > 
> > Then, if you want a particular action to always overwrite any previous
> > content, use setBody():
> > 
> > $this->_response->setBody('Thanks for verifying your identity');
> > 
> > You could also do this just before your call to _forward():
> > 
> > $this->_response->setBody('');
> > $this->_forward('index', 'verification');
> > 
> > > 2. What performance penalty do I suffer for letting the script compile
> > and
> > > then I clean?
> > 
> > Not much -- it's all being handled as PHP arrays; you're simply
> > unsetting previous values.
> > 
> > --
> > Matthew Weier O'Phinney
> > PHP Developer| [EMAIL PROTECTED]
> > Zend - The PHP Company   | http://www.zend.com/
> 

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] JSON encoding problem

[Matthew Weier O'Phinney]

-- Dmitry Shirokov <[EMAIL PROTECTED]> wrote
(on Tuesday, 27 February 2007, 04:11 PM +):
> hello guys, i had weird problem with code like that (zf 0.7.0):
> 
> foreach ($this->_subSites->fetchAll() as $subSite)
> { 
>  $resRow = new StdClass;
>   
>  $resRow->id = $subSite->id;
>   
>  $resRow->subDomain  = $subSite->subDomain;
>
>  $resRow->image  = $subSite->image;
>
>  $res[] = $resRow;
>   
>   
> }
>   
>   
> echo Zend_Json::encode($res);
> 
> on my home machine with php 5.2.0 return:
> 
> [{"id":"19","subDomain":"one","image":"\/images\/sub\/image1.jpg"},
> {"id":"13","subDomain":"test","image":"\/images\/sub\/ee.jpg"},
> {"id":"1","subDomain":"two","image":"\/images\/sub\/test.jpg"}]
> 
> on the server with php 5.1.4:
> [{"__className":"stdClass","id":"19","subDomain":"one","image":"/images/sub/
> image1.jpg"},{"__className":"stdClass","id":"13","subDomain":"test","image":"/
> images/sub/ee.jpg"},
> {"__className":"stdClass","id":"1","subDomain":"two","image":"/images/sub/
> test.jpg"}]
> 
> not same...
> 
> 
> any ideas?

When encoding objects with Zend_Json, it adds an extra key at the
beginning indicating the class name; this is done to hint to the JS
consumer a JS class to instantiate (should that be desired).

Now, that said, with ZF release 0.7.0, a change was made to use ext/json
if detected. ext/json basically simply casts objects to arrays prior to
encoding them -- which is why the two versions are different.

If you want the to function the same for your example, do one of the
following:

* cast objects to arrays prior to encoding:
  Zend_Json::encode((array) $res);

* or use Zend_Json's encoder explicitly:
  Zend_Json_Encoder::encode($res);

(this latter is true of the decoder, too)

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

RE: [fw-general] Forward method

[Ian Warner]

Matt

Worked fine thank you very much

Ian

> > I am trying to make sense of the Forward command.
> >
> > I am utilizing QuickForm in a join form
> >
> > The user fills in the form if it validates I want to forward to a
> validate
> > Action - just for separation.
> >
> > // Try to validate a form
> > if ($form->validate()) {
> >
> > // Email and store in DB
> > // Forward to the Verification controller
> > self::_forward('validate');
> 
> First, Zend_Controller_Action::_forward() is not a static method.
> Second, make sure you understand its signature:
> 
> protected function _forward($action, $controller = null, $module =
> null, array $params = array());
> 
> It works like this:
> 
> * If only an $action is provided, it forwards to that action in the
>   current controller and module
> * If an $action and a $controller are provided, it forwards to that
>   action and controller in the current module
> * If an $action, $controller, and $module are provided, it forwards
>   to that action and controller in the provided module.
> * $params may be provided at any time (pass null to any unneeded
>   parameter), and will be used to set parameters in the request
>   object.
> 
> >
> > } else {
> > $string = $form->toHtml();
> > }
> >
> > Now in my validate action I want to forward again to the second stage of
> the
> > form
> >
> > // Show second stage
> > public function validateAction()
> > {
> > //$post = Zend::registry('post');
> > //echo ''; print_r($post); echo '';
> > //echo ''; print_r($_POST); echo '';
> >
> > // Forward to the Verification controller
> > self::_forward('index', 'verification');
> > }
> >
> > Which involves verification
> >
> > However when I get here I have the output of all the previous pages.
> >
> > So my question is
> >
> > 1. How do I stop output from the action the script forwarded from. Is
> this
> > something to do with the Dispatch stuff - can I clear this before I
> forward
> > maybe?
> 
> Use the response object's setBody() and appendBody() methods for
> displaying content. So, instead of:
> 
> echo '', print_r($post, 1, '';
> 
> You'd use:
> 
> $this->_response->appendBody('' . print_r($post, 1) . '');
> 
> // or
> $this->getResponse()->appendBody('' . print_r($post, 1) .
> '');
> 
> Then, if you want a particular action to always overwrite any previous
> content, use setBody():
> 
> $this->_response->setBody('Thanks for verifying your identity');
> 
> You could also do this just before your call to _forward():
> 
> $this->_response->setBody('');
> $this->_forward('index', 'verification');
> 
> > 2. What performance penalty do I suffer for letting the script compile
> and
> > then I clean?
> 
> Not much -- it's all being handled as PHP arrays; you're simply
> unsetting previous values.
> 
> --
> Matthew Weier O'Phinney
> PHP Developer| [EMAIL PROTECTED]
> Zend - The PHP Company   | http://www.zend.com/

[fw-general] JSON encoding problem

[Dmitry Shirokov]

hello guys, i had weird problem with code like that (zf 0.7.0):

foreach ($this->_subSites->fetchAll() as $subSite)
{
$resRow = new
StdClass;

$resRow->id =
$subSite->id;
$resRow->subDomain  =
$subSite->subDomain;
$resRow->image  =
$subSite->image;
$res[] =
$resRow;

}

echo Zend_Json::encode($res);

on my home machine with php 5.2.0 return:

[{"id":"19","subDomain":"one","image":"\/images\/sub\/image1.jpg"},{"id":"13","subDomain":"test","image":"\/images\/sub\/ee.jpg"},{"id":"1","subDomain":"two","image":"\/images\/sub\/test.jpg"}]

on the server with php 5.1.4:
[{"__className":"stdClass","id":"19","subDomain":"one","image":"/images/sub/image1.jpg"},{"__className":"stdClass","id":"13","subDomain":"test","image":"/images/sub/ee.jpg"},{"__className":"stdClass","id":"1","subDomain":"two","image":"/images/sub/test.jpg"}]

not same...


any ideas?

--
Thanks, Dmitry

Re: [fw-general] Forward method

[Matthew Weier O'Phinney]

-- Ian Warner <[EMAIL PROTECTED]> wrote
(on Tuesday, 27 February 2007, 11:30 AM -):
> I am trying to make sense of the Forward command.
> 
> I am utilizing QuickForm in a join form
> 
> The user fills in the form if it validates I want to forward to a validate
> Action - just for separation.
> 
> // Try to validate a form 
> if ($form->validate()) {
> 
>   // Email and store in DB
> // Forward to the Verification controller
> self::_forward('validate');

First, Zend_Controller_Action::_forward() is not a static method.
Second, make sure you understand its signature:

protected function _forward($action, $controller = null, $module = null, 
array $params = array());

It works like this:

* If only an $action is provided, it forwards to that action in the
  current controller and module
* If an $action and a $controller are provided, it forwards to that
  action and controller in the current module
* If an $action, $controller, and $module are provided, it forwards
  to that action and controller in the provided module.
* $params may be provided at any time (pass null to any unneeded
  parameter), and will be used to set parameters in the request
  object.

> 
> } else {
> $string = $form->toHtml();
> }
> 
> Now in my validate action I want to forward again to the second stage of the
> form
> 
> // Show second stage
> public function validateAction()
> {
> //$post = Zend::registry('post');
> //echo ''; print_r($post); echo '';
> //echo ''; print_r($_POST); echo '';
> 
> // Forward to the Verification controller
> self::_forward('index', 'verification');
> }
> 
> Which involves verification
> 
> However when I get here I have the output of all the previous pages.
> 
> So my question is
> 
> 1. How do I stop output from the action the script forwarded from. Is this
> something to do with the Dispatch stuff - can I clear this before I forward
> maybe?

Use the response object's setBody() and appendBody() methods for
displaying content. So, instead of:

echo '', print_r($post, 1, '';

You'd use:

$this->_response->appendBody('' . print_r($post, 1) . '');

// or 
$this->getResponse()->appendBody('' . print_r($post, 1) . '');

Then, if you want a particular action to always overwrite any previous
content, use setBody():

$this->_response->setBody('Thanks for verifying your identity');

You could also do this just before your call to _forward():

$this->_response->setBody('');
$this->_forward('index', 'verification');

> 2. What performance penalty do I suffer for letting the script compile and
> then I clean?

Not much -- it's all being handled as PHP arrays; you're simply
unsetting previous values.

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Shekar C Reddy]

Hi Tautvydas,

You are confusing Stanislav with the mis-typed file-names:

Zend/Filter.php => Zend/Filter/Filter.php [not: Zend_Filter.php, Zend_Filter
is the name of the class]
Zend/Filter/Filter/Alnum.php [no change, couse it is same package]
Zend/Filter/Filter/Alpha.php [no change, couse it is same package]
Zend/Filter/Filter/Digits.php [no change, couse it is same package]




On 2/27/07, Tautvydas Andrikys <[EMAIL PROTECTED]> wrote:


Stanislav Malyshev wrote:
>> Now every package has its own directory and one file in parent
>> directory, so i offer to move all files to package directory:
>> Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
>> Zend/Filter/Zend_Filter_Alnum.php [no change, couse it is same package]
>> Zend/Filter/Zend_Filter_Alpha.php [no change, couse it is same package]
>> Zend/Filter/Zend_Filter_Digits.php [no change, couse it is same
package]
>
> why we need to repeat Zend_Filter twice?
Zend_Filter would not be repeated twice. Zend/Zend_Filter.php would be
moved to Zend/Filter/Zend_Filter.php

> What good would it make?
Every package would be strictly separated. Now all packages are mixed up
in Zend directory. And this solution is time tested in Java, where each
package is in its own directory. This is solution to svn:externals too.

> And how we know Zend and Filter get its own directory but Alpha does
not?
If Alpha would be in differenet package it would be moved to that
package directory

And yes it would require quite some work to refactor to this
structure... so i dont think this will be implemented in ZF:(

Tautvydas Andrikys aka esminis

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Lee Saferite]

Perhaps moving Zend.php to Zend/Core.php as-is AND making new classes to
replace it is the better solution.

We can make the move from Zend to Zend_Core and people can easily do a
global search-replace to handle it.

Once Zend_Core is in the framework, you can basically turn each of it's
functions into a wrapper for the 'real' function.
For example, Zend::dump() could just point at Zend_Debug::dump()
We could mark the entire Zend_Core class deprecated and remove it on
the 1.0release.

I personally would prefer it if the entire framework was contained in the
/Zend directory.  It's a cleaner layout.  Besides, Zend::dump() is a great
little function, but it absolutely does not need to be a 'core' function
that is loaded on every request.

My 2 cents.

Lee

On 2/27/07, Tautvydas Andrikys <[EMAIL PROTECTED]> wrote:


Stanislav Malyshev wrote:
>> Now every package has its own directory and one file in parent
>> directory, so i offer to move all files to package directory:
>> Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
>> Zend/Filter/Zend_Filter_Alnum.php [no change, couse it is same package]
>> Zend/Filter/Zend_Filter_Alpha.php [no change, couse it is same package]
>> Zend/Filter/Zend_Filter_Digits.php [no change, couse it is same
package]
>
> why we need to repeat Zend_Filter twice?
Zend_Filter would not be repeated twice. Zend/Zend_Filter.php would be
moved to Zend/Filter/Zend_Filter.php

> What good would it make?
Every package would be strictly separated. Now all packages are mixed up
in Zend directory. And this solution is time tested in Java, where each
package is in its own directory. This is solution to svn:externals too.

> And how we know Zend and Filter get its own directory but Alpha does
not?
If Alpha would be in differenet package it would be moved to that
package directory

And yes it would require quite some work to refactor to this
structure... so i dont think this will be implemented in ZF:(

Tautvydas Andrikys aka esminis

Re: [fw-general] Zend_Locale

[Thomas Weidner]

In your example I get an error:
Fatal error: Call to undefined method Zend_Locale::getList() in
C:\AWebEnvironment\htdocs\HoTxt\index.php on line 13



I have version .8 Is this a new feature on SVN?


Normally it should be clear that when I am writing "since 24.2" and 0.8 was 
released on 22.2 that this functionallity is not avaiable within 0.8. See my 
mail from 26.2.


Greetings
Thomas
I18N Team Leader 

RE: [fw-general] Zend DB Table

[Ian Warner]

> -Original Message-
> From: Ian Warner [mailto:[EMAIL PROTECTED]
> Sent: 27 February 2007 12:57
> To: fw-general@lists.zend.com
> Subject: [fw-general] Zend DB Table
> 
> Hi
> 
> I wish to use this functionality, I assume this is similar to the
> Data_Objects that PEAR provides
> 
> However where do I place the newly created classes that extend:
> 
> class RoundTable extends Zend_Db_Table {}
> 
> Is there any way to override this location.

Ok I did it this way: $table = new Dataobjects_Config_User() - placed the
class in the directory structure - library/Dataobjects/Config/User.php

Within this file added:

class Dataobjects_Config_User extends Zend_Db_Table
{
protected function _setup()
{
$this->_name= 'user';
$this->_primary = 'User';
parent::_setup();
}
}

So this works.

However I am getting the following issue:

Zend_Db_Table::setDefaultAdapter($db);
$table = new Dataobjects_Config_User();
$rowset = $table->fetchAll();
 
// display them all
foreach ($rowset as $row) {

// $row is a Zend_Db_Table_Row object
echo '-->' . htmlspecialchars($row->Host) . '';
}

This comes up with Fatal error: Uncaught exception
'Zend_Db_Table_Row_Exception' with message 'column 'Host' not in row' in

Using - $row->host I get - Notice: Undefined index: Host in
C:\AWebEnvironment\htdocs\ZendFramework-0.8.0\library\Zend\Db\Table\Row.php
on line 95

[_data:protected] => Array
(
[host] => localhost
[user] => root
[password] => 
[select_priv] => Y
[insert_priv] => Y
[update_priv] => Y
[delete_priv] => Y
[create_priv] => Y
[drop_priv] => Y
[reload_priv] => Y
[shutdown_priv] => Y
[process_priv] => Y
[file_priv] => Y
[grant_priv] => Y
[references_priv] => Y
[index_priv] => Y
[alter_priv] => Y
[show_db_priv] => Y
[super_priv] => Y
[create_tmp_table_priv] => Y
[lock_tables_priv] => Y
[execute_priv] => Y
[repl_slave_priv] => Y
[repl_client_priv] => Y
[create_view_priv] => Y
[show_view_priv] => Y
[create_routine_priv] => Y
[alter_routine_priv] => Y
[create_user_priv] => Y
[ssl_type] => 
[ssl_cipher] => 
[x509_issuer] => 
[x509_subject] => 
[max_questions] => 0
[max_updates] => 0
[max_connections] => 0
[max_user_connections] => 0
)

There is data in this table for the host field.

Hope that's enough info 

Cheers

Ian


> 
> Lastly is there a simple way to change the DB within the set connection or
> do I need to create a new factory call?
> 
> Cheers
> 
> Ian

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Tautvydas Andrikys]

U misunderstood me. Not every class gets its own directory, but every 
package gets its own directory.


Now every package has its own directory and one file in parent 
directory, so i offer to move all files to package directory:

Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
Zend/Filter/Zend_Filter_Alnum.php [no change, couse it is same package]
Zend/Filter/Zend_Filter_Alpha.php [no change, couse it is same package]
Zend/Filter/Zend_Filter_Digits.php [no change, couse it is same package]
...

Stanislav Malyshev wrote:

So:
Zend/Db.php => Zend/Db/Db.php,
Zend/Db/Table.php => Zend/Db/Table/Table.php


So each class gets its own directory or what? Doesn't make much sense to 
me. Do I miss something?





--
Pagarbiai,
Tautvydas Andrikys

UAB "M2 technologijos"
Laisvës pr. 77B, Vilnius
Tel. +370 5 2462284
Faks. +370 5 2462285
Mob.: +370 671 52246
www.m2.lt 
begin:vcard
fn:Tautvydas Andrikys
n:Andrikys;Tautvydas
org:M2 Technologijos;Programming
adr;quoted-printable:;;Laisv=C4=97s pr. 77B;Vilnius;;;Lithuania
email;internet:[EMAIL PROTECTED]
title:Programmer
tel;work:00 370 5 2462284
tel;fax:00 370 5 2462285
tel;cell:00 370 671 52246
x-mozilla-html:FALSE
url:http://www.m2.lt
version:2.1
end:vcard

[fw-general] Zend DB Table

[Ian Warner]

Hi

I wish to use this functionality, I assume this is similar to the
Data_Objects that PEAR provides

However where do I place the newly created classes that extend:

class RoundTable extends Zend_Db_Table {}

Is there any way to override this location.

Lastly is there a simple way to change the DB within the set connection or
do I need to create a new factory call?

Cheers

Ian

[fw-general] Forward method

[Ian Warner]

I am trying to make sense of the Forward command.

I am utilizing QuickForm in a join form

The user fills in the form if it validates I want to forward to a validate
Action - just for separation.

// Try to validate a form 
if ($form->validate()) {

// Email and store in DB
// Forward to the Verification controller
self::_forward('validate');

} else {
$string = $form->toHtml();
}

Now in my validate action I want to forward again to the second stage of the
form

// Show second stage
public function validateAction()
{
//$post = Zend::registry('post');
//echo ''; print_r($post); echo '';
//echo ''; print_r($_POST); echo '';

// Forward to the Verification controller
self::_forward('index', 'verification');
}

Which involves verification

However when I get here I have the output of all the previous pages.

So my question is

1. How do I stop output from the action the script forwarded from. Is this
something to do with the Dispatch stuff - can I clear this before I forward
maybe?

2. What performance penalty do I suffer for letting the script compile and
then I clean?

3. Any other tips on how to utilize this sort of thing appreciated

Cheers

Ian

Re: [fw-general] rewrite router problem

[Blue Paprica]

Simon Mundy wrote:
> 
> Is your class named 'Admin_TestController' in your TestController.php  
> file?
> 
> 
> 
No. I knew i'm missing something silly. Thanks. Now it works
Regards
Maciej

-- 
View this message in context: 
http://www.nabble.com/rewrite-router-problem-tf3299925s16154.html#a9179801
Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] rewrite router problem

[Simon Mundy]

Is your class named 'Admin_TestController' in your TestController.php  
file?


at apl/controllers/asmin/ i have IndexController, TestController  
but still

it doesn't work

Regard
Maciej


--

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

[fw-general] rewrite router problem

[Blue Paprica]

Hi 
I wnat to set up 2 controller, defalut and admin, i found here this: 
http://www.nabble.com/RewriteRouter-gone...-tf3225893s16154.html post 
I tried to do it same way:
$controller = Zend_Controller_Front::getInstance();

$controller->throwExceptions(true);

$controller->setControllerDirectory(array(
'default' => ROOT . '/apl/controllers/',
'admin'   => ROOT . '/apl/controllers/admin/'
)); 
but when i call  http://localhost/site/www/admin/test/
i get 
Fatal error: Uncaught exception 'Zend_Exception' with message 'File
"Admin\TestController.php" was not found.' in
G:\wamp2\www\pl_flash\lib\Zend.php:175 
Stack trace: 
 #0 G:\wamp2\www\pl_flash\lib\Zend.php(103):
Zend::loadFile('TestController', Array, true) 
#1 G:\wamp2\www\pl_flash\www\index.php(63):
Zend::loadClass('Admin_TestContr...') 
#2 [internal function]: __autoload('Admin_TestContr...') #3 
My dir structure looks like this:
/apl/
/controllers/
 /admin/
   /views/
  /models/
...
/www/
   /admin/
  
at apl/controllers/asmin/ i have IndexController, TestController but still
it doesn't work

Regard
Maciej


-- 
View this message in context: 
http://www.nabble.com/rewrite-router-problem-tf3299925s16154.html#a9179513
Sent from the Zend Framework mailing list archive at Nabble.com.

RE: [fw-general] Zend_Locale

[Ian Warner]

In your example I get an error:

require_once 'Zend/Locale.php';
$locale = new Zend_Locale('de');

$country = $locale->getList('country');
$territory = $locale->getList('territory'); $connection =
$locale->getList('territory_detail');

print_r($country);
print_r($territory);
print_r($connection);


Fatal error: Call to undefined method Zend_Locale::getList() in
C:\AWebEnvironment\htdocs\HoTxt\index.php on line 13

I have version .8 Is this a new feature on SVN?

Can you point that out in examples that it is available in version ###

I will update now and see if it is there.

Cheers

Ian

> -Original Message-
> From: Thomas Weidner [mailto:[EMAIL PROTECTED]
> Sent: 26 February 2007 22:10
> To: [EMAIL PROTECTED]
> Cc: Ian Warner; fw-general@lists.zend.com
> Subject: Re: [fw-general] Zend_Locale
> 
> >However, I still think that there should be a way to separate continents
> >from regions(which might be complicated as Stéphane already pointed out).
> >Likewise, it would be great if instead of a string (with a list of
> country
> >codes separated by white spaces) objects would be given back.
> 
> As I wrote before this is already be supported... see the example I sent
> to
> you.
> The only thing is that the parameter is not named "continent" because
> there
> are also
> subcontinents included... just use "territory" as seen in the example I
> sent
> and
> within the already existing docu.
> 
> And Zend_Locale will never return objects.
> How should I return an object "north-america" or "antarctica" ???
> The data which we speak of here is not identical with a locale !!!
> 
> >Enough of the feature request ;)
> 
> Well, until now no one sent a feature request to jira.
> 
> Greetings
> Thomas
> I18N Team Leader

Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

[Simon Mundy]

Yeah I agree with Stanislav - the thinking behind the original  
request was just to tuck the Zend.php file away, not the whole  
framework.


The PEAR-like directory structure works pretty well as-is and I'd  
daresay most people can get to grips with it quickly.


I'd be happy moving Zend.php -> Zend/Core.php and leaving it as-is  
_OR_ completely removing it and splitting it into the other purpose- 
built components (Zend_Debug, Zend_Registry, Zend_Environment, etc...)


Now every package has its own directory and one file in parent  
directory, so i offer to move all files to package directory:

Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
Zend/Filter/Zend_Filter_Alnum.php [no change, couse it is same  
package]
Zend/Filter/Zend_Filter_Alpha.php [no change, couse it is same  
package]
Zend/Filter/Zend_Filter_Digits.php [no change, couse it is same  
package]


why we need to repeat Zend_Filter twice? What good would it make?  
And how we know Zend and Filter get its own directory but Alpha  
does not?

--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.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] Request for feedback: moving Zend.php to Zend/Zend.php

[Stanislav Malyshev]

Now every package has its own directory and one file in parent 
directory, so i offer to move all files to package directory:

Zend/Zend_Filter.php => Zend/Filter/Zend_Filter.php
Zend/Filter/Zend_Filter_Alnum.php [no change, couse it is same package]
Zend/Filter/Zend_Filter_Alpha.php [no change, couse it is same package]
Zend/Filter/Zend_Filter_Digits.php [no change, couse it is same package]


why we need to repeat Zend_Filter twice? What good would it make? And 
how we know Zend and Filter get its own directory but Alpha does not?

--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/