[Typo3-dev] Porposal for a lean real URL solution

Peter Russ peter.russ at 4dfx.de
Wed Sep 1 18:32:30 CEST 2004


Hallo Jan,

thanks for your comments on the proposal.
Pls. find my reply below.

Regs Peter,

Jan Roehrich wrote:

[...]
> 1. and 2.: Rather than extending the alias field I would introduce a new
> field. But how would you use this field? You have to make sure that it is
> unique (not a problem as I can see in 2) but - much more importand - it
> must be reasonable and the editor is capable of creating arbitrary paths -
> I think this would be not a good idea thinking about our secretary!

The reason why "extending" is prefered, that alias is already 
implemented everywhere. So either the id is taken or the alias. No 
headache about "how to get the field replacing ..." etc.

Creating the right path would be straight forward, but should be 
implemented in a second step.

1) If an alias is not set: get the alias from parent and add the title
2) A function to rebuild the aliases.
3) A strategy what happens if an element is copied or moved: but this 
could be defined in the TCA.

But as I mentioned in the paper: 1 step manually.

I guess for 80% of the user a working and fast solution with some manual 
tasks is better than a buggy one with a lot of overhead. But it always 
depend on how many dynamic content is on the page!

> 
> 4.: What if someone doesn't supply such an alias?

No problem with that as we change anything on the other original code 
EVERYTHING will work as usual :-) That the benefit of this solution:
No alias than the id is taken.
Pretty cheap.

> 
> In general:
> It isn't as easy as you think to develop such an extension. When I first
> posted my idea to write such an extension 2 years ago I got a lot of
> answers. All with the same content: "It's impossible to do that!". But my
> opinion has been that it was possible and as you can see it is possible.
> But I spent weeks on developing it and I think it was nearly the same with
> Martin!
> 
> So be careful with such assumptions.

As I mentioned it is a totally different approach than yours. But I see 
that also Typo3 is changing: there are wikis and bug.lists. The reason 
for that is that this softwares are specialized to fullfil special tasks 
much better than Typo3 could ever do.

So my approach is to get the best out of Apache & PHP & Typo3. No Apache 
I loose. So let's see.

Regs Peter.




More information about the TYPO3-dev mailing list