I'm going to try to respond to everyone's concerns here. First, let me say that the autolink replacement is meant to do what the old autolink did and not more. It seems to me that some of the concerns you have here are asking for more than the original implementation did. Furthermore, autolinks are made to apply to adhere to standard HTML link behavior as much as possible. With further ado, here are the replies.
> How are we going to support absolute package-path? Users can specify the Webapp base path, like you suggested. > I recall Jon talking about an alias map (Admin.html => > administration/Home.html) to be set through AppSettings - The currenlty implementation works with admin.Home.html. I propose the new one will ONLY work with admin/Home.html ("." => "/") Alias maps are against the natural behavior of HTML links so I am against this. > /admin/Home.html could solve the absolute Path problem. But I propose to > combine it with a rootPackage name configureable through AppSettings. Like > rootPath=wicket.myApp and href="/admin/Home.html" leads to class name > wicket.myApp.admin.Home I was/am under the impression that we already know the root classpath of our web application, you can initialize this value at webapp startup. > May I suggest we make [autolink] depreciated first instead of removing it as > both approaches don't seem to contradict Jon had the same thing in mind. > do you already have an idea on how to implement it? I guess it'll be on Page > level, right? I guess it'll have a cache to map found hrefs with classnames. > Stop: can not only be class name, what about images? Are we going to treat > *.html differently from everything else? Currently autolinks only work for HTML. I don't see why the new approach would be any differently. I think we *can* extend it to work for images but right now we should focus on replacing the preexisting behavior and not more. > will it support href in <head> like <link> as well? I am not familiar with <link>, please elaborate. > what about images which are referenced through hrefs. JSP apps use something > like "$contextPath/images/myimage.png". How will that fit with the absolute > href path mentioned above. How to know the resource is in $contextPath or in > /. And you need to know that in order to create the correct URL. There is nothing magic about this autolink implementation. Whatever decision is taken by your browser or DreamWeaver when rendering this page in a static manner, we'd be making the same decision. My guess is that if you refer to "/myImage.png" in your href, the browser will look at the root path of your server. Since our webapp is *not* mounted at the root, this will translate to some other path (outside the scope of our webapp). Again, this might change in the future if we begin to handle image links using automount, but right now we are simply interested in replacing the preexisting behavior. >Hmmm. I'm not convinced yet. I like it from a designer's perspective (not >having to use id="wicket-[autolink]"), >but really dislike it from a programmers perspective (implicit behaviour is >scary). Eelco, this is silly. With the old behavior, unless you explicitly convert them to autolinks, you will end up with broken links. It's not as if we're taking something that actually used to work and make it work unexpectedly. In fact, we are doing exactly the opposite: we are making the guarantee to the developer that any static link that used to work before will continue to work under Wicket. This is an important guarantee to make for the sake of previewability, if nothing else. >And one more thing. Say, you've got Home.html relative to your current >package, and you've got Home.html in your webapp directory. Is see a >problem here. and... >I have a Home.html in the root of the webapp and a Home component >This should be documented that this can't be done. (Correct me if I'm wrong) There is no concept of "your current package" or "component HTML". Autolink is concerns with one and only one thing: Pages. If you've got Home.html in your webapp directory and Home.html inside your component directory, we don't care about the component Home.html. Autolinks deal with pages, not components. When in doubt, always ask yourself: what would happen if this was a normal HTML link? Normal HTML links always refer to HTML pages, nothing else. Ok, I'm going to be gone for the next couple of hours. I'll answer any remaining questions then. Please keep in mind, the new implementation aims to do two things: - Act as much as normal HTML links as possible (for the sake of previewability and intuitiveness of the behavior). We don't want to surprise the user or DreamWeaver. By keeping the behavior consistent with normal HTML links, we guarantee they get what they expect. - Replace the preexisting autolink behavior. Yes, we might address links to images in the future, but the current implementation does not support this so nor does its replacement try to support it either. (Although I am pretty certain I know how we can add such behavior) Good day. Gili ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user