Page 2 of 2

Posted: Mon Aug 07, 2006 12:28 am
by RobertGonzalez
Ninja, I believe we all thought you'd go that route.

What about URIHandler. Does that break any conventions?

Posted: Mon Aug 07, 2006 12:31 am
by Benjamin
Shouldn't the validation & fixer be in seperate classes?

Posted: Mon Aug 07, 2006 11:35 am
by Ambush Commander
Okay, after reading all your comments, and doing some reading of the URI RFC, I've come to some conclusions:

Seperating validation, normalization and plain-old fixing would negatively affect both performance and readability.

The URI is a complex dataform governed by many different specifications (called schemes). However, URI defines a generic syntax applicable to all schemes, for which the scheme can place further constraints.

The first logical step, then, would be to parse the URI according to the generic syntax and then pass on the components to the correct scheme for further parsing. If the URI turns out to be completely invalid, we can abort real fast. However, notice how parsing and validation are intertwined: you must parse before you can validate.

You also need to parse before you can fix or normalize.

If we seperate the validator logic, we end up parsing the URL twice, and, without common function set, the code gets duplicated too.

Further complicating the situation is the fact that we have two levels of parsing, validation and fixing, the generic URI level and the specific scheme (e.g. HTTP) level.

So... to go full out OOP, we need a ParsedURI, ParsedURI_HTTP and friends, URIValidator, URIValidator_HTTP and friends, URINormalizer, URINormalizer_HTTP and friends, URIFixer for full extensibility and modularity. All this for a spec that really won't change. Oh, and throw in a ResolveRelativeURI.

I'd much rather think of URI validation as a black box that takes a random URI and spits out a good one. Split out the schemas because that changes a lot. But that's it. Top down in a weird convoluted way.

I've got a feeling that splitting them out is the knee-jerk reaction. Does it make less sense after I've explained it this way, or did I completely miss the point?
What about URIHandler. Does that break any conventions?
Hmm... the definition makes sense. Would AttrHandler and ChildHandler make sense too?

Posted: Mon Aug 07, 2006 1:10 pm
by Christopher
I think you mean:

... might possibly negatively affect performance and decrease readability for me. ;)

Posted: Mon Aug 07, 2006 2:19 pm
by Ambush Commander
True. But I've got to make an executive decision sometime, and right now, I'm not convinced that it's a good idea.

Posted: Mon Aug 07, 2006 2:53 pm
by RobertGonzalez
Ambush Commander wrote:
What about URIHandler. Does that break any conventions?
Hmm... the definition makes sense. Would AttrHandler and ChildHandler make sense too?
To me they do, but I made the URIHandler recommendation, so I am biased. Although, when I step back and look at AttrHandler and ChildHandler, they don't make as much sense as URIHandler does.

Re: Gimme a name : URI and friends

Posted: Sun Jan 23, 2011 12:13 pm
by remshad
Luke wrote:I would definately go with URIne
whats URIne ?

Re: Gimme a name : URI and friends

Posted: Sun Jan 23, 2011 12:26 pm
by John Cartwright
remshad wrote:
Luke wrote:I would definately go with URIne
whats URIne ?
Please stop resurrecting old threads.

Topic Locked.