ok i got the links figured out. this is a bit tricky so walk with me.

<wicket:link> resolves links /relative/ to the package of the current template
you have two links
<a href="" (1) and <a href="" (2)

when the index page loads wicket will resolve the links thus:

page package: com.foo.website.pages

1->com.foo.website.pages.Index
2->com.foo.website.pages.about.Index

this is correct

now when you hit the about page the following happens:

page package: com.foo.website.pages.about

1->com.foo.website.pages.about.Index
2->com.foo.website.pages.about.about.Index -> class does not exist -> markup unchanged

this is why on the about page the first link is disabled and the second one causes 404
it wouldve been easier to catch but because both pages were called Index it was confusing.

the problem is of course the relative nature of the <wicket:link> resolver. there is not much we can do about this. what you will have to do is to use PageLink components (which keep the full classname) in your template.

-Igor


On 3/2/06, Thomas Singer <[EMAIL PROTECTED]> wrote:
OK, you are right, having the PageTemplate class in a different package than
the Index class and having the PageTemplate.html in the same directory as
the Index.html markup is not that easy do achieve on deploying. Looks like
in my case I need to keep my IResourceStreamLocator instance for the
mapping. Or I move the PageTemplate class in the same package as the Index
class...

--
Best regards,
Thomas Singer


Thomas Singer schrieb:
> OK, at the moment I have code to find the markups in the pages/ dir, but
> it also should be possible to copy them into the packages while deploying.
>
> But does this solve the problems with the *links* shown in my example?
>
> --
> Best regards,
> Thomas Singer
>
>
> Igor Vaynberg schrieb:
>> still tricky
>>
>> notice that your Index.html is in pages dir and so is your
>> PageTemplate.html, but the corresponding classes are in two different
>> packages: com.foo.website.pages.Index.html and
>> com.foo.website.templates.PageTemplate so somehow you need to handle
>> that mapping. which you in fact can, you can say any class can look
>> for its template in pages dir, but then you have about/Index.html
>> mapped to com.foo.website.pages.about.Index.html which throws things off.
>>
>> you can setup alternative loading of resources but unless you want to
>> do some extensive mapping of your classes to template folders the
>> easiest approach is to mirror your package structure in your template
>> base dir structure.
>>
>> what you have to do is to implement your own IResourceStreamLocator
>> and add it to the resource settings. implementations of this interface
>> are responsible for figuring out where the html template is for a
>> given component and loading it.
>>
>> you can achieve any effect you want using this, but remember you dont
>> want to paint yourself into a corner so i would start simple and see
>> how far that carries you.
>>
>> -Igor
>>
>>
>>
>>
>> On 3/2/06, *Thomas Singer* <[EMAIL PROTECTED]
>> <mailto: [EMAIL PROTECTED]>> wrote:
>>
>>     Would it be possible for wicket to handle such a
>> after-deploy-structure
>>     without major head-aches:
>>
>>     +---graphics
>>     |       logo.gif
>>     |
>>     \---WEB-INF
>>          |   web.xml
>>          |
>>          +---classes
>>          |   +---com
>>          |   |   \---foo
>>          |   |       \---website
>>          |   |           |   FooWebApplication.class
>>          |   |           |   FooWebApplication$1.class
>>          |   |           |
>>          |   |           +---pages
>>          |   |           |   |   Index.class
>>          |   |           |   |
>>          |   |           |   \---about
>>          |   |           |           Index.class
>>          |   |           |
>>          |   |           \---templates
>>          |   |                   PageTemplate.class
>>          |   |
>>          |   \---pages
>>          |       |   Index.html
>>          |       |   PageTemplate.html
>>          |       |
>>          |       \---about
>>          |               Index.html
>>          |
>>          \---lib
>>                  commons-logging-1.0.4.jar
>>                  log4j-1.2.12.jar
>>                  wicket-1.2-20060227-0200-src.zip
>>                   wicket-1.2-20060227-0200.jar
>>
>>     and having the markup-files and images in the same directory
>>     structure at
>>     design-time?
>>
>>     --
>>     Best regards,
>>     Thomas Singer
>>
>>
>>     Johan Compagner schrieb:
>>      > if you don't want to make components for youre image or other
>>     resource tags.
>>      > Then the only thing i can think of is that you put all youre
>>     pages in
>>      > the doc root
>>      > and then all youre other stuff in images above that so
>>      >
>>      > Page.html
>>      > graphics/xxxx
>>      > style/xxxx
>>      >
>>      > The big problem with this at runtime is that youre wicket html
>>     pages are
>>      > also accessible through an url
>>      > just ask for /foo/Page.html
>>      >
>>      > So then they just have youre wicket page without the touching of
>>     wicket.
>>      >
>>      >
>>      > Also map youre wicket servlet not on /* but do it on /app/* or
>>     something
>>      > so that the doc root is not also served through wicket servlet.
>>     Thats a
>>      > waste.
>>      >
>>      > johan
>>
>>
>>
>>     -------------------------------------------------------
>>     This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>     language
>>     that extends applications into web and mobile media. Attend the live
>>     webcast
>>     and join the prime developer group breaking into this new coding
>>     territory!
>>
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>
>> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642>
>>
>>     _______________________________________________
>>     Wicket-user mailing list
>>     [email protected]
>>     <mailto: [email protected]>
>>     https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to