Igor, thanks for clarification. Is it possible to plug-in an own
"link-resolver", which manages the path-correction in the <wicket:link> area?
--
Best regards,
Thomas Singer
PS: I'm not THE SmartCVS/SVN guy - we are two, Marc Strapetz and me. But
unfortunately experience in developing desktop applications does not help
much with web applications.
Igor Vaynberg schrieb:
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="Index.html"> (1) and <a href="about/Index.html"> (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] <mailto:[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]>
>> <mailto: [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>
>>
>>
<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
>> Wicket-user@lists.sourceforge.net
<mailto:Wicket-user@lists.sourceforge.net>
>> <mailto: Wicket-user@lists.sourceforge.net
<mailto:Wicket-user@lists.sourceforge.net>>
>> 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
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642>
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
<mailto:Wicket-user@lists.sourceforge.net>
> 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
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642>
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
<mailto:Wicket-user@lists.sourceforge.net>
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
