Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Service_ShortenUrl Component Proposal

Proposed Component Name Zend_Service_ShortenUrl
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Service_ShortenUrl
Proposers Martin Hujer
Zend Liaison Dolf Schimmel (Freeaqingme)
Revision 1.0 - 12th August 2008: Initial Draft.
8th December 2008: Refactored, code and tests added
24th December 2008: Refactored according to comment (wiki revision: 12)

Table of Contents

1. Overview

Zend_Service_ShortenUrl provide a simple interface to access different url-shortening services. It will use adapter design pattern.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component must allow to shorten any URL.
  • This component will have method to get the target location of shortened URL (if the service supports it)

4. Dependencies on Other Framework Components

  • Zend_Service_Abstract
  • Zend_Exception
  • Zend_Http

5. Theory of Operation

...

6. Milestones / Tasks

  • Milestone 1: Finalize this proposal
  • Milestone 2: Working prototype checked into SVN.
  • Milestone 3: Unit tests exist, work, and are checked into SVN.
  • Milestone 4: Community and Zend review

7. Class Index

  • Zend_Service_ShortenUrl
  • Zend_Service_ShortenUrl_Exception
  • Zend_Service_ShortenUrl_Abstract
  • Zend_Service_ShortenUrl_TinyUrlCom
  • ZendXe_Service_ShortenUrl_JdemCz

8. Use Cases

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Dec 08, 2008

    <p>I have written code and tests. They are in my repository. Link is in the "2. References" section.</p>

  2. Dec 15, 2008

    <p>Another relevant usecase would be URL shortening with random providers. E.g. Twitter does it that way. So a composite shorten URL service would be helpful which chooses one specific implementation randomly.</p>

  3. Dec 15, 2008

    <p>Design:</p>
    <ul>
    <li>As not all services support the "unshorten" feature it would be better to have two interfaces, one for shortening and one for unshortening (maybe extending the shortening interface, as unshortening without shortening does not make sense).</li>
    <li>getTaget(): Maybe a better name would be "unshorten"?</li>
    <li>_checkUrl(): Better name would be "_validateUri"?</li>
    </ul>

    <p>Let's do some code review:<br />
    Mhujer_Service_ShortenUrl_Abstract::_checkUrl()</p>
    <ul>
    <li>Missing require_once() for Zend/Uri.php</li>
    </ul>

    <p>Mhujer_Service_ShortenUrl_JdemCz::shorten() and Mhujer_Service_ShortenUrl_TinyUrlCom::shorten()</p>
    <ul>
    <li>@throws comments missing</li>
    <li>Uses parent::_checkUrl(). Is the explicit parent needed? Why not simply rely on $this</li>
    <li>Query data added in Zend_Uri::factory(). Violates DRY, as Zend_Uri_Http already has setQuery() which can be used to construct the query part</li>
    <li>$httpclient would be written as "HTTP client" in spoken language, so it should be $httpClient</li>
    <li>Zend_Http_Client provides a fluent interface, which can be used</li>
    <li>Inner exceptions from Zend_Http_Client are not catched and rethrown as service exceptions</li>
    </ul>

    <p>Mhujer_Service_ShortenUrl_JdemCz::getTarget()</p>
    <ul>
    <li>@throws comments missing</li>
    <li>The first guarding exception could be removed by reusing _checkUrl()</li>
    <li>The second exception can be generalized by defining a method _verifyBaseUri() in the abstract superclass and defining a property _baseUri in each descendant</li>
    <li>Inner exceptions from Zend_Http_Client are not catched and rethrown as service exceptions</li>
    <li>Zend_Http_Client provides a fluent interface, which can be used</li>
    <li>$httpclient would be written as "HTTP client" in spoken language, so it should be $httpClient</li>
    <li>Query data added in Zend_Uri::factory(). Violates DRY, as Zend_Uri_Http already has setQuery() which can be used to construct the query part</li>
    </ul>

    1. Dec 24, 2008

      <p>Thank you for your comment, Lars. I will correct my code.</p>

      <p>Design:</p>
      <ul class="alternate">
      <li>I think, it is possible to emulate unshortening also for services which does not support it. I have added it for TinyUrl.com. I think it is better to throw Exception in services which does not support it, but it can be further discussed.</li>
      <li>getTarget() renamed to unshorten() - makes sence</li>
      <li>_checkUrl() -> _validateUri</li>
      </ul>

      <p>Mhujer_Service_ShortenUrl_Abstract::_checkUrl()</p>
      <ul class="alternate">
      <li>require_once is not required because it extends Zend_Service_Abstract, it requires Zend_Http_Client and it requires Zend/Uri.php</li>
      </ul>

      <p>I have updated and refactored code and comments of classes according to your notes.</p>

      <p>I'd be happy if you could have a quick look at changes!</p>

      1. Dec 26, 2008

        <p>Thanks for your attention Martin. One thing: I guess a strpos($url, $this->_baseUri) === 0 will be more efficient in _verifyBaseUri(). Aside from that I'm not sure if it is a good idea to "hack" unshorten support for services not providing an API for it. I think for APIs the providers guarantee a certain stability, while for the web that is not always the case. But that's at the end something Zend must decide, I'm just having an opinion there. For the interface vs. exception thing: I think an exception is - well - an exception and should be treated like that. A service not providing unshortening is not really an exception, but a different implementation, therefore I vote for the interface. But you are the proposer, it's totally up to you what route you choose.</p>

        1. Feb 20, 2009

          <p>Thanks for PHP tip <ac:emoticon ac:name="smile" /></p>

          <p>I think, that if it would be mentioned in docs, it is good to have "hacked" unshorten support. Otherwise, users will be forced to write it themselves.</p>

          <p>I know, that APIs are usually more stable then web, but I can't see any other difference between change of API and change of web from the point of code change.</p>

          <p>But, I'm free to discussion about it...</p>

          <p>As for the abstract unshorten method, I can make non-abstract and put the exception into the parent class. And when user would want to call it in the concrete adapter, he will get 'huh, not implemented for this service' message.</p>

  4. Jan 10, 2009

    <p>A couple of points on the naming that I have discussed with the team at Zend, and we seem to agree that. . .</p>

    <p>1) Since shortening URL's is becoming a relatively common use case- what with Twitter and all- there should be a top-level component called Zend_ShortUrl. Note that is 'ShortUrl' <strong>not</strong> 'ShortenUrl', which reflects our standardizing on nouns as opposed to verbs for package names. Obviously, components such as Zend_Validate were named before this convention was established, and those packages may be renamed with 2.0. This proposal may have to be renamed to reflect this package structure.</p>

    <p>2) The interface should have multiple backends as has been discussed, with all web services going under Zend_Service, eg, Zend_Service_JdemCz. The interface above should <strong>not</strong> go in to the Zend_Service package as outlined in point 1. It should not be assumed that all shortening adapters are for services that are remote; if there are any local URL shortening implementations in the future- similar to the URL shortening functionality that Confluence offers on the info view of each page that uses the same domain name but a much shorter path/parameter string- we will decide what package hierarchy they belong in as they are proposed.</p>

    <p>Hope this makes sense to you. Let me know what you think in comments (I'm now subscribed to this proposal).</p>

    <p>,Wil</p>

    1. Feb 20, 2009

      <p>Hi,</p>

      <p>sorry for my long inactivity!</p>

      <p>I'm not sure, if I understand your comment clearly, I understand it this way:</p>
      <ul class="alternate">
      <li>There would be Zend_ShortUrl package, with adapters called eg. Zend_Service_JdemCz and Zend_Service_TinyUrlCom.</li>
      <li>The reason for this is, that there could be some local url shortening classes in the future</li>
      </ul>

      <p>Have you meant it this way?</p>

      1. Mar 27, 2009

        <p>Hey Martin,</p>

        <p>That is exactly the points Wil, was making. But I'll make sure with him and we'll have a response as per where to move development today.</p>

        <p>-ralph</p>

  5. Jan 19, 2009

    <p>I don't see a remote or local way to automatically submit URL's, but here's an OS project for a short URL server: <a class="external-link" href="http://www.hido.net/projects/phurl/">http://www.hido.net/projects/phurl/</a>. We may want to see how this project grows and possible support it in the future with Zend_ShortUrl.</p>

  6. Feb 20, 2009

    <p>When the proposal goes further, I will provide adapters for more services, so feel free to post links to them</p>

    <ul class="alternate">
    <li><a class="external-link" href="http://ur.ly/">http://ur.ly/</a></li>
    </ul>

  7. Mar 27, 2009

    <ac:macro ac:name="note"><ac:parameter ac:name="title">"Zend Official Comment"</ac:parameter><ac:rich-text-body>

    <p>This proposal is accepted for development in <strong>Zend Standard Incubator</strong> provided the following points are met:</p>

    <ul>
    <li>Create the master interface at Zend_ShortUrl that will provide the main interface for url shortening.</li>
    <li>Zend_ShortUrl should be able to consume shortening adapters (like a Zend Service for JdemCZ or TinyUrl).</li>
    <li>This will leave the option open to create local url shortening in the future.</li>
    </ul>

    </ac:rich-text-body></ac:macro>

    1. Mar 28, 2009

      <p>I have committed code to the incubator, but I needed to abstract some functionality same for all web url-shortening services, so I've created Zend_ShortUrl_Service_Abstract, where I put it.</p>

      <p>Is this the right way?</p>

      <p><ac:image><ri:url ri:value="http://img401.imageshack.us/img401/8558/classdiagram.png" /></ac:image></p>

      <p>It leaves the option for local url shortening, because you can always create class Zend_ShortUrl_Local_Abstract or sth. like that.</p>

  8. Nov 18, 2009

    <p>What's the status of this proposal? From the last comment comment it appears the component is awaiting approval from Zend liaison. </p>

    <p>I proposed <a class="external-link" href="http://framework.zend.com/wiki/display/ZFPROP/ZendX_Service_Trim+-+Sudheer+Satyanarayana">http://framework.zend.com/wiki/display/ZFPROP/ZendX_Service_Trim+-+Sudheer+Satyanarayana</a> without knowing the interface and abstract classes being developed for short URL services. Zend_Service_Trim can make use of Zend_Service_ShortUrl interface.</p>

  9. Aug 03, 2010

    <p>I'm going to finally finish it.</p>

    <p>I will implement also <a href="http://wiki.github.com/ajstiles/urly/">ur.ly</a> and <a href="http://is.gd/tech.php">is.gd</a> shorteners.</p>

    <p>Any others?</p>

    1. Oct 14, 2010

      <p>How about the <a href="http://www.google.com/enterprise/marketplace/viewListing?productListingId=5143210+6352879591152674960">Google Short Links</a> for Google Apps?</p>