It's just interesting... Shale is a pretty high profile apache project and it's probably more than a year old... Looking at the shale project site, the majority of the packages and pieces of shale are still not co sidered production quality with most of the api-s not considered stable. Now, looking st what shale has to offer, and considering my experience (and a partial disappointment) with jsf, i do believe that shale will be açcepted very well, because just like struts proper it will offer a bunch of useful abstractions and utilities on top of the standard that would make it useful and popular. So, here is the paradox: there are smart and experienced people who are working on the project, probably all of them see the usefullness of what shale could be.... And ýet, for such a long time, the project has not released a stable version. On one hand I understand that having ¨struts¨ in the of the project does bring a lot of responsibility and baggage and there might be a desire to get everything to be perfect or at least excellent when 1.0 is released. On the other hand, i understand that it is an open source project and it largely depends on volunteer contributions of time and effort ( and thus, instead of blogging i probably should be reading and writing code for shale). On the other hand, it seems to me that is doesn't have to be perfect for 1.0 - it just has to be goood enough in order to be useful to a lot of people and then with usage it will start to get exponentially better....
so, my question still is : why isn't there a struts shale 1.0 yet??
Saturday, May 13, 2006
Kudos to Jacob Hookom
A number of years ago while I was still in college.. one of my cool professors was raving about some guy who managed to connect to his cell phone from his home machine in some very sneaky and cool way.. So, my professor's comment was something like "Well, some people might say, who the hell cares about somebody connecting to a cell phone... But damn, it makes me sleep well at night when I know this kind of people are out there.. "...
So, the connection to JHook... He's the lead of the Facelets project.. and he is involved with the JSF spec committee.. He's coming up with these great ideas about web applications, components, JSF, Ajax + JSF... stuff like that.. Reading his blog is just a pleasure.. and it constantly makes me think "Thank god people like him are out there..."...
So, the connection to JHook... He's the lead of the Facelets project.. and he is involved with the JSF spec committee.. He's coming up with these great ideas about web applications, components, JSF, Ajax + JSF... stuff like that.. Reading his blog is just a pleasure.. and it constantly makes me think "Thank god people like him are out there..."...
Wicket review
A couple of weeks ago i spent a couple of hours reading up on wicket. I have to say i was quite intrigued by some posts that one of my favorite bloggers had posted ( geertjan ). He was quite ecstatic about how easy it is quite easy to develop in wiçket. Alright, i thought, let me see what it is all about.
So, i sat down and went through what i thought was almost all documentation that i could get my hands on during those few hours. I do agree that it manages to take away a lot of the complexity that is inherent to web app development - e.g. No need to deal with http requests and responses, no sessions, nothing of the sort. The development model is very similar to a swing ui development model - you just work with objects, add listeners, process events...pretty sweet feeling. All in all for a fairly small learning curve ( especially if one is already familiar with swing development), you get a fairly straightforward way to develop a web app. It turned out that the way that is possible by keeping everything in the session. Now, my first reaction ( well indoctrinated in good j2ee dev practices :-) ) was to pull back and think that something is not quite right... However, after´some further consideration... Hey, why not??? After all it is a stateful web dev framework, the state has to be preserved somwhere... Sure it's new and might have not been tested for scalability over thousands of users.. but then, for 90-some percent of the apps out there, there are a few users here and there, and really it doesn't require scalability up to thousands of users...
The templating capabilities seemed to be pretty cool as well, as you could nest and compose templates from other components up to an arbitrary depth. The templating sysstem seemed to be pretty straightforward as well, kinda similar to the facelets or the tapestry templating. So, that was nice too...
So, all in all I liked what I saw. On the other hand, I do have a strong preference for using whatever is "standard" in the particular space (or at least 2nd most popular). In light of that, although Wicket seemed to be offering a couple of interesting design options, it's far from being popular or have a large user community. Now, one of the reasons that I was actually looking at Wicket was because of the problems that I had previously with using JSF (e.g. had some problems with event handling on request-scoped components or with components inside a dataTable - both of which turned out to be well known problems with the reference implementation). In light of that, if one put everything in session scope in a JSF project,then that would solve all of the difficulties that I was having with JSF as well. Additionally, there is pretty decent support for developing with JSF (e.g. IDEs, books, etc), which wasn't really there for Wicket. Finally, it seems to me that although when you work with Wicket, often times you might not have to even touch any html, it seems to me that when I do web development, sooner or later I would have to deal with html.
Luckily, at my job, I pretty much have choice of what framework or approach to use in developing the next application. Thus, I really don't have to learn any framework or approach that I don't think would be useful in the future or wouldn't be a good investment of time from all points of view. So, from the easiness point of view, Wicket does have a lot to offer. However, at this point, at least for me, from a "future investment" point of view, I think that investing more time into JSF would be more valuable.
So, i sat down and went through what i thought was almost all documentation that i could get my hands on during those few hours. I do agree that it manages to take away a lot of the complexity that is inherent to web app development - e.g. No need to deal with http requests and responses, no sessions, nothing of the sort. The development model is very similar to a swing ui development model - you just work with objects, add listeners, process events...pretty sweet feeling. All in all for a fairly small learning curve ( especially if one is already familiar with swing development), you get a fairly straightforward way to develop a web app. It turned out that the way that is possible by keeping everything in the session. Now, my first reaction ( well indoctrinated in good j2ee dev practices :-) ) was to pull back and think that something is not quite right... However, after´some further consideration... Hey, why not??? After all it is a stateful web dev framework, the state has to be preserved somwhere... Sure it's new and might have not been tested for scalability over thousands of users.. but then, for 90-some percent of the apps out there, there are a few users here and there, and really it doesn't require scalability up to thousands of users...
The templating capabilities seemed to be pretty cool as well, as you could nest and compose templates from other components up to an arbitrary depth. The templating sysstem seemed to be pretty straightforward as well, kinda similar to the facelets or the tapestry templating. So, that was nice too...
So, all in all I liked what I saw. On the other hand, I do have a strong preference for using whatever is "standard" in the particular space (or at least 2nd most popular). In light of that, although Wicket seemed to be offering a couple of interesting design options, it's far from being popular or have a large user community. Now, one of the reasons that I was actually looking at Wicket was because of the problems that I had previously with using JSF (e.g. had some problems with event handling on request-scoped components or with components inside a dataTable - both of which turned out to be well known problems with the reference implementation). In light of that, if one put everything in session scope in a JSF project,then that would solve all of the difficulties that I was having with JSF as well. Additionally, there is pretty decent support for developing with JSF (e.g. IDEs, books, etc), which wasn't really there for Wicket. Finally, it seems to me that although when you work with Wicket, often times you might not have to even touch any html, it seems to me that when I do web development, sooner or later I would have to deal with html.
Luckily, at my job, I pretty much have choice of what framework or approach to use in developing the next application. Thus, I really don't have to learn any framework or approach that I don't think would be useful in the future or wouldn't be a good investment of time from all points of view. So, from the easiness point of view, Wicket does have a lot to offer. However, at this point, at least for me, from a "future investment" point of view, I think that investing more time into JSF would be more valuable.
JSF early adopter...
I know that I am not too early in the adoption cycle for JSF.. but it's funny, cause it feels that way.. I mean that I learned struts when it was already quite popular (although I think a little before it peaked in popularity), and there were already a good number of books, tutorials, etc. Not with JSF - there are a lot resources on how to do stuff, however, there is no "definitive" best practices that have existed with Struts in a while.. and so many different things just kinda seem half baked in JSF.. I mean, I understand that it was designed to have "tool support" and so on.. but really, there needs to be a package (e.g. maybe Shale) that would provide a layer on top of JSF that resolves the trivial and middle-of-the road problems in a nice way, just like Struts did the same for servlet programming.. I mean, before Struts, everyone was hacking out their own little solutions, and had their own way of dealing with http requests and responses, form submissions, validations, etc.. and now with JSF, there are a couple of different ways to solve the same problem..
Here is an example - dealing with row selection in an h:dataTable :
1. One possible way to solve it is to write a custom component, just like ibm did in this explanation . But really, how many people who don't use WebSphere would actually sit down and write their own component for that (especially considering that JSF components are notoriously difficult to do.
2. There was another post on the Sun JSF forums, where none other than CraigMcc responded to a question on how to do it (took a bit of digging
* Option#1 was to have a bolean property in the actual bean that you're iterating over, to indicate that the bean was selected. That is not very pleasant to use, as first, you might have to wrap your regular beans into a bean that has boolean property..
* Option #2 is to bind a datatable to the backing bean, bind a checkbox to the backing bean, and then on submit, actually iterate over the dataTable, and check the value of the h:selectBooleanCheckbox on each iteration . Now, this is pretty simple and straightforward, with the only downside that you definitely bind your backing bean to the JSF API (which is generally frowned upon, but then on 2nd thought, the backing bean is generally tied to the framework api anyways for whatever framework you're using). Now, the thing that kinda pissed me off was that after reading the two books that I mentioned in the previous post, I really had no clue that it would work that way - that the single checkbox that's bound into a single (not array) backing bean property, would change it's "selected" value based on how you iterate inside the h:dataTable .I kinda liked this solution the most.
3. In the appropriate column in the dataTable, include a verbatim html input checkbox. Then, when you're processing the submit in the backing bean, retrieve the request params with the same name as the checkbox, and you will get a string array with the checkbox values. Not a bad solution as you get everything you need, with the downside that you have to muck around with the request... (this option and a couple of other ones are discussed in more detail here
So, there it is.. there are a few different ways to solve this problem that should really be something trivial... and none of them are particularly straightforward....
Here is an example - dealing with row selection in an h:dataTable :
1. One possible way to solve it is to write a custom component, just like ibm did in this explanation . But really, how many people who don't use WebSphere would actually sit down and write their own component for that (especially considering that JSF components are notoriously difficult to do.
2. There was another post on the Sun JSF forums, where none other than CraigMcc responded to a question on how to do it (took a bit of digging
* Option#1 was to have a bolean property in the actual bean that you're iterating over, to indicate that the bean was selected. That is not very pleasant to use, as first, you might have to wrap your regular beans into a bean that has boolean property..
* Option #2 is to bind a datatable to the backing bean, bind a checkbox to the backing bean, and then on submit, actually iterate over the dataTable, and check the value of the h:selectBooleanCheckbox on each iteration . Now, this is pretty simple and straightforward, with the only downside that you definitely bind your backing bean to the JSF API (which is generally frowned upon, but then on 2nd thought, the backing bean is generally tied to the framework api anyways for whatever framework you're using). Now, the thing that kinda pissed me off was that after reading the two books that I mentioned in the previous post, I really had no clue that it would work that way - that the single checkbox that's bound into a single (not array) backing bean property, would change it's "selected" value based on how you iterate inside the h:dataTable .I kinda liked this solution the most.
3. In the appropriate column in the dataTable, include a verbatim html input checkbox. Then, when you're processing the submit in the backing bean, retrieve the request params with the same name as the checkbox, and you will get a string array with the checkbox values. Not a bad solution as you get everything you need, with the downside that you have to muck around with the request... (this option and a couple of other ones are discussed in more detail here
So, there it is.. there are a few different ways to solve this problem that should really be something trivial... and none of them are particularly straightforward....
JSF dirty little secrets
I've been working pretty intensively with JSF for the last couple of weeks on a couple of different projects. I usually read a couple of books before I dig into a technology in order to get a good understanding of how it works, how it does things, etc. So, a couple of months ago, I read 2 books on JSF, looked at a couple of tutorials, and gave it a shot. The first couple of apps were pretty straightforward, and since I never did anything particularly complicated, it worked OK. This time around, the sh*t really hit the fan.. Not that I was doing anything particularly complicated, but it was outside of the "really easy" stuff that is in all the tutorials and books... And all of I sudden, I started finding these "dirty little secrets" that each technology has, that one hopes to either never encounter, or to possibly be able to find a half-decent solution. I really would like to learn more about it, but I was surprised very unpleasantly to start hitting these roadblocks so early in learning about the technology.. I mean, JSF was supposed to make the developers' lives easier... and that is the case for 10% of the most trivial cases..
The other thing that really bugs me is the amount and depth of material that is covered in the JSF books that I have... ("Core JSF" and "JSF in Action"). I mean that it seems that the authors intentionally picked up examples that were in the 10% "easy" zone, where none of the ugliness shows.. I mean, I would have thought that in an effort to make their books useful, the authors would try to cover a few examples that go beyond the trivial stuff. Now, it's not like they don't show you any of the "advanced" stuff like building your own components.. they do, but the basic stuff is really so basic and they don't give examples or useful workaround to the middle of the road practical problems that one encounters...
I will go back to the example that I spent a lot of time on.. and I will try to post the problem, solution, and the explanation..
The other thing that really bugs me is the amount and depth of material that is covered in the JSF books that I have... ("Core JSF" and "JSF in Action"). I mean that it seems that the authors intentionally picked up examples that were in the 10% "easy" zone, where none of the ugliness shows.. I mean, I would have thought that in an effort to make their books useful, the authors would try to cover a few examples that go beyond the trivial stuff. Now, it's not like they don't show you any of the "advanced" stuff like building your own components.. they do, but the basic stuff is really so basic and they don't give examples or useful workaround to the middle of the road practical problems that one encounters...
I will go back to the example that I spent a lot of time on.. and I will try to post the problem, solution, and the explanation..
Subscribe to:
Posts (Atom)