[Pier] Internal Link Problems
Locked
 
|
Hi,
since the structures have a "name" beside the "title" it's very difficult to create internal Links when you renamed (rather "retitled") a structure. You have to always remember the name you gave the structure first because if you want to create internal links you have to use now this name else the link is broken. I don't think thats a good Idea because no one can guess the hidden "name" of structures.... Regards, Thomas _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: [Pier] Internal Link Problems
|
|
Hi,
I agree with you about the issue you are raising. In fact, it's the only reason why I am holding back my plan to upgrade to the latest version of Pier. We use a slightly customised Pier to manage our intranet and it was relatively easy to explain to the users that if they want to create a link to a structure, they just have to put the title of the target. The situation was not that smooth when we were using Plone and custom CMS. Even after a while, a large portion of our user base still had troubles to make the difference between the name of a structure and its title when it came to create links. The consequence was that the sites produced during that period contained a lot of endless pages and very few links. So far, we get a better balance between cross-referencing and page size, thanks to the sheer simplicity of the way Pier manages its links. I fear that we will lose this simplicity if we introduce back the same concepts that didn't performed that well during our previous attempts. Regards, Dominique Le 08-mars-06 à 15:55, Thomas Froeb a écrit : > Hi, > > since the structures have a "name" beside the "title" it's very > difficult to create internal Links when you renamed (rather > "retitled") > a structure. > You have to always remember the name you gave the structure first > because if you want to create internal links you have to use now this > name else the link is broken. I don't think thats a good Idea > because no > one can guess the hidden "name" of structures.... > > Regards, > Thomas _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: [Pier] Internal Link Problems
|
|
Hi Dominique, Hi Thomas,
> since the structures have a "name" beside the "title" it's very > difficult to create internal Links when you renamed (rather > "retitled") a structure. thanks for rising the issue with the 'name' and 'title'. To introduce a name was a difficult decision for me, and it is definitely not a final decision, I just wanted to give it a try. The reasons were the following: 1. People want to change the title of pages without that the URL changes, so that they don't need to update their bookmarks. 2. People want to use Pier to model existing (static) pages and want to model the URL to look the exactly the same. 3. People want use strange characters and very long titles, this makes the URL unreadable and difficult to parse and generate. 4. People want use the same title twice within the same context, this is impossible if we use the title as an unique key. > You have to always remember the name you gave the structure first > because if you want to create internal links you have to use now > this name else the link is broken. I don't think thats a good Idea > because no one can guess the hidden "name" of structures.... It is not so hidden after all, you can just copy the part of the URL into your link. > The situation was not that smooth when we were using Plone and custom > CMS. Even after a while, a large portion of our user base still had > troubles to make the difference between the name of a structure and > its title when it came to create links. The consequence was that the > sites produced during that period contained a lot of endless pages > and very few links. Ok, I see that this can be a problem, but I guess that there also a couple of solutions to this problem: a. Let the user browse a tree navigator to help them writing the links. b. Display the current name more clearly in the edit page. > So far, we get a better balance between cross-referencing and page > size, thanks to the sheer simplicity of the way Pier manages its > links. I fear that we will lose this simplicity if we introduce back > the same concepts that didn't performed that well during our previous > attempts. The current trial is definitely a loss of simplicity, I agree, however I don't know of another simple way to get 1. - 4. working only having a title. If there are any ideas how these problems could be cleanly solved otherwise, I would be happy to discuss and maybe (help to) implement them? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: [Pier] Internal Link Problems
|
|
I often wanted to change a title of a page without changing links to it
so the difference between title and name is useful I think. However, it should be clear to the user how to reference a page. Why not displaying in each page (in view mode) the name of the page ? Something like 'Link me with "/myName"' would be cool. -- Damien Cassou _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: [Pier] Internal Link Problems
|
|
> I often wanted to change a title of a page without changing links to it > so the difference between title and name is useful I think. However, it > should be clear to the user how to reference a page. > > Why not displaying in each page (in view mode) the name of the page ? > Something like 'Link me with "/myName"' would be cool. > > > 1. People want to change the title of pages without that the URL > changes, so that they don't need to update their bookmarks. > > 2. People want to use Pier to model existing (static) pages and want > to model the URL to look the exactly the same. > > 3. People want use strange characters and very long titles, this > makes the URL unreadable and difficult to parse and generate. > > 4. People want use the same title twice within the same context, this > is impossible if we use the title as an unique key. intoduced this in my Smallwiki 1 for my XML persistency to have constant directeries (references) in the filesystem and I use this in Pier too. I fixed the problem with the internal links for me by changing the PRPathLookup >> visitChildren: method so that it finds the child also by the title. It is not very clean but works for my purposes. Perhaps it is better to change the reference of a link - after editing a page - to the right path? Regards, Thomas _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: [Pier] Internal Link Problems
|
|
> I fixed the problem with the internal links for me by changing the
> PRPathLookup >> visitChildren: method so that it finds the child also > by the title. It is not very clean but works for my purposes. Yes, that sounds like a simple solution: when parsing a path it first tries to look it up by name, if it fails by title; paths are always printed by name. > Perhaps it is better to change the reference of a link - after > editing a > page - to the right path? I think this happens already. At least the paths should be automatically rewritten if you rename the target page. What do others think about this? Cheers, Lukas > > Regards, Thomas > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: [Pier] Internal Link Problems
|
|
>> I fixed the problem with the internal links for me by changing the
>> PRPathLookup >> visitChildren: method so that it finds the child >> also >> by the title. It is not very clean but works for my purposes. > > Yes, that sounds like a simple solution: when parsing a path it first > tries to look it up by name, if it fails by title; paths are always > printed by name. Pier-All-lr.72 does exactly that. It does not fix the reference string automatically thou. Moreover it tries to be smarter when stripping of the seaside parts of the path. This works well for standard applications, if you make your application the default one (to be run when accessing /seaside) bookmarking won't work at all, due to a limitation in Seaside. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
Re: [Pier] Internal Link Problems
|
|
In reply to this post by Lukas Renggli-2
Hi Thomas, Hi Lukas,
>> I fixed the problem with the internal links for me by changing the >> PRPathLookup >> visitChildren: method so that it finds the child >> also by the title. It is not very clean but works for my purposes. > > Yes, that sounds like a simple solution: when parsing a path it > first tries to look it up by name, if it fails by title; paths are > always printed by name. > ... > What do others think about this? It sounds like a good compromise for me. The interim solution (as implemented in Pier-All.72) already feels much simpler to deal with. Thanks! Dominique _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |