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

Reply via email to