Re: Re: Debugging/deciphering library methods

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.

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).

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?

--
Trevor Johns
http://tjohns.net