Need more feedback on Zend\Uri proposal

[Shahar Evron]

Hi all,

I've more or less finished writing a Zend\Uri proposal for ZF 2.0. I
also have an implementation of ~80% of what's proposed, + unit tests.

I would however like to get more feedback before I move on with this. I
would really love it if you can review the proposal and comment on it.

Specifically, I have 2 doubts:

1. Is it right to have URI parsing / building in the same class with URI
representation? Or is it more correct / clean / efficient to have a
class for representing URIs (actually a set of classes, e.g.
Zend\Uri\Uri, Zend\Uri\Http, etc.) and one class or set of classes to
handle parsing / constructing URIs to / from strings (e.g
Zend\Uri\Parser or even repurpose Zend\Uri\Factory for this)?

Up until now I thought separating representation from parsing logic is
overkill and over-design, but I would like to get more feedback on that.

2. While all URIs are derived from a generic syntax, there are two major
classes of URIs: Network location based URLs and other URIs. For
example, HTTP URIs in their full form are URLs, because they contain a
network location reference, while "data" URIs or "mailto" URIs are not.
They do not and will never contain a hostname, port or user/password
information as network URIs might.

I thought about separating these two classes into two base classes, and
inherit from them, but again came to the conclusion it's overkill and
will introduce all sorts of weird design issues when representing URIs
of arbitrary schemes.

What this means in effect is that there will be a getPort() method for
data: or mailto: URIs, which will never return any useful information.

Any thoughts on that?

Shahar.

--
Shahar Evron <[hidden email]>

Product Manager
Zend Technologies

Mobile: [phone]
Office: [phone] ext. 9546

[Shahar Evron]

Oh I forgot, the proposal is here:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Uri+2.0+-+Shahar+Evron

Shahar.

On 15/11/10 17:54 PM, Shahar Evron wrote:

> Hi all,
>
> I've more or less finished writing a Zend\Uri proposal for ZF 2.0. I
> also have an implementation of ~80% of what's proposed, + unit tests.
>
> I would however like to get more feedback before I move on with this. I
> would really love it if you can review the proposal and comment on it.
>
> Specifically, I have 2 doubts:
>
> 1. Is it right to have URI parsing / building in the same class with URI
> representation? Or is it more correct / clean / efficient to have a
> class for representing URIs (actually a set of classes, e.g.
> Zend\Uri\Uri, Zend\Uri\Http, etc.) and one class or set of classes to
> handle parsing / constructing URIs to / from strings (e.g
> Zend\Uri\Parser or even repurpose Zend\Uri\Factory for this)?
>
> Up until now I thought separating representation from parsing logic is
> overkill and over-design, but I would like to get more feedback on that.
>
> 2. While all URIs are derived from a generic syntax, there are two major
> classes of URIs: Network location based URLs and other URIs. For
> example, HTTP URIs in their full form are URLs, because they contain a
> network location reference, while "data" URIs or "mailto" URIs are not.
> They do not and will never contain a hostname, port or user/password
> information as network URIs might.
>
> I thought about separating these two classes into two base classes, and
> inherit from them, but again came to the conclusion it's overkill and
> will introduce all sorts of weird design issues when representing URIs
> of arbitrary schemes.
>
> What this means in effect is that there will be a getPort() method for
> data: or mailto: URIs, which will never return any useful information.
>
> Any thoughts on that?
>
> Shahar.
>

--
Shahar Evron <[hidden email]>

Product Manager
Zend Technologies