Zend_Server_Reflection_Exception be more specific with your feedback...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Zend_Server_Reflection_Exception be more specific with your feedback...

Erik Olof Wahlstrom
I am working with creating a Zend_Json_Server and setting some classes like so:

$server = new Zend_Json_Server();

$server->setClass('MyClass', 'mynamespace');

When I try to get the smd for this, Zend_Reflection throws the following error about my class:

Zend_Server_Reflection_Exception Object
"Variable number of arguments is not supported for services (except optional parameters). Number of function arguments must currespond to actual number of arguments described in a docblock."

I understand exactly what this means and have gotten this code to work using some less complex classes - however, on the class I am attempting to expose right now, I just cannot find where I might have a discrepancy in my docblock.

It would be extremely usefull if the Zend_Server_Reflection threw an exception that could help pinpoint which method it was having problems with...  Has anyone had a similar experience?

Extra points to whomever gets the reference in the subject... :P
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Server_Reflection_Exception be more specific with your feedback...

weierophinney
Administrator
-- edub <[hidden email]> wrote
(on Tuesday, 31 March 2009, 12:05 PM -0700):

>
> I am working with creating a Zend_Json_Server and setting some classes like
> so:
>
> $server = new Zend_Json_Server();
>
> $server->setClass('MyClass', 'mynamespace');
>
> When I try to get the smd for this, Zend_Reflection throws the following
> error about my class:
>
> Zend_Server_Reflection_Exception Object
> "Variable number of arguments is not supported for services (except optional
> parameters). Number of function arguments must currespond to actual number
> of arguments described in a docblock."
>
> I understand exactly what this means and have gotten this code to work using
> some less complex classes - however, on the class I am attempting to expose
> right now, I just cannot find where I might have a discrepancy in my
> docblock.
>
> It would be extremely usefull if the Zend_Server_Reflection threw an
> exception that could help pinpoint which method it was having problems
> with...  Has anyone had a similar experience?

Wow... I'm not sure how that exception message could be any more clear,
actually.

What it's saying is that there is a discrepancy with the number of
arguments defined in the function call and those in its corresponding
docblock. As an example:

    /**
     * Do something
     *
     * @param  string $foo
     * @return string
     */
    public function doSomething($foo, $bar)
    {
    }

In this example, your function requires 2 parameters -- but your
docblock is only reporting one of them. This is an issue as we cannot
infer any type information on the second parameter -- and thus an
exception is raised.

The opposite is also true:

    /**
     * Do something
     *
     * @param  string $foo
     * @return string
     */
    public function doSomething()
    {
    }

In this case, you may be using func_get_args() to process variable
numbers of arguments in your method. Being a good developer, you've
documented the fact that you might accept a parameter. However, because
there is no corresponding _real_ parameter in the method definition,
reflection is unaware of it, leading to a mismatch between the two.
Again, an exception is raised.

Both situtations are summed up nicely in the last sentence of that
exception message:

    "Number of function arguments must correspond to actual number of
    arguments described in a docblock."

--
Matthew Weier O'Phinney
Software Architect      | [hidden email]
Zend Framework          | http://framework.zend.com/
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Server_Reflection_Exception be more specific with your feedback...

Erik Olof Wahlstrom
Thanks for your response, however I had reviewed my code at LEAST ten times before I submitted my question to the mailing list...  Finally, I resorted to copying my class to a new name and then, starting at the bottom, deleting each method from the class.  I was expecting to pinpoint which method was causing the problem.  

As it turned out, I continued deleting methods all the way to my __construct - even then, the code still gives the same error.  Lightbulb moment ensues - my class is extending Zend_Db_Table and the error is obviously being thrown in regards to some code in that class (or more accurately Zend_Db_Table_Abstract).

I can see that this brings up a whole assortment of issues in regards to the Zend_Json_Server - for example, a lot of return types from Zend_Db_Table_Abstract are obviously not types that could be handled natively by JavaScript.

So I guess the question has morphed into the following: how can I expose a class through Zend_Json_Server that extends classes such as Zend_Db_Table?



Matthew Weier O'Phinney-3 wrote
-- edub <ewahlstr@gmail.com> wrote
(on Tuesday, 31 March 2009, 12:05 PM -0700):
>
> I am working with creating a Zend_Json_Server and setting some classes like
> so:
>
> $server = new Zend_Json_Server();
>
> $server->setClass('MyClass', 'mynamespace');
>
> When I try to get the smd for this, Zend_Reflection throws the following
> error about my class:
>
> Zend_Server_Reflection_Exception Object
> "Variable number of arguments is not supported for services (except optional
> parameters). Number of function arguments must currespond to actual number
> of arguments described in a docblock."
>
> I understand exactly what this means and have gotten this code to work using
> some less complex classes - however, on the class I am attempting to expose
> right now, I just cannot find where I might have a discrepancy in my
> docblock.
>
> It would be extremely usefull if the Zend_Server_Reflection threw an
> exception that could help pinpoint which method it was having problems
> with...  Has anyone had a similar experience?

Wow... I'm not sure how that exception message could be any more clear,
actually.

What it's saying is that there is a discrepancy with the number of
arguments defined in the function call and those in its corresponding
docblock. As an example:

    /**
     * Do something
     *
     * @param  string $foo
     * @return string
     */
    public function doSomething($foo, $bar)
    {
    }

In this example, your function requires 2 parameters -- but your
docblock is only reporting one of them. This is an issue as we cannot
infer any type information on the second parameter -- and thus an
exception is raised.

The opposite is also true:

    /**
     * Do something
     *
     * @param  string $foo
     * @return string
     */
    public function doSomething()
    {
    }

In this case, you may be using func_get_args() to process variable
numbers of arguments in your method. Being a good developer, you've
documented the fact that you might accept a parameter. However, because
there is no corresponding _real_ parameter in the method definition,
reflection is unaware of it, leading to a mismatch between the two.
Again, an exception is raised.

Both situtations are summed up nicely in the last sentence of that
exception message:

    "Number of function arguments must correspond to actual number of
    arguments described in a docblock."

--
Matthew Weier O'Phinney
Software Architect      | matthew@zend.com
Zend Framework          | http://framework.zend.com/
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Server_Reflection_Exception be more specific with your feedback...

weierophinney
Administrator
-- Erik Olof Wahlstrom <[hidden email]> wrote
(on Wednesday, 01 April 2009, 05:01 PM -0700):

>
> Thanks for your response, however I had reviewed my code at LEAST ten times
> before I submitted my question to the mailing list...  Finally, I resorted
> to copying my class to a new name and then, starting at the bottom, deleting
> each method from the class.  I was expecting to pinpoint which method was
> causing the problem.  
>
> As it turned out, I continued deleting methods all the way to my __construct
> - even then, the code still gives the same error.  Lightbulb moment ensues -
> my class is extending Zend_Db_Table and the error is obviously being thrown
> in regards to some code in that class (or more accurately
> Zend_Db_Table_Abstract).
>
> I can see that this brings up a whole assortment of issues in regards to the
> Zend_Json_Server - for example, a lot of return types from
> Zend_Db_Table_Abstract are obviously not types that could be handled
> natively by JavaScript.
>
> So I guess the question has morphed into the following: how can I expose a
> class through Zend_Json_Server that extends classes such as Zend_Db_Table?

Simple answer: don't.

Longer answer: create a "service layer" for your models. This layer will
consume your Zend_Db_Table objects and create return values that your
server classes can then safely expose. For example, they might case
Zend_Db_Table_Rows to arrays before returning them, or detect when no
results were found and return a boolean false.

It's typically a bad idea to use Zend_Db_Table directly with the server
classes because doing so exposes methods such as delete() and save() --
you're basically giving unfettered access to the database via your
service layer, without any validation whatsoever. You should only expose
what's absolutely necessary, and ensure that the data provided is valid
before you perform any DB operations.

> Matthew Weier O'Phinney-3 wrote:
> >
> > -- edub <[hidden email]> wrote
> > (on Tuesday, 31 March 2009, 12:05 PM -0700):
> >>
> >> I am working with creating a Zend_Json_Server and setting some classes
> >> like
> >> so:
> >>
> >> $server = new Zend_Json_Server();
> >>
> >> $server->setClass('MyClass', 'mynamespace');
> >>
> >> When I try to get the smd for this, Zend_Reflection throws the following
> >> error about my class:
> >>
> >> Zend_Server_Reflection_Exception Object
> >> "Variable number of arguments is not supported for services (except
> >> optional
> >> parameters). Number of function arguments must currespond to actual
> >> number
> >> of arguments described in a docblock."
> >>
> >> I understand exactly what this means and have gotten this code to work
> >> using
> >> some less complex classes - however, on the class I am attempting to
> >> expose
> >> right now, I just cannot find where I might have a discrepancy in my
> >> docblock.
> >>
> >> It would be extremely usefull if the Zend_Server_Reflection threw an
> >> exception that could help pinpoint which method it was having problems
> >> with...  Has anyone had a similar experience?
> >
> > Wow... I'm not sure how that exception message could be any more clear,
> > actually.
> >
> > What it's saying is that there is a discrepancy with the number of
> > arguments defined in the function call and those in its corresponding
> > docblock. As an example:
> >
> >     /**
> >      * Do something
> >      *
> >      * @param  string $foo
> >      * @return string
> >      */
> >     public function doSomething($foo, $bar)
> >     {
> >     }
> >
> > In this example, your function requires 2 parameters -- but your
> > docblock is only reporting one of them. This is an issue as we cannot
> > infer any type information on the second parameter -- and thus an
> > exception is raised.
> >
> > The opposite is also true:
> >
> >     /**
> >      * Do something
> >      *
> >      * @param  string $foo
> >      * @return string
> >      */
> >     public function doSomething()
> >     {
> >     }
> >
> > In this case, you may be using func_get_args() to process variable
> > numbers of arguments in your method. Being a good developer, you've
> > documented the fact that you might accept a parameter. However, because
> > there is no corresponding _real_ parameter in the method definition,
> > reflection is unaware of it, leading to a mismatch between the two.
> > Again, an exception is raised.
> >
> > Both situtations are summed up nicely in the last sentence of that
> > exception message:
> >
> >     "Number of function arguments must correspond to actual number of
> >     arguments described in a docblock."
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | [hidden email]
> > Zend Framework          | http://framework.zend.com/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Zend_Server_Reflection_Exception-be-more-specific-with-your-feedback...-tp22807177p22835017.html
> Sent from the Zend Web Services mailing list archive at Nabble.com.
>

--
Matthew Weier O'Phinney
Software Architect      | [hidden email]
Zend Framework          | http://framework.zend.com/
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Server_Reflection_Exception be more specific with your feedback...

Erik Olof Wahlstrom
That makes sense - thanks for the explanation.  

For this example, I will be using Dojo on the front-end (dojo.rpc.JsonService) to consume the services exposed by the "service layer" classes.  This indeed  brings up the issue of securing these services...

My first thought is to pass the userId as an argument in the dojo.rpc.JsonService call to the service, check if that userId has permissions for the requested action/method, and continue from there.  Clearly this is faulty because the dojo.rpc.JsonService submits using HTTP Post which could very easily be spoofed should one so desire.

My second thought was to capture the user's auth info in the Controller action and pass it into where the Zend_Json_Server resides and verify permissions there before allowing access to the server...?

What is your currently used best practice for this?

Erik

Matthew Weier O'Phinney-3 wrote
-- Erik Olof Wahlstrom <ewahlstr@gmail.com> wrote
(on Wednesday, 01 April 2009, 05:01 PM -0700):
>
> Thanks for your response, however I had reviewed my code at LEAST ten times
> before I submitted my question to the mailing list...  Finally, I resorted
> to copying my class to a new name and then, starting at the bottom, deleting
> each method from the class.  I was expecting to pinpoint which method was
> causing the problem.  
>
> As it turned out, I continued deleting methods all the way to my __construct
> - even then, the code still gives the same error.  Lightbulb moment ensues -
> my class is extending Zend_Db_Table and the error is obviously being thrown
> in regards to some code in that class (or more accurately
> Zend_Db_Table_Abstract).
>
> I can see that this brings up a whole assortment of issues in regards to the
> Zend_Json_Server - for example, a lot of return types from
> Zend_Db_Table_Abstract are obviously not types that could be handled
> natively by JavaScript.
>
> So I guess the question has morphed into the following: how can I expose a
> class through Zend_Json_Server that extends classes such as Zend_Db_Table?

Simple answer: don't.

Longer answer: create a "service layer" for your models. This layer will
consume your Zend_Db_Table objects and create return values that your
server classes can then safely expose. For example, they might case
Zend_Db_Table_Rows to arrays before returning them, or detect when no
results were found and return a boolean false.

It's typically a bad idea to use Zend_Db_Table directly with the server
classes because doing so exposes methods such as delete() and save() --
you're basically giving unfettered access to the database via your
service layer, without any validation whatsoever. You should only expose
what's absolutely necessary, and ensure that the data provided is valid
before you perform any DB operations.

> Matthew Weier O'Phinney-3 wrote:
> >
> > -- edub <ewahlstr@gmail.com> wrote
> > (on Tuesday, 31 March 2009, 12:05 PM -0700):
> >>
> >> I am working with creating a Zend_Json_Server and setting some classes
> >> like
> >> so:
> >>
> >> $server = new Zend_Json_Server();
> >>
> >> $server->setClass('MyClass', 'mynamespace');
> >>
> >> When I try to get the smd for this, Zend_Reflection throws the following
> >> error about my class:
> >>
> >> Zend_Server_Reflection_Exception Object
> >> "Variable number of arguments is not supported for services (except
> >> optional
> >> parameters). Number of function arguments must currespond to actual
> >> number
> >> of arguments described in a docblock."
> >>
> >> I understand exactly what this means and have gotten this code to work
> >> using
> >> some less complex classes - however, on the class I am attempting to
> >> expose
> >> right now, I just cannot find where I might have a discrepancy in my
> >> docblock.
> >>
> >> It would be extremely usefull if the Zend_Server_Reflection threw an
> >> exception that could help pinpoint which method it was having problems
> >> with...  Has anyone had a similar experience?
> >
> > Wow... I'm not sure how that exception message could be any more clear,
> > actually.
> >
> > What it's saying is that there is a discrepancy with the number of
> > arguments defined in the function call and those in its corresponding
> > docblock. As an example:
> >
> >     /**
> >      * Do something
> >      *
> >      * @param  string $foo
> >      * @return string
> >      */
> >     public function doSomething($foo, $bar)
> >     {
> >     }
> >
> > In this example, your function requires 2 parameters -- but your
> > docblock is only reporting one of them. This is an issue as we cannot
> > infer any type information on the second parameter -- and thus an
> > exception is raised.
> >
> > The opposite is also true:
> >
> >     /**
> >      * Do something
> >      *
> >      * @param  string $foo
> >      * @return string
> >      */
> >     public function doSomething()
> >     {
> >     }
> >
> > In this case, you may be using func_get_args() to process variable
> > numbers of arguments in your method. Being a good developer, you've
> > documented the fact that you might accept a parameter. However, because
> > there is no corresponding _real_ parameter in the method definition,
> > reflection is unaware of it, leading to a mismatch between the two.
> > Again, an exception is raised.
> >
> > Both situtations are summed up nicely in the last sentence of that
> > exception message:
> >
> >     "Number of function arguments must correspond to actual number of
> >     arguments described in a docblock."
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | matthew@zend.com
> > Zend Framework          | http://framework.zend.com/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Zend_Server_Reflection_Exception-be-more-specific-with-your-feedback...-tp22807177p22835017.html
> Sent from the Zend Web Services mailing list archive at Nabble.com.
>

--
Matthew Weier O'Phinney
Software Architect      | matthew@zend.com
Zend Framework          | http://framework.zend.com/
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Server_Reflection_Exception be more specific with your feedback...

weierophinney
Administrator
-- Erik Olof Wahlstrom <[hidden email]> wrote
(on Thursday, 02 April 2009, 01:12 PM -0700):

> That makes sense - thanks for the explanation.  
>
> For this example, I will be using Dojo on the front-end
> (dojo.rpc.JsonService) to consume the services exposed by the "service
> layer" classes.  This indeed  brings up the issue of securing these
> services...
>
> My first thought is to pass the userId as an argument in the
> dojo.rpc.JsonService call to the service, check if that userId has
> permissions for the requested action/method, and continue from there.
> Clearly this is faulty because the dojo.rpc.JsonService submits using HTTP
> Post which could very easily be spoofed should one so desire.
>
> My second thought was to capture the user's auth info in the Controller
> action and pass it into where the Zend_Json_Server resides and verify
> permissions there before allowing access to the server...?
>
> What is your currently used best practice for this?

The cool part about JSON-RPC is that it's happening in the same domain,
using HTTP... so you have access to the session. On a project I've been
working on recently, we leveraged this -- we use
Zend_Auth::hasIdentity() and Zend_Auth::getIdentity() to determine if
the user is logged in, and then to grab the identity for later ACL
checks. We've also created standard "error" payloads that can report the
fact that the person is either not logged in or has insufficient ACLs so
that the client can the present a login form or an error dialog.

It also means we only need to pass the parameters necessary for the
called method -- the identity is part of the session already.

> Matthew Weier O'Phinney-3 wrote:
> >
> > -- Erik Olof Wahlstrom <[hidden email]> wrote
> > (on Wednesday, 01 April 2009, 05:01 PM -0700):
> >>
> >> Thanks for your response, however I had reviewed my code at LEAST ten
> >> times
> >> before I submitted my question to the mailing list...  Finally, I
> >> resorted
> >> to copying my class to a new name and then, starting at the bottom,
> >> deleting
> >> each method from the class.  I was expecting to pinpoint which method was
> >> causing the problem.  
> >>
> >> As it turned out, I continued deleting methods all the way to my
> >> __construct
> >> - even then, the code still gives the same error.  Lightbulb moment
> >> ensues -
> >> my class is extending Zend_Db_Table and the error is obviously being
> >> thrown
> >> in regards to some code in that class (or more accurately
> >> Zend_Db_Table_Abstract).
> >>
> >> I can see that this brings up a whole assortment of issues in regards to
> >> the
> >> Zend_Json_Server - for example, a lot of return types from
> >> Zend_Db_Table_Abstract are obviously not types that could be handled
> >> natively by JavaScript.
> >>
> >> So I guess the question has morphed into the following: how can I expose
> >> a
> >> class through Zend_Json_Server that extends classes such as
> >> Zend_Db_Table?
> >
> > Simple answer: don't.
> >
> > Longer answer: create a "service layer" for your models. This layer will
> > consume your Zend_Db_Table objects and create return values that your
> > server classes can then safely expose. For example, they might case
> > Zend_Db_Table_Rows to arrays before returning them, or detect when no
> > results were found and return a boolean false.
> >
> > It's typically a bad idea to use Zend_Db_Table directly with the server
> > classes because doing so exposes methods such as delete() and save() --
> > you're basically giving unfettered access to the database via your
> > service layer, without any validation whatsoever. You should only expose
> > what's absolutely necessary, and ensure that the data provided is valid
> > before you perform any DB operations.
> >
> >> Matthew Weier O'Phinney-3 wrote:
> >> >
> >> > -- edub <[hidden email]> wrote
> >> > (on Tuesday, 31 March 2009, 12:05 PM -0700):
> >> >>
> >> >> I am working with creating a Zend_Json_Server and setting some classes
> >> >> like
> >> >> so:
> >> >>
> >> >> $server = new Zend_Json_Server();
> >> >>
> >> >> $server->setClass('MyClass', 'mynamespace');
> >> >>
> >> >> When I try to get the smd for this, Zend_Reflection throws the
> >> following
> >> >> error about my class:
> >> >>
> >> >> Zend_Server_Reflection_Exception Object
> >> >> "Variable number of arguments is not supported for services (except
> >> >> optional
> >> >> parameters). Number of function arguments must currespond to actual
> >> >> number
> >> >> of arguments described in a docblock."
> >> >>
> >> >> I understand exactly what this means and have gotten this code to work
> >> >> using
> >> >> some less complex classes - however, on the class I am attempting to
> >> >> expose
> >> >> right now, I just cannot find where I might have a discrepancy in my
> >> >> docblock.
> >> >>
> >> >> It would be extremely usefull if the Zend_Server_Reflection threw an
> >> >> exception that could help pinpoint which method it was having problems
> >> >> with...  Has anyone had a similar experience?
> >> >
> >> > Wow... I'm not sure how that exception message could be any more clear,
> >> > actually.
> >> >
> >> > What it's saying is that there is a discrepancy with the number of
> >> > arguments defined in the function call and those in its corresponding
> >> > docblock. As an example:
> >> >
> >> >     /**
> >> >      * Do something
> >> >      *
> >> >      * @param  string $foo
> >> >      * @return string
> >> >      */
> >> >     public function doSomething($foo, $bar)
> >> >     {
> >> >     }
> >> >
> >> > In this example, your function requires 2 parameters -- but your
> >> > docblock is only reporting one of them. This is an issue as we cannot
> >> > infer any type information on the second parameter -- and thus an
> >> > exception is raised.
> >> >
> >> > The opposite is also true:
> >> >
> >> >     /**
> >> >      * Do something
> >> >      *
> >> >      * @param  string $foo
> >> >      * @return string
> >> >      */
> >> >     public function doSomething()
> >> >     {
> >> >     }
> >> >
> >> > In this case, you may be using func_get_args() to process variable
> >> > numbers of arguments in your method. Being a good developer, you've
> >> > documented the fact that you might accept a parameter. However, because
> >> > there is no corresponding _real_ parameter in the method definition,
> >> > reflection is unaware of it, leading to a mismatch between the two.
> >> > Again, an exception is raised.
> >> >
> >> > Both situtations are summed up nicely in the last sentence of that
> >> > exception message:
> >> >
> >> >     "Number of function arguments must correspond to actual number of
> >> >     arguments described in a docblock."
> >> >
> >> > --
> >> > Matthew Weier O'Phinney
> >> > Software Architect      | [hidden email]
> >> > Zend Framework          | http://framework.zend.com/
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Zend_Server_Reflection_Exception-be-more-specific-with-your-feedback...-tp22807177p22835017.html
> >> Sent from the Zend Web Services mailing list archive at Nabble.com.
> >>
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect      | [hidden email]
> > Zend Framework          | http://framework.zend.com/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Zend_Server_Reflection_Exception-be-more-specific-with-your-feedback...-tp22807177p22856101.html
> Sent from the Zend Web Services mailing list archive at Nabble.com.
>

--
Matthew Weier O'Phinney
Software Architect      | [hidden email]
Zend Framework          | http://framework.zend.com/