Debugging/deciphering library methods

[dmclark]

Hi,

I am using the gcal zend library in Symfony using the symfony-zend
bridge plugin.

I  am successfully getting the feed of a calendar and setting the sort
order, etc.

I am having trouble rendering (or ideally, parsing to import the data
into local db). $event->title->text works, but none of the other
documented method seem to work.

I would rather not have to use dom if at all possible

Any pointers?

thanks

[Ryan Boyd-3]

Hi Clark,

Can you please give us a snippet of the relevant code, so we can see what methods are not working for you, what URLs you're using, what query params, and what class objects you're using?

Cheers,
-Ryan

On 9/25/07, dmclark <[hidden email]> wrote:

Hi,

I am using the gcal zend library in Symfony using the symfony-zend
bridge plugin.

I  am successfully getting the feed of a calendar and setting the sort
order, etc.

I am having trouble rendering (or ideally, parsing to import the data
into local db). $event->title->text works, but none of the other
documented method seem to work.

I would rather not have to use dom if at all possible

Any pointers?

thanks


--
View this message in context: http://www.nabble.com/Debugging-deciphering-library-methods-tf4515579s16154.html#a12879596
Sent from the Zend gdata mailing list archive at Nabble.com.

[dmclark]

Ryan,

I have a func:
        public static function get_gcal_events()
        {
                $service = Zend_Gdata_Calendar::AUTH_SERVICE_NAME; // predefined service name for calendar

                $client = Zend_Gdata_ClientLogin::getHttpClient(sfConfig::get('app_gcal_username'),sfConfig::get('app_gcal_password'),$service);
          $service = new Zend_Gdata_Calendar($client);
                $query = $service->newEventQuery();
                $query->setUser('default');
                // Set to $query->setVisibility('private-magicCookieValue') if using MagicCookie auth
                $query->setVisibility('private');
                $query->setProjection('full');
                $query->setOrderby('starttime');
                $query->setSortOrder('ascending');
                $query->setFutureevents('true');
                // $query->setStartMin(date("Y-m-d"));
                $query->setMaxResults(25);
               
                return $service->getCalendarEventFeed($query);
        }
and then in the view I have tried many things, but currently have
<?php if ($eventfeed): ?>
<!-- <dl> -->
        <?php foreach ($eventfeed as $event): ?>
                <strong>Title: </strong> <?php echo $event->title->text ?> <br />
                <strong>content: </strong> <?php echo $event->content ?> <br />
                <strong>when: </strong> <?php echo $event->when['startTime'] ?> <br />
                <pre><?php print_r($event) ?></pre>
                <hr />
        <?php endforeach; ?>
<!-- </dl> -->
<?php endif; ?>

Ryan Boyd-3 wrote:

Hi Clark,

Can you please give us a snippet of the relevant code, so we can see what
methods are not working for you, what URLs you're using, what query params,
and what class objects you're using?

Cheers,
-Ryan


On 9/25/07, dmclark <[e-mail]> wrote:
>
>
> Hi,
>
> I am using the gcal zend library in Symfony using the symfony-zend
> bridge plugin.
>
> I  am successfully getting the feed of a calendar and setting the sort
> order, etc.
>
> I am having trouble rendering (or ideally, parsing to import the data
> into local db). $event->title->text works, but none of the other
> documented method seem to work.
>
> I would rather not have to use dom if at all possible
>
> Any pointers?
>
> thanks
>
>
> --
> View this message in context:
> http://www.nabble.com/Debugging-deciphering-library-methods-tf4515579s16154.html#a12879596
> Sent from the Zend gdata mailing list archive at Nabble.com.
>
>

[Trevor Johns]

On 2007-09-25 10:37:06 -0700, dmclark said:

> <strong>Title: </strong> <?php echo $event->title->text ?> <br />
> <strong>content: </strong> <?php echo $event->content ?> <br />
> <strong>when: </strong> <?php echo $event->when['startTime'] ?> <br />

Hi dmclark,
I think I might see your problem. Try $event->content->text and
$event->when->startTime.

I know it can be confusing at times. Unfortunately __toString() isn't
implemented consistently throughout the client library, which would
mitigate the simpler cases. This is a known issue (ZF-1632), and
something I'd very much like to see improved for future releases.

--
Trevor Johns
http://tjohns.net

[Ryan Boyd-3]

On 9/27/07, Trevor Johns <[hidden email]> wrote:

On 2007-09-25 10:37:06 -0700, dmclark said:

>               <strong>Title: </strong> <?php echo $event->title->text ?> <br />
>               <strong>content: </strong> <?php echo $event->content ?> <br />
>               <strong>when: </strong> <?php echo $event->when['startTime'] ?> <br />

Hi dmclark,
I think I might see your problem. Try $event->content->text and
$event->when->startTime.

I know it can be confusing at times. Unfortunately __toString() isn't
implemented consistently throughout the client library, which would
mitigate the simpler cases. This is a known issue (ZF-1632), and
something I'd very much like to see improved for future releases.

Thanks Trevor.  There also another thread about this issue here:
http://groups.google.com/group/google-calendar-help-dataapi/browse_frm/thread/fd6c99e68ae7edb7/a52dffe82a1b4560?lnk=gst&q=umb.edu&rnum=1#a52dffe82a1b4560

Not sure that toString solves this issue entirely though.  It definitely works for things like atom:content (which is the confusing part here).  We had some other ideas that we were floating around, and I thought I'd see what people think about it.

Right now, the data model closely resembles the XML.  However, there are some XML elements used by GData services which only have a single attribute/child text node (or a single commonly-used attribute/child text node).  See the class that represents gCal:selected, gCal:color, gCal:timezone for instance.  Currently, to set one of these on an entry, the developer needs to actually create a new instance of the class and set the appropriate values.  It would be easier if the client could just pass the appropriate text for an entry.

For example:
Instead of:
$entry->color = $gdata->newColor('orange')
We'd have:
$entry->colorValue = 'orange';

Similar things could hold true for title and content (though they each have more than one bit of data which needs to be set):
$entry->titleValue = 'foo';  (would automatically create a Zend_Gdata_App_Extension_Title object with the appropriate child text node.

The same thing would be used for retrieving data (though the toString solution solves this for newer versions of PHP):
print $entry->colorValue would traverse the Zend_Gdata_Calendar_Extension_Color object and grab the value of $_value

Thoughts?

-Ryan

:
$event->contentValue, $event->

--
Trevor Johns
http://tjohns.net

[Ryan Boyd-3]

On 9/27/07, Trevor Johns <[hidden email]> wrote:

Comments inline below.

On Sep 27, 2007, at 9:51 AM, Ryan Boyd wrote:

> Thanks Trevor.  There also another thread about this issue here:
> http://groups.google.com/group/google-calendar-help-dataapi/
> browse_frm/thread/fd6c99e68ae7edb7/a52dffe82a1b4560?
> lnk=gst&q=umb.edu&rnum=1#a52dffe82a1b4560

Thanks for the heads up. I didn't realize that this message had been
cross-posted.


> Not sure that toString solves this issue entirely though.  It
> definitely works for things like atom:content (which is the
> confusing part here).  We had some other ideas that we were
> floating around, and I thought I'd see what people think about it.

I agree, implementing __toString() definitely doesn't solve this
entirely. It only helps for the simplest cases, and it will still
break when trying to set properties.

> Right now, the data model closely resembles the XML.  However,
> there are some XML elements used by GData services which only have
> a single attribute/child text node (or a single commonly-used
> attribute/child text node).  See the class that represents
> gCal:selected, gCal:color, gCal:timezone for instance.  Currently,
> to set one of these on an entry, the developer needs to actually
> create a new instance of the class and set the appropriate values.
> It would be easier if the client could just pass the appropriate
> text for an entry.
>
> For example:
> Instead of:
> $entry->color = $gdata->newColor('orange')
> We'd have:
> $entry->colorValue = 'orange';
>
> Similar things could hold true for title and content (though they
> each have more than one bit of data which needs to be set):
> $entry->titleValue = 'foo';  (would automatically create a
> Zend_Gdata_App_Extension_Title object with the appropriate child
> text node.
>
> The same thing would be used for retrieving data (though the
> toString solution solves this for newer versions of PHP):
> print $entry->colorValue would traverse the
> Zend_Gdata_Calendar_Extension_Color object and grab the value of
> $_value
>
> Thoughts?

I like this line of thinking, and I think I recommended something
similar at some point in the past.

Yep, you did :)

In order not to break backwards compatibility, we could use
introspection to choose the correct behavior. If an instance of
Zend_Gdata_App_Extension is detected, we'd use the current behavior
(just set the property to point to the provided object). For all
other types, we'd use the new behavior (create a new instance of the
property's model and initialize it with the provided data).

This is the reason I recommended appending the attribute name with Value when an option like this is available.  I don't think we can change the normal setters, because people will have no idea what's going to come out of the getter.

so, I call $entry->title = 'foo'
and then I get $entry->title... should that be an Zend_Gdata_App_Extension_Title, or just the string 'title'.

I think appending the attribute names with 'Value' will allow you to use either option.

Extensions which take several parameters, such as
Zend_Gdata_Extension_When does, will be tricky. Unfortunately PHP
doesn't allow method overloading. I can think of a way to hack this
in using optional parameters ($data, $startTime = null, $endTime =
null, ... -- where $data could be either an Extension object or
$valueString), but I'd really like to avoid doing that. Any better
thoughts? Or should we just not implement a shortcut to instantiate
these objects?

I think  my first step would only be to allow these Value attributes for things that either have only 1 value to deal with, or things that have multiple values, but only 1 is used 95% of time.

Then we could follow up with optional ones if we want, but the goal for this was to cover the largest use cases.

-Ryan

--
Trevor Johns
http://tjohns.net

[Ryan Boyd-3]

On 9/29/07, Trevor Johns <[hidden email]> wrote:

On Sep 27, 2007, at 4:02 PM, Ryan Boyd wrote:

>> In order not to break backwards compatibility, we could use
>> introspection to choose the correct behavior. If an instance of
>> Zend_Gdata_App_Extension is detected, we'd use the current behavior
>> (just set the property to point to the provided object). For all
>> other types, we'd use the new behavior (create a new instance of the
>> property's model and initialize it with the provided data).
>
> This is the reason I recommended appending the attribute name with
> Value when an option like this is available.  I don't think we can
> change the normal setters, because people will have no idea what's
> going to come out of the getter.
>
> so, I call $entry->title = 'foo'
> and then I get $entry->title... should that be an
> Zend_Gdata_App_Extension_Title, or just the string 'title'.

It would be an instance of Zend_Gdata_App_Extension_Title.

However, for most operations the user can pretend it's the string
'title'. When it gets passed to something that is expecting a string,
__toString() should get called assuming they're using PHP 5 (which is
supposed to be a requirement for ZF).

As of 5.2.0, with echo and print methods, yep.  Prior to 5.2.0, only echo/print statements which used only the value (and no concatenation) would work.

From the magic methods doc:
" It is worth noting that before PHP 5.2.0 the __toString method was only called when it was directly combined with echo() or print(). Since PHP 5.2.0, it is called in any string context (e.g. in printf() with %s modifier) but not in other types contexts (e.g. with %d modifier). Since PHP 5.2.0, converting objects without __toString method to string would cause E_RECOVERABLE_ERROR."

I still don't know what the result of the following would be (need to test):

$foo = $stringBar . $objectWithToStringMethod;

Also, perhaps more importantly, would be equality checking and things like that.

Basically, it just seems weird to me that someone would call a setter using one type, but would get back another type when calling the getter.  Is there any precedence for this that you're aware of?

Thanks,
-Ryan

> I think appending the attribute names with 'Value' will allow you
> to use either option.

It would. However, it feels like we'd be duplicating code. Wouldn't
'$entry->titleValue' be identical to calling '$entry->title-
>__toString()', or '(string) $entry->title' on PHP 5?

>> Extensions which take several parameters, such as
>> Zend_Gdata_Extension_When does, will be tricky. Unfortunately PHP
>> doesn't allow method overloading. I can think of a way to hack this
>> in using optional parameters ($data, $startTime = null, $endTime =
>> null, ... -- where $data could be either an Extension object or
>> $valueString), but I'd really like to avoid doing that. Any better
>> thoughts? Or should we just not implement a shortcut to instantiate
>> these objects?
>
> I think  my first step would only be to allow these Value
> attributes for things that either have only 1 value to deal with,
> or things that have multiple values, but only 1 is used 95% of time.
>
> Then we could follow up with optional ones if we want, but the goal
> for this was to cover the largest use cases.

Sounds good to me.

--
Trevor Johns
http://tjohns.net