Debugging/deciphering library methods

Thread: Debugging/deciphering library methods

Search this list only Search all lists
Debugging/deciphering library methods
	2007-09-25 08:28:19
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#a 12879596 Sent from the Zend gdata mailing list archive at Nabble.com.

Re: Debugging/deciphering library methods
	2007-09-25 12:26:02

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 < david.clarkumb.edu">david.clarkumb.edu> 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.
Re: Debugging/deciphering library methods
	2007-09-25 12:37:06
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_gca l_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 <david.clarkumb.edu> 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#a 12879596 >> Sent from the Zend gdata mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/ Debugging-deciphering-library-methods-tf4515579s16154.html#a 12884664 Sent from the Zend gdata mailing list archive at Nabble.com.

Re: Re: Debugging/deciphering library methods
	2007-09-27 11:51:02

On 9/27/07, Trevor Johns < trevortjohns.net">trevortjohns.net> 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') We9;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
Re: Re: Debugging/deciphering library methods
	2007-09-27 18:02:19

On 9/27/07, Trevor Johns < trevortjohns.net">trevortjohns.net> 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
Re: Re: Debugging/deciphering library methods
	2007-10-01 11:25:11

On 9/29/07, Trevor Johns < trevortjohns.net">trevortjohns.net> 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 9;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

[1-6]

about | contact Other archives ( Real Estate discussion Medical topics )