Re: Status of Wicket and Groovy?
Hi Eelco (and others), Thanks for your post. On 09/06/2008, at 11:37 AM, Eelco Hillenius wrote: I don't know about Django, but I think Wicket comes with quite a number of reusable components. And as I believe that you typically want to customize components for your own use anyway, I think it is more important that it is easy to create them than to have them readily available. Anyway, are there any components you miss that e.g. Django has but Wicket hasn't? Sorry, I used the wrong term there. I didn't mean specifically components as in parts of a dynamic Web page but rather what Django calls applications (which really are components in the more general sense of the word - how's that for confusing ;-). Django Web applications can be composed of a number of (smaller) applications (basically another subdirectory in the site directory). AFAIK, these can be complete high-level functionality (e.g. email- confirmation for registration, surveys, feeds etc). I guess these could be done with Wicket add-on frameworks (i.e. JARs) but I just don't see that many (please correct me if I am wrong) at this level. Also, I can't see a high-level automatic and customisable admin/CRUD interface for Wicket like there is for Django. I think being able to pull together this sort of functionality quickly into an application (i.e. reuse) and customise it is very handy - saves re-inventing the wheel. Whether this is a result of Django being based on Python and interpreted I am not sure. Please don't misunderstand me, I am not criticising Wicket - I think it is fantastic, I'm just trying to understand why it may / needs to lack the RAD and large-scale functionality reuse that something like Django seems to provide. I don't agree with the classification. That whole article (http://en.wikipedia.org/wiki/Web_application_framework) isn't very well written imho. I made this comment on the wiki-talk page: == Push vs Pull should go == I've seen these terms - push and pull - used before in discussions, but not everyone agrees on what they mean. Sure, I agree there is some vagueness in these terms and I agree they have little to do with component vs. non-component based Web frameworks. But I do think there is a push vs. pull distinction (although some frameworks as you say can be push and pull). Push to me are request-oriented or (type 2) controller-driven frameworks, e.g. where the URL drives a controller which produces the page. These type of applications also seem to make it clear that you are getting a request object and have to return a response object. In Django, for example, (like I believe happens in Struts) you map out which URL patterns will match to which functions, and then the functions are sent the request and return a response object (usually produced by filling in a template in a context). Pull, on the other-hand, to me are more page-driven Web frameworks, e.g. where the main page loads and there you go from page to page. These type of applications seems to, generally, let you work at a higher level of abstraction than request-response. Of course, there is a request-response cycle going on lower down, that one can get to if you wish, but generally speaking developers work at a higher level. Wicket I think, like WebObjects and a lot of other frameworks work at this level. A quick Google showed me that some work has been done with Groovy (wicket-contrib-groovy) and the WicketBuilder by Kevin Galligan. However, Kevin seems to have moved on to Seam and wicket-contrib-groovy seems to be no longer supported. I couldn't find that he moved on, but it is possible the project isn't maintained anymore. He has confirmed to me via email that he has moved to using Seam. His implementation used named closures and he mentioned (as another poster has indicated) that he had to do various hacks to serialise the closures and make it all work. I think it was more of a proof-of- concept than anything else. That said, I think the *brevity and structure* of the Groovy code that he was able to use (in the pages I linked to) was really something significant. That with the ability to have a more RAD approach was very appealing (to me at least). You could take a look at the integration that Grails has for Wicket. That will let you use Groovy with Wicket, but also provides a RoR-like rad framework. I will have another look but from what I understand Grails is like Django / RoRs another push Web framework that focuses on mapping URLs to controller methods. From what I see, the Wicket integration either requires you to use Java or extras classes in Groovy. Personally I still think there is room for a Web framework that is: + fully component-based, + pull-oriented (but allowing push for when it is useful), + full separation between HTML and application (like Wicket does), and allows one to use
Re: Status of Wicket and Groovy?
Sorry, I used the wrong term there. I didn't mean specifically components as in parts of a dynamic Web page but rather what Django calls applications (which really are components in the more general sense of the word - how's that for confusing ;-). Django Web applications can be composed of a number of (smaller) applications (basically another subdirectory in the site directory). AFAIK, these can be complete high-level functionality (e.g. email-confirmation for registration, surveys, feeds etc). Actually, you can build such 'applications' as components in Wicket. That's the beauty of the fact that Wicket's components are truly self contained. State, navigation, you name it, everything can be put in components and it doesn't leak to outside unless you design it that way. Develop a registration component, survey component, feeds component and put it in any page, together with any combination of components you want. This is t h e w h o l e i d e a with Wicket's components :-) I guess these could be done with Wicket add-on frameworks (i.e. JARs) but I just don't see that many (please correct me if I am wrong) at this level. If there's any framework that let's you develop mini-applications seamlessly, it's Wicket. The availability of such components is another matter. Also, I can't see a high-level automatic and customisable admin/CRUD interface for Wicket like there is for Django. Not sure what you're looking for, but something like http://wicketwebbeans.sourceforge.net/ or http://sourceforge.net/projects/wicket-rad? Please don't misunderstand me, I am not criticising Wicket - I think it is fantastic, I'm just trying to understand why it may / needs to lack the RAD and large-scale functionality reuse that something like Django seems to provide. I really think it's just a matter of what we want to focus on. With 'we' I mean the core team and community here that works on Wicket. I don't know Django well, but RoR for instance is very focussed on the RAD part. Wicket doesn't aim to be a RAD development framework, but instead provides a framework that is extensible so you or other people can build stuff like that on top of it. Personally I believe that RAD stuff is nice to score projects and show some quick results, but I care way way more about the longer term. If I can scale a development team and if the project still is easy to get around in and refactor half a year down the line. Push to me are request-oriented or (type 2) controller-driven frameworks, e.g. where the URL drives a controller which produces the page. I don't want to be blunt, but I just think that the push-pull classification is too vague and arbitrary to be in that WIKI article. In this case, it's perfectly fine to speak about for instance 'front controller'/ 'web mvc' or 'model 2' (which is kinda the official term Sun gave it a long time ago) frameworks rather than pull-push. The way I've seen pull-push being used in the context of discussions about frameworks, it always referred to model 2 frameworks and more importantly to frameworks that allow some scripting in templates, and in that case, 'pull' refers to lazy evaluation whereas 'push' means everything has to be calculated up-front. The only somewhat agreeable piece on this - imho - is http://www.antlr.org/wiki/display/ST/Introduction. But imho, the pull vs push thing is relevant for a framework like Wicket (or GWT or Echo for that matter). I couldn't find that he moved on, but it is possible the project isn't maintained anymore. He has confirmed to me via email that he has moved to using Seam. Ok. Seam with JSF, or Seam with Wicket? Seam ships with Wicket support nowadays :-) I will have another look but from what I understand Grails is like Django / RoRs another push Web framework that focuses on mapping URLs to controller methods. From what I see, the Wicket integration either requires you to use Java or extras classes in Groovy. I really don't know enough about Grails to say :-) You could check with them. Personally I still think there is room for a Web framework that is: + fully component-based, + pull-oriented (but allowing push for when it is useful), + full separation between HTML and application (like Wicket does), and allows one to use a dynamic language (for RAD). Something based on Groovy (because of its close ties to Java) and Wicket (because of its great approach and separation) would be very elegant and powerful. I think it is a matter of building on a framework like Wicket. Why start over again? The whole idea of components is that you make something more complex out of simpler parts. And there's really no end to what you can do with that (within the confines of web applications obviously). Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
Hi again Eeclo (et al.), Thanks for taking the time to discuss this. On 10/06/2008, at 4:50 PM, Eelco Hillenius wrote: Sorry, I used the wrong term there. I didn't mean specifically components as in parts of a dynamic Web page but rather what Django calls applications (which really are components in the more general sense of the word - how's that for confusing ;-). Django Web applications can be composed of a number of (smaller) applications (basically another subdirectory in the site directory). AFAIK, these can be complete high-level functionality (e.g. email- confirmation for registration, surveys, feeds etc). Actually, you can build such 'applications' as components in Wicket. That's the beauty of the fact that Wicket's components are truly self contained. State, navigation, you name it, everything can be put in components and it doesn't leak to outside unless you design it that way. Develop a registration component, survey component, feeds component and put it in any page, together with any combination of components you want. Ok, I understand the OO nature of components in Wicket but I guess I will have to stop thinking of them as independent snippet level components. If there's any framework that let's you develop mini-applications seamlessly, it's Wicket. If one can easily build a group of components that will appear on different pages and work together collaboratively as a whole functional unit that's great. The availability of such components is another matter. Yes, I (honestly) wonder though why more higher-level components are not available? You suggest it is not technical. Also, I can't see a high-level automatic and customisable admin/CRUD interface for Wicket like there is for Django. Not sure what you're looking for, but something like http://wicketwebbeans.sourceforge.net/ or http://sourceforge.net/projects/wicket-rad? I've read a bit about them and will check them out further. I don't believe they handle relationships (to-one and to-many) between entities though? Please don't misunderstand me, I am not criticising Wicket - I think it is fantastic, I'm just trying to understand why it may / needs to lack the RAD and large-scale functionality reuse that something like Django seems to provide. I really think it's just a matter of what we want to focus on. With 'we' I mean the core team and community here that works on Wicket. I don't know Django well, but RoR for instance is very focussed on the RAD part. Wicket doesn't aim to be a RAD development framework, but instead provides a framework that is extensible so you or other people can build stuff like that on top of it. Personally I believe that RAD stuff is nice to score projects and show some quick results, but I care way way more about the longer term. If I can scale a development team and if the project still is easy to get around in and refactor half a year down the line. Yes, I understand and agree. However, the project I am doing now is relatively small and simple and not Enterprise class hence I am looking for an easy and RAD solution. Push to me are request-oriented or (type 2) controller-driven frameworks, e.g. where the URL drives a controller which produces the page. I don't want to be blunt, but I just think that the push-pull classification is too vague and arbitrary to be in that WIKI article. Ok, that's fine. In this case, it's perfectly fine to speak about for instance 'front controller'/ 'web mvc' or 'model 2' (which is kinda the official term Sun gave it a long time ago) frameworks rather than pull-push. Yes, that is what I (and I think the Wikipedia page) mean by push and the other approach (like Wicket) is pull. The way I've seen pull-push being used in the context of discussions about frameworks, it always referred to model 2 frameworks and more importantly to frameworks that allow some scripting in templates, and in that case, 'pull' refers to lazy evaluation whereas 'push' means everything has to be calculated up-front. The only somewhat agreeable piece on this - imho - is http://www.antlr.org/wiki/display/ST/Introduction. But imho, the pull vs push thing is relevant for a framework like Wicket (or GWT or Echo for that matter). That's an interesting article but I think we have two different uses of the terms push and pull (at least that is how I see it). I couldn't find that he moved on, but it is possible the project isn't maintained anymore. He has confirmed to me via email that he has moved to using Seam. Ok. Seam with JSF, or Seam with Wicket? Seam ships with Wicket support nowadays :-) That very interesting, I will check it out. Personally I still think there is room for a Web framework that is: + fully component-based, + pull-oriented (but allowing push for when it is useful), + full separation between HTML and application (like Wicket does), and allows one to use a dynamic language
Re: Status of Wicket and Groovy?
If there's any framework that let's you develop mini-applications seamlessly, it's Wicket. If one can easily build a group of components that will appear on different pages and work together collaboratively as a whole functional unit that's great. You certainly can, it's all a matter of designing these components well. Again, I don't know much about Django, so I can't really compare. The availability of such components is another matter. Yes, I (honestly) wonder though why more higher-level components are not available? You suggest it is not technical. I think - certainly speaking from my situation - that it is easier and quicker with Wicket to develop components exactly for your needs instead of depending on more generic ones. Especially domain specific components can be hard to develop in such a way that they are helpful for a great number of cases (great enough to justify the extra effort of developing such components generically), and their API might get so complex that it is hardly worth the effort. That's what I think at least. But in the end, it's just a matter of someone picking up the task to develop things like survey components etc. Also, I can't see a high-level automatic and customisable admin/CRUD interface for Wicket like there is for Django. Not sure what you're looking for, but something like http://wicketwebbeans.sourceforge.net/ or http://sourceforge.net/projects/wicket-rad? I've read a bit about them and will check them out further. I don't believe they handle relationships (to-one and to-many) between entities though? No idea. Yes, I understand and agree. However, the project I am doing now is relatively small and simple and not Enterprise class hence I am looking for an easy and RAD solution. You might be better off using a framework that focussed on that. There nothing wrong with using different frameworks for different purposes if you ask me :-) Unfortunately, although there has been some discussion of serialising closures on the Groovy mailing lists but I don't believe anything has been done about it. Too bad. Well, a single person can make all the difference in the world :-) I think I will just stick with plain Java Wicket or Django for the time being. Sounds good. Good luck with your project. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
On Monday 09 June 2008 10:47:45 Eelco Hillenius wrote: IMHO they cannot be easily used together at the moment. Hmmm, interesting. My only experience with Groovy is years ago, and back then we abandoned and switched to PNuts (which I guess should work with Wicket as well) due to Groovy's immaturity back then. Dima, are these problems hard to overcome in your opinion? And did you look at other dynamic languages with Wicket by any chance? I wouldn't say the problems are hard but they are not easy either. When I attempted to implement some kind of my own wicketbuilder, the problems boiled down to making closures serializable and creating wrappers for wicket classes to make them use closures instead of anonymous classes. Unfortunately I switched from it to other things. I haven't looked at other dynamic languages. May be I should try jruby. Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
On Mon, Jun 9, 2008 at 1:38 AM, Dmitry Kandalov [EMAIL PROTECTED] wrote: I like the idea of using groovy and in general using dynamic language would be interesting indeed. But I think you might be not 100% correct about using groovy as it is. The main problem in my view is the lack of anonymous classes in groovy which are widely used by wicket. Anonymous classes aren't needed in Groovy. In Groovy, you have closures. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
Anonymous classes aren't needed in Groovy. In Groovy, you have closures. Dmitry hinted in his reply that closures can't be serialized by default... Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
Yeah, I read that later in the thread. Oops! :) On Mon, Jun 9, 2008 at 12:09 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Anonymous classes aren't needed in Groovy. In Groovy, you have closures. Dmitry hinted in his reply that closures can't be serialized by default... Eelco - 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]
Re: Status of Wicket and Groovy?
I started working on the builder a wee back, and intend on bringing it up to spec. The only work I had done so far was making it compile compatible with Wicket 1.3 and cleaning up the Maven stuff. I forked it to github here: http://github.com/astubbs/wicket-contrib-groovy/commits/wicket1.3Compilecompat I may have forgotten to commit my latest changes... Let me know if you have any problems cloning or viewing the site. Eelco Hillenius wrote: A quick Google showed me that some work has been done with Groovy (wicket-contrib-groovy) and the WicketBuilder by Kevin Galligan. However, Kevin seems to have moved on to Seam and wicket-contrib-groovy seems to be no longer supported. I couldn't find that he moved on, but it is possible the project isn't maintained anymore. However, the integration is pretty simple to achieve, and it might even be best for your case to build a set of utilities (as that's pretty much what you need to make the integration work if I understand it correctly) that suit your needs. - ___ http://stubbisms.wordpress.com http://stubbisms.wordpress.com -- View this message in context: http://www.nabble.com/Status-of-Wicket-and-Groovy--tp17710986p17745477.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
Ah yes - It was committed, but the first comment line didn't summarise the commit. This is the big commit: Author: Antony Stubbs [EMAIL PROTECTED](none) 2008-03-20 17:24:53 Committer: Antony Stubbs [EMAIL PROTECTED](none) 2008-03-20 17:24:53 Parent: e7d957ba2dd793898dae1828e1c683bb7635db76 (updated wicket dependency) Child: bd620b84e0f99b27e2d68ac51fbfdfd18fe1866a (removed duplicate classpath) Branches: remotes/origin/wicket1.3Compilecompat, wicket1.3Compilecompat Follows: Precedes: Changed maven module layout to make more sense - renamed module dirs to match module names Changed import and other wicket references to match org.apache.wicket package name Using with 0.9 version of m2elcipse plugin Updated version of wicket dependency Got rid of repeated info from poms Signed-off-by: Antony Stubbs [EMAIL PROTECTED] Antony Stubbs wrote: I started working on the builder a wee back, and intend on bringing it up to spec. The only work I had done so far was making it compile compatible with Wicket 1.3 and cleaning up the Maven stuff. I forked it to github here: http://github.com/astubbs/wicket-contrib-groovy/commits/wicket1.3Compilecompat I may have forgotten to commit my latest changes... Let me know if you have any problems cloning or viewing the site. Eelco Hillenius wrote: A quick Google showed me that some work has been done with Groovy (wicket-contrib-groovy) and the WicketBuilder by Kevin Galligan. However, Kevin seems to have moved on to Seam and wicket-contrib-groovy seems to be no longer supported. I couldn't find that he moved on, but it is possible the project isn't maintained anymore. However, the integration is pretty simple to achieve, and it might even be best for your case to build a set of utilities (as that's pretty much what you need to make the integration work if I understand it correctly) that suit your needs. - ___ http://stubbisms.wordpress.com http://stubbisms.wordpress.com -- View this message in context: http://www.nabble.com/Status-of-Wicket-and-Groovy--tp17710986p17745525.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
I know Wicket makes it very easy to develop components and there are some component libraries (e.g. Wicket Stuff) but it doesn't seem like there are as many (high level components) as Django or that they are as easy to integrate (that's just my perception). I don't know about Django, but I think Wicket comes with quite a number of reusable components. And as I believe that you typically want to customize components for your own use anyway, I think it is more important that it is easy to create them than to have them readily available. Anyway, are there any components you miss that e.g. Django has but Wicket hasn't? So when I was looking at the Wikipedia comparison on Web frameworks I noticed something. There doesn't seem to be a pull (component-based) Web framework that uses a dynamic programming language (like Groovy, Ruby or Python). Grok seems too left field. Django, RoR and Grails are all push (request-based) Web frameworks and, as I mentioned above, use template languages to varying degrees. So I was thinking a pull (component-based) Web framework like Wicket but using a dynamic language could be a great move. I don't agree with the classification. That whole article (http://en.wikipedia.org/wiki/Web_application_framework) isn't very well written imho. I made this comment on the wiki-talk page: == Push vs Pull should go == I've seen these terms - push and pull - used before in discussions, but not everyone agrees on what they mean. I certainly don't. With Velocity for instance, you need to 'push' something in the context before you can use it, but after that, the object and everything it references is available for whatever operation, which is more of a pull. In fact, Velocity tools are purely 'pull'. Also, Struts is being classified as a push framework, and Velocity as pull, but you can use Velocity as a view layer of Struts. Whether a framework is 'component oriented' has absolutely nothing to do with whether it is push or pull, but rather with the ability to break up functionality on 'pages' into smaller, independent 'components'. Finally, the reference that is used for the push vs pull explanation is a public forum; the opinions of a few random people of that site hardly justifies being referenced to here. That article would be much better without the whole push vs pull thing. A quick Google showed me that some work has been done with Groovy (wicket-contrib-groovy) and the WicketBuilder by Kevin Galligan. However, Kevin seems to have moved on to Seam and wicket-contrib-groovy seems to be no longer supported. I couldn't find that he moved on, but it is possible the project isn't maintained anymore. However, the integration is pretty simple to achieve, and it might even be best for your case to build a set of utilities (as that's pretty much what you need to make the integration work if I understand it correctly) that suit your needs. So what do people think about Groovy and Wicket? I think you should be able to use Groovy just fine if you want. And other dynamic languages should work as well as long as they run on the JVM and can cooperate with regular Java classes. You could take a look at the integration that Grails has for Wicket. That will let you use Groovy with Wicket, but also provides a RoR-like rad framework. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
On Saturday 07 June 2008 22:09:02 Ashley Aitken wrote: So my question is: what is the status (now and going forward) with regards to using Groovy to develop with Wicket? I know there has been much discussion of generifying Wicket but perhaps moving to a dynamic language could be an alternative future. Of course, using Groovy with Wicket wouldn't require the framework itself to be implemented in Groovy or even that everyone uses Groovy. And, as you all probably know Groovy can easily call an Java class library. I like the idea of using groovy and in general using dynamic language would be interesting indeed. But I think you might be not 100% correct about using groovy as it is. The main problem in my view is the lack of anonymous classes in groovy which are widely used by wicket. I wrote a little bit more about it a while ago here http://www.nabble.com/Feedback-on-proposed-Groovy-DSL-syntax-for-Wicket-tt15873183.html So what do people think about Groovy and Wicket? IMHO they cannot be easily used together at the moment. Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of Wicket and Groovy?
IMHO they cannot be easily used together at the moment. Hmmm, interesting. My only experience with Groovy is years ago, and back then we abandoned and switched to PNuts (which I guess should work with Wicket as well) due to Groovy's immaturity back then. Dima, are these problems hard to overcome in your opinion? And did you look at other dynamic languages with Wicket by any chance? Ashley, what do you think of Scala? It's a statically typed language, so it may not be what you're looking for, but it has the potential of making a lot of Wicket code much shorter. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Status of Wicket and Groovy?
Howdy All, There's a question at the end of this long intro: I've been evaluating and comparing a number of Web frameworks again, particularly at this time Wicket (which I have looked at previously and tried out) and Django (which I am new to but comes highly recommended). I very much like the way Wicket has a complete (yes, I think complete is a good description) separation of the (X)HTML and Java code. It's fantastic when you want graphic designers to design the pages (with dummy data as well). I'm over the idea of using a complex template language, even the simplified (presentation only) template language used in Django (so I don't wish to go near JSF and I'm even a little negative on Tapestry which has a similar minimal template language). Django on the other hand use the dynamic language Python which makes writing apps easier (and shorter). It also seems to make it very easy to create more powerful applications by combining smaller applications (e.g. it includes a powerful automatic CRUD interface). I know Wicket makes it very easy to develop components and there are some component libraries (e.g. Wicket Stuff) but it doesn't seem like there are as many (high level components) as Django or that they are as easy to integrate (that's just my perception). So when I was looking at the Wikipedia comparison on Web frameworks I noticed something. There doesn't seem to be a pull (component-based) Web framework that uses a dynamic programming language (like Groovy, Ruby or Python). Grok seems too left field. Django, RoR and Grails are all push (request-based) Web frameworks and, as I mentioned above, use template languages to varying degrees. So I was thinking a pull (component-based) Web framework like Wicket but using a dynamic language could be a great move. A quick Google showed me that some work has been done with Groovy (wicket-contrib-groovy) and the WicketBuilder by Kevin Galligan. However, Kevin seems to have moved on to Seam and wicket-contrib- groovy seems to be no longer supported. From what I saw of WicketBuilder it seems it has a lot of potential to make Wicket development more dynamic (with the GroovyClassResolver), reduce the code required to write Wicket applications, and even make them clearer with no overhead when deployed. So my question is: what is the status (now and going forward) with regards to using Groovy to develop with Wicket? I know there has been much discussion of generifying Wicket but perhaps moving to a dynamic language could be an alternative future. Of course, using Groovy with Wicket wouldn't require the framework itself to be implemented in Groovy or even that everyone uses Groovy. And, as you all probably know Groovy can easily call an Java class library. So what do people think about Groovy and Wicket? Cheers, Ashley. Some relevant URLs: http://wicketstuff.org/confluence/display/STUFFWIKI/WicketBuilder http://www.kgalligan.com/wicketgroovy-setup http://www.kgalligan.com/wicketgroovy-simplepage http://bigheadco.blogspot.com/2007/03/wicket-and-groovy.html http://people.byte-code.com/dpanelli/2008/02/04/groovy-wicket/ -- Ashley Aitken 04 1226-8159 (Mb) 08 9368-5505 (Ph) Perth, Western Australia Skype/iChat: MrHatken (GMT + 8hrs!) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
