Well, I guess I almost messed this one up :-) I had initially posted my Tapestry screenshots on Aug. 20th. However, since I had started blogging about it about a month earlier (on Aug 20th), when I posted the actual post, it posted with a July 20th date...
Geertjan mentioned that the project was about a month old and it might have updates, based on the posting date... So, in order not to give the false impression, I went back and updated the posting date to Aug. 20th.. Funny thing is, by then, the posting got picked up and sent out in the NetBeans weekly news newsletter.. and the link was broken... So, in order to fix the link for NetBeans users, I put it back to where originally was in the July entry . I will end up re-posting the same one at both places ( July entry , Aug entry ) to make sure all links are in place...
Damn, I am not used to being responsible and keeping the links to me constant.. :-) Nice and tickly feeling that someone might be interested in the things that I'm doing :-)
Tuesday, August 22, 2006
Sunday, August 20, 2006
Tapestry NetBeans Plugin
This is repost of my original post - since it was linked by Geertjan and NetBeans weekly news at two different URLs, here it goes...:
I've read up a bit on Tapestry and I've followed Geertjan's blog for quite a while now. I've been a NetBeans fan for quite a while now (since 3.5), and Geertjan's blog has been really eye opening in what is possible with NetBeans. So, a while back, he was really excited about Wicket, and he started working on a plugin for developing Wicket apps in NetBeans. It appears that in the last few months, with the help of Petr they've built quite a nice set up to support Wicket in NetBeans.
What that means about me is that I will try to do something similar, but with Tapestry. What I will try to do is to develop a plugin that will support Tapestry development in NetBeans. Geertjan has already done most of the work here as he has covered a lot of the topics that are required to build a nice web framework support plugin for NetBeans. At the same time, as he seems to point out in one of his latest entries, the information that is required to build such a plugin is either scattered all over the net (or the NetBeans.org site), or is in the source code for his Wicket support plugin . Now that I'm trying to organize my thoughts about this project better, I start noticing that he's also done a great job of documenting his work and his progress along the way. However, I guess giving it a second run wouldn't hurt anyone.
I will probably try to put up a post that would list the proposed features for such a plugin. However, the idea is that the plugin should make working with Tapestry easier, maybe even to the point of not having to know all the nitty-gritty details of exactly how Tapestry works. It should probably have all the nice features of the Wicket plugin, translated into the Tapestry world.
One thing that I've considered in the past is to dig into the Spindle project (which is an Eclipse Tapestry support plugin which has an Eclipse specific and an Eclipse agnostic part) and try to adapt it to work for NetBeans. Now, the thing is that part of my goals includes learning the NetBeans APIs along the way. So, while sometime down the road, looking into using the Spindle implementation and putting up a NetBeans frontend to it would make sense, it appears that for now it would make the most sense to see about implementing the basics in NetBeans only...
I will also probably post more details on the steps required to accomplish this; however, after a few hours of playing around with NetBeans, the tutorials on the site, Geertjan's tutorials, as well as the NetBeans APIs, I've put together the first few things for the plugin... Here are a couple of screenshots that just give me an enormous adrenaline rush...
First, a blank Tapestry project, set up and ready to go (I wish I knew how to do this a while back at work, as with both Tapestry and JSF/Facelets I've always kept referring to a sample project that I know it works when I've done new projects...):
Geertjan is probably going to laugh at this one as this is dirt simple to do, but damn, it is nice to be able t accomplish this.
The next one is showing how the Tapestry framework is added to the list of supported frameworks in a standard NetBeans web project. I admit right off the bat that I took all the code from the Wicket plugin and replaced all references to Wicket with references to Tapestry. I still need to remove some of the config options here that really have nothing to do with Tapestry, but this is a very nice start (I was initially having some trouble getting the framework support in - I spent a good number of hours until I found out exactly how to register the framework in the IDE).
The last one is a list of a couple of new file types added to a project. Most likely, I will have to restrict them to Tapestry projects only, but it's a nice start again. THere is more work to be done to maybe create a graphical customizer for a Tapestry page, but still.. I'm pumped.. :-)
I've read up a bit on Tapestry and I've followed Geertjan's blog for quite a while now. I've been a NetBeans fan for quite a while now (since 3.5), and Geertjan's blog has been really eye opening in what is possible with NetBeans. So, a while back, he was really excited about Wicket, and he started working on a plugin for developing Wicket apps in NetBeans. It appears that in the last few months, with the help of Petr they've built quite a nice set up to support Wicket in NetBeans.
What that means about me is that I will try to do something similar, but with Tapestry. What I will try to do is to develop a plugin that will support Tapestry development in NetBeans. Geertjan has already done most of the work here as he has covered a lot of the topics that are required to build a nice web framework support plugin for NetBeans. At the same time, as he seems to point out in one of his latest entries, the information that is required to build such a plugin is either scattered all over the net (or the NetBeans.org site), or is in the source code for his Wicket support plugin . Now that I'm trying to organize my thoughts about this project better, I start noticing that he's also done a great job of documenting his work and his progress along the way. However, I guess giving it a second run wouldn't hurt anyone.
I will probably try to put up a post that would list the proposed features for such a plugin. However, the idea is that the plugin should make working with Tapestry easier, maybe even to the point of not having to know all the nitty-gritty details of exactly how Tapestry works. It should probably have all the nice features of the Wicket plugin, translated into the Tapestry world.
One thing that I've considered in the past is to dig into the Spindle project (which is an Eclipse Tapestry support plugin which has an Eclipse specific and an Eclipse agnostic part) and try to adapt it to work for NetBeans. Now, the thing is that part of my goals includes learning the NetBeans APIs along the way. So, while sometime down the road, looking into using the Spindle implementation and putting up a NetBeans frontend to it would make sense, it appears that for now it would make the most sense to see about implementing the basics in NetBeans only...
I will also probably post more details on the steps required to accomplish this; however, after a few hours of playing around with NetBeans, the tutorials on the site, Geertjan's tutorials, as well as the NetBeans APIs, I've put together the first few things for the plugin... Here are a couple of screenshots that just give me an enormous adrenaline rush...
First, a blank Tapestry project, set up and ready to go (I wish I knew how to do this a while back at work, as with both Tapestry and JSF/Facelets I've always kept referring to a sample project that I know it works when I've done new projects...):
Geertjan is probably going to laugh at this one as this is dirt simple to do, but damn, it is nice to be able t accomplish this.
The next one is showing how the Tapestry framework is added to the list of supported frameworks in a standard NetBeans web project. I admit right off the bat that I took all the code from the Wicket plugin and replaced all references to Wicket with references to Tapestry. I still need to remove some of the config options here that really have nothing to do with Tapestry, but this is a very nice start (I was initially having some trouble getting the framework support in - I spent a good number of hours until I found out exactly how to register the framework in the IDE).
The last one is a list of a couple of new file types added to a project. Most likely, I will have to restrict them to Tapestry projects only, but it's a nice start again. THere is more work to be done to maybe create a graphical customizer for a Tapestry page, but still.. I'm pumped.. :-)
JVM scripting languages review
I've been playing around with groovy for the last couple of weeks and I have to say that I am intrigued by it. In the beginning, when I was starting to hear that there was a Groovy JSR that was aiming to create a standard Java scripting language, I was a bit skeptical : I've been using Jython for the last couple of years for the same puprose and so far it has been working out great for me. I already have a number of working application at work that are doing great. I even bought the "Jython for Java programmers" book a few years ago and it was an excellent guide in getting started. Additionally, in the last few months I've been getting back into the same book on the more advanced topics such as embedding jython in other applications (I even have a little prototype NetBeans plugin that is a live Jython interpeter, very nice in exploring the NetBeans APIs)
So, I said that Jython was generally working well for me for the same purpose. However, I did have a couple of things that bug me about it:
- Because Jython is an implementation of Python on top of a JVM, it is forced (or at least expected) to move at the same speed that python does. So, although Jython works pretty well for JVM scripting and and is generally feature complete, since it's a couple of releases behind Python proper, there is a lot of pressure to keep up with the language. Since one of the reasoning for using Jython is that you can either reuse python skills on the JVM, that really doesn't translate very well since Jython cannot use Python features implemented natively. Thus the "python skills transfer" thing doesn't really work.
- Although I really like the Python newline handling and indentation, it is kinda messed up that it's difficult to use python inside web pages or directly from the command line ('cause you have to maintain and respect the white space, which works great inside a regular script but it sucks when you try to do something like "jython 'for i in os.listdir("."):\n print i\n \n'"... which could have been so much better if there was another delimiter
- Because Jython has to implement the Python APIs, for a java developer to use Jython (e.g. because of the concise syntax or scripting features) he/she has to learn the totally new Python syntax and libraries (although Java most likely has equivalent APIs, using the Java APIs is not consice).
So, back to Groovy. I was initially a bit cynical, since Jython was really doing it for me (for the most part). I remember reading how the Groovy APIs were so unstable, and that it wasn't particularly catching on.. After all, I was a faithful Jython user.
So, one day I decided to give it a shot, and now, after reading about it, I am starting to really like it. For the most part, it appears to have all the goodness of Jython (e.g. concise map or list syntax, etc), however, without having to learn a totally new API. It enhances and improves Java and the JVM (e.g. Grails is really doing some really interesting things on top of Hibernate with GORM). It has a whole bunch of "best-of-breed" features taken from Ruby and Perl, without having to comply with a particular formal specification that isn't particularly Java related (e.g. such as the Python spec). It has Java-like syntax and delimiters and Java code could be used "as is" inside Groovy. Additionally, talking about syntax, it can be used nicely from the command like as in "groovy 'for i in [1,2,3] { print i }" - assuming that the for loop is correct.
All in all, so far Groovy has been really nice. I am really looking forward to the Groovy in Action book coming out so that I can dig more into it. The only thing that I really miss from Jython so far is the interactive console. I mean that Groovy that have a graphical groovy shell that can be used to execute Groovy statements, however, each statement is executed as a separate script and the results of the statements do not build up inside the script context (which might be easily fixable, but so far I don't know enough about it to fix it right off the bat).
So, I said that Jython was generally working well for me for the same purpose. However, I did have a couple of things that bug me about it:
- Because Jython is an implementation of Python on top of a JVM, it is forced (or at least expected) to move at the same speed that python does. So, although Jython works pretty well for JVM scripting and and is generally feature complete, since it's a couple of releases behind Python proper, there is a lot of pressure to keep up with the language. Since one of the reasoning for using Jython is that you can either reuse python skills on the JVM, that really doesn't translate very well since Jython cannot use Python features implemented natively. Thus the "python skills transfer" thing doesn't really work.
- Although I really like the Python newline handling and indentation, it is kinda messed up that it's difficult to use python inside web pages or directly from the command line ('cause you have to maintain and respect the white space, which works great inside a regular script but it sucks when you try to do something like "jython 'for i in os.listdir("."):\n print i\n \n'"... which could have been so much better if there was another delimiter
- Because Jython has to implement the Python APIs, for a java developer to use Jython (e.g. because of the concise syntax or scripting features) he/she has to learn the totally new Python syntax and libraries (although Java most likely has equivalent APIs, using the Java APIs is not consice).
So, back to Groovy. I was initially a bit cynical, since Jython was really doing it for me (for the most part). I remember reading how the Groovy APIs were so unstable, and that it wasn't particularly catching on.. After all, I was a faithful Jython user.
So, one day I decided to give it a shot, and now, after reading about it, I am starting to really like it. For the most part, it appears to have all the goodness of Jython (e.g. concise map or list syntax, etc), however, without having to learn a totally new API. It enhances and improves Java and the JVM (e.g. Grails is really doing some really interesting things on top of Hibernate with GORM). It has a whole bunch of "best-of-breed" features taken from Ruby and Perl, without having to comply with a particular formal specification that isn't particularly Java related (e.g. such as the Python spec). It has Java-like syntax and delimiters and Java code could be used "as is" inside Groovy. Additionally, talking about syntax, it can be used nicely from the command like as in "groovy 'for i in [1,2,3] { print i }" - assuming that the for loop is correct.
All in all, so far Groovy has been really nice. I am really looking forward to the Groovy in Action book coming out so that I can dig more into it. The only thing that I really miss from Jython so far is the interactive console. I mean that Groovy that have a graphical groovy shell that can be used to execute Groovy statements, however, each statement is executed as a separate script and the results of the statements do not build up inside the script context (which might be easily fixable, but so far I don't know enough about it to fix it right off the bat).
Subscribe to:
Posts (Atom)