Usually when there seems to be concensus that something isn't possible, I get
triggered that there must be a simple solution. On the other hand if it's
considered to be 'simple' it usually gets out of hand. So I got triggered
and looked a bit further into this.
Providing you set things up
If you rename a package, then you have to do it in 2 places.
Martijn
On 1/29/07, nilo.de.roock [EMAIL PROTECTED] wrote:
Usually when there seems to be concensus that something isn't possible, I get
triggered that there must be a simple solution. On the other hand if it's
considered to be
I leave that to my refactoring tool. So it's not a problem.
- nilo
Martijn Dashorst wrote:
If you rename a package, then you have to do it in 2 places.
Martijn
On 1/29/07, nilo.de.roock [EMAIL PROTECTED] wrote:
Usually when there seems to be concensus that something isn't possible, I
ohh?
How does your refactoring tool know that?
That you rename a package for some java classes and that he also have to
rename
some resource directory somewhere also to that same thing?
johan
On 1/29/07, nilo.de.roock [EMAIL PROTECTED] wrote:
I leave that to my refactoring tool. So it's not
maybe if you setup that resource dir as a source dir in eclipse?
-igor
On 1/29/07, Johan Compagner [EMAIL PROTECTED] wrote:
ohh?
How does your refactoring tool know that?
That you rename a package for some java classes and that he also have to
rename
some resource directory somewhere also to
and?
How does eclipse know that there are 2 dirs somewhere (i guess in different
src dirs)
one for the html files and another for class files.
That they have the same structure and need to be in sync?
johan
On 1/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
maybe if you setup that resource
On 1/29/07, Johan Compagner [EMAIL PROTECTED] wrote:
and?
How does eclipse know that there are 2 dirs somewhere (i guess in
different src dirs)
you set it up in project properties
one for the html files and another for class files.
That they have the same structure and need to be in sync?
It is possible that this is a simple misunderstanding. I know that when I
first read the post regarding the renaming of packages, I had the same
response as the poster that my IDE would take care of fixing the places that
changed. But, after reading the subsequent posts, I see that Johan is
We advise you to not do this until you are absolutely sure you need
it, especially as a newbie to the framework. Obvious reasons are not
so obvious in a Wicket context.
- packaging your components in a jar
- having to mimick the package/directory structure
- looking up your HTML (which is
yes, all newbies start to do this and eventually go back, but oh well
if you still want to shoot yourself in the foot what you do is this:
implement IResourceStreamLocator and make it take a delegate
then in your app's init do this
application.init() {
MyResourceStreamLocator locator=new
And there is an example of it in Wicket-examples called 'custom
template loading'. But yes, it is recommended to use the defaults
instead; that auto discovery pattern is there to save you precious
development time, make things easier to look up (at least for
developers) and to make packaging
Hi,
... Wicket allows you to easily customize this default behavior though.
...
NOT! ( Why did he write that anyway? Perhaps as an excuse. He might have
considered it a design error. It is dirty, a bit. ) I hope the rest of the
book has better advice.
I'll leave the .html and .java mixed up in
12 matches
Mail list logo
