[Zope3-dev] Ugly URLs

[Chris Withers]

Jim Fulton wrote:
> 
> > For example, a non object-container would have a lookup order:
> 
> You cheated and pickled the easy case. ;)

Well yes, but that and containers are gonna be the commonest cases, if we can
get them right, end of problem :-)

> > -presentation
> > -attributes
> 
> If a content object doesn't have presentation logic
> in it, why would an attribute be published directly?

*shrugs* I was thinking this is gonna apply to paths in ZPT and the like as
well?

> If you use implicit acquisition. I expect implicit
> acquisition to fade from usage. Acquisition will still
> be important, but will be more explicit, more predictable, and
> ultimately, more useful.

Indeed, if this lookup is easily configurable, all you have to do is drop
acquisition from the list and you're left with explicit acquisition ;-)

> > While an object-container might have:
> > -items
> > -presentation
> > -attributes
> > -acquisition?
> >
> > How hard would it be to make this configurable, using zcml for example?
> 
> Not hard at all. There are components that are responsible for
> URL traversal. Simply find or write a component that implements the
> policy you want and register it in the configuration file or TTW.

:-)

> Note that with the policy above, you will *always* need to use semicolons
> to get to presentation components unless you can arrange that the item
> and presentation namespaces don't overlap (e.g. by using integer item
> names).

Well, surely the default presentation requires no extra URL bit of any sort?
I reckon for containers, you'll usually only get the one 'view' mode, and that's
where nice URLs are important. For 'edit' modes, I can live with the ; 'cos
accessing items is gonna be a lot mroe common than editing the container,
wouldn't you say?

Of course, the default presentation should depend on what protocol the object
was acessed through, is that possible?

> > BTW, I think bavarian (who are ya, bavarian?) 's suggestion is absolute genius.
> > I wonder how it could be woven in?
> 
> I'm going to write a separate proposal on this.
> Stay tuned.

Cool :-) I really hope those Fishbowl notification tools show up soon or I'm
gonna miss it :-S

> > My only comment would be to not worry about other presentations... for example,
> > if you upload a .png, then obviously it'll have a .png presentation, but why
> > should it have a .jpg presentation at all?
> 
> Dunno. That's up the component developer. :)

As it should be :-)

> My too, or even ".py" source and ".html" render and "" (no suffix)
> use from Python.

*drooool* ;-)

Chris