Our particular web application simply could not exist if wicket did not allow us to load markup from outside the jar. I think it's fine that the default is loading markup from the jar.
I our case we have a number of mechanisms by which more skilled end users can adjust markup so to force an app reload each time an end user does this would certainly place the policy of 'markup should be stored in the jar' outside the realms of best practice. >-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Monday, 7 June 2010 9:05 AM >To: [email protected]; John Krasnay >Subject: Re: Can I develop without recompiling/restarting after every >change? > >Hi > >>Yes, I understand that. But you have to put the markup for each >>component somewhere. If it's not on the classpath, then you will not be >>able to package that component into a JAR for re-use. > >As I wrote, both methods co-exist, and you can put markup on the >classpath and package it as jar while other markup is separate from >the classpath. How otherwise would I be able to use Wicket components >with my scheme? Please accept the good news that your "but" is not >justified. > >>No, we disagree because I think that "doing nothing", i.e. keeping your >>component markup on the classpath, *is* the best practice, that is, the >>majority opinion on what makes the most sense for most people. > >Quoting "majority opinion" and "community consensus" is a very weak >contribution to innovation, a sign that the speaker is running out of >genuine ideas. In such context I would typically say that my views >represent the other 100% of such perceived majority/consensus, just to >make it absolutely clear what kind of Orwellian bsht this is. > >Page developers, especially those who work with markup, and that is >the majority that Wicket is targeting (not component developers) need >the markup in the context of their resolvable image, script and other >resource files which is in the web directory. Otherwise they cannot >view the markup in the browser. They don't care where these files are >at runtime as long as they are not broken at design time which they >currently are. You never seem to comment on this critical point. > >> >>If you feel that the default approach isn't the best practice, then you >>are saying that the Wicket designers made a mistake by making this the >>default. I disagree strongly with that sentiment. > >You accept broken markup at design time and I don't accept it because >I have solved the problem. > >I would not go as far as to say they made THAT mistake. As you know, >they gave us the option. But the non-default option is broken because >of the missing three lines of Java code, and whenever people try it, >they become part of your perceived community consensus due to >frustration. Like prisoners. > >>I think perhaps we mean different things by "deploy on save". When I say >>"deploy" I mean it in the J2EE sense, where the container re-loads my >>WAR package. In my case, this re-loads my Spring context and a few dozen >>JPA entity beans, which takes up to 15 seconds on my relatively modern >>laptop. There is no way rearranging my markup (or running it on a "fully >>certified J2EE server") would turn this into milliseconds. > >True. "deploy on save" is not invented here. It is a term used in >IDEs. The IDE decides what deployment method to use depending on file >location etc.. That is one of two reasons why I would recommend to not >store page markup in Java package directories. > > >>Look, the only reason I took up this (now too long) thread is your use >>of the words "best practice", which implies a broadly held consensus. >>Now that you've included "as I see it" I'm happy to let it drop. > >Wrong. > >Best practice does not imply "broadly held consensus" at all. I am not >using this as a buzzword as you are. If I invent a better mouse trap >today that is more effective at delivering the outcome than any other >technique, while the better mouse trap is not even available or known >to everyone, then using it becomes best practice overnight. > >Regards > >Bernard > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
