(response about the initial iterate question at end): >>Frankly the example applications stink. >>I have tried struts-logon and that has load of mistakes in it , while
Whom is this supposed to help? People who do not like struts? Nope -- if they do not like it, chances are they are not on this list. People who use and/or commit to struts? Nope -- because you do not give any indication of what you think is wrong with it, so they have no idea how to help you, or to improve the product. People on the fence, who may or may not use it? You might think you save these people some time by scaring them off, but those who leave based on a lack of infomration will likely have to make decisions without proper knowledge, which can also be dangerous. Criticism without focus or direction helps nobody. Struts is not for everybody, nor is it even for every project -- and nobody on this list would pretend it is. If it helps you, great. If it is not for your project, great -- pick the framework or development environment that works for you. And if struts is *close but not quite* what you need, well, that is where these lists and this model of development shines. If you rephrased your issue as follows: "I find the example applications are not well-documented. My project needs a strong user authentication component, but the examples have bug X, Y, and Z in them. With problems in such a simple example, I do not think Struts can handle a login scheme. How do people get around X, Y, Z to implement robust user authentication?" -- you might get a better response. Armed with a knowledge of which X, Y, and Z are your problems, people on this list can provide some manner of help on how to get around these problems. Sometimes problems arise because the developer does not understand a particular facet of struts -- it is complex, and there are points where fuller documentation would be nice. (Ooops -- I should be more specific -- maybe next time:) ). Sometimes it is a genuine problem or bug in the framework, in which case putting it on this list can bring it directly to the attention of the coders -- a responsiveness that does not exist elsewhere. In either case, a conceptual hurdle or a bug, a *specific*, polite post will often get you a solution. Sometimes it will not, but a vague post saying something "stinks" *NEVER* will. >>the users are supposed to produce .war files that are production >>ready,tried and tested. Yes, if you are a developer, you are expected to put together solutions that work. It is, after all, your job. If shortcomings in the examples lead you not to trust struts as a foundation, then you can a) use it, in which case it is also your job to dig past the examples, learn the underlying concepts, and adapt/fix it to your needs, or b) not use it, in which case it becomes your job to find something better, or to roll your own. You have that choice. >>I have purchased a book called in Struts in Action and the simple example >>application also doesn't work and needed correcting. Again, this helps nobody. What did not work? If you made specific corrections, I am sure Ted Husted would appreciate hearing them, and would gladly put them on his website Errata to help other people with the same issues. If you did not make corrections, but just had problems getting the samples running, post what problems you had, and perhaps people will help you get it working. >>>These American companies have a culture of releasing beta >>>functionality. Hyping it up. Getting people from the industry to >>>test it free. Having had the benefit of your free time then they >>>charge you by selling to you >>>after having had your free feedback. >>>I am surprised you have not noticed this cultural trend. I am not going to argue American software firms, except to point out that Apache is not a company, nor is it, strictly speaking, American. Yes, they expect bleeding-edge people to test it. On any given project, you have the option of taking nightly builds, which may or may not be stable, but will have newer whiz-bang features. Yes, these bleeding-edge testers do more work, and as a reward they get a significant voice in the shape of the products they use. If this is not for you, you can take something marked as "stable", that might not have every feature, but has been more thoroughly tested. You get a *CHOICE* on how you want to participate. And after you make that choice and the Apache group takes your feedback for free, they will turn around and charge you *ZERO* dollars to use the software. >>>That is the purpose of having mailing lists. >>>It is to get free feedback amongst other things. True - the purpose of these mailing lists is to get feedback. That feedback can be in the form of discussions, complaints, or problems. If the discussion/complaint/problem is specific and to the point, it will get addressed. If it is not, the discussion will die, and the problem goes unresolved. >>>Comparatively those of us who have to meet to spec are not allowed >>>such luxuries of beta versions. You have beta versions; you just do not call them that, and you do not open your doors and let people see them. Many people work that way; by the time we deliver to our client(s), hopefully we have cleaned up the problems, so that people only see the polished version. The Apache people do it differently. Millions of eyes *see* the warts on their software, and motivated people from that group of users can help improve it. The theory is that allowing others to see the problems leads to quicker and more thorough fixes. On some projects it works very well; on others, not as well. >>>The only upside is that if somebody(who doesn't want to spend on >>>licensing fees) >>>and wants to write a bespoke product can use the tools freely. >>>How ever you have to take your chances with the stability. As said earlier, struts is not for everybody, or for every project. If struts works for you, use it. If it does not, use something else. If it is close-but-not-quite, ask specific questions or help make specific improvments -- there is a type of responsiveness here you will not find anywhere else in the software world. We all have jobs to do, and we pick the tools that help us do those jobs most effectively. Moving on the original poster/question... >>>>I have done quite a bit of development without even knowing about >>>>Struts...and it went quite smoothly.... as far as crying like a >>>>little baby over an iterate tag is concerned,that For what it's worth, I think the 'crying like a little baby' comment was out of line. However, many people here have devoted substantial amounts of their time to this project, so when a question starts with a blanket statement like 'struts is not yet complete', you can expect people to get a bit offended. >>>>was just an example...If inside 3-4 days i could find some basic thing >>>>which was not there in Struts what about in later stages of >>>>development... Iteration over constant numbers is more difficult in struts than it probably could be, but it is not lack of a basic feature so much as a concious design decision. Struts encourages developers to do it another way. This might be why you are not getting the types of straight answers you want, and it may mean that Struts is not suitable for the type of project you have. Iterating over a constant list often suggests having something like an Array of objects or a ResultSet directly in the JSP, and output with something like: <%=object[i].getName()%> = <%=object[i].getPrice()%> Which is something struts tries to minimize, because it means the JSP has to know details about the underlying object type. This might be quick to write, but it can create the maintenance problem that you cannot change your data model without having to change your JSPs. In the struts world, that Array or ResultSet would be converted to a standard java object type before the JSP ever saw it, so that the JSP author never has to worry about syntax or the underlying object type. He/she might use: <bean:write name="object" value="name"/> = <bean:write name="object" value="price"/> This way, the page author does not have to know or care if the underlying objects are an Array, a Vector, a ResultSet, or a Map -- and, more importantly, the programmer can change the underlying code without disturbing any JSPs. You can argue that these struts tags, as well as the separating the layers as much as possible seems awkward, and adds needless complexity to what you are trying to do, and, for some projects, I might even agree. However, if you work with a team, or are writing code that will have to live past your involvement, this type of separation really helps the project stay clean. After that long-winded bit above, I now have to confess I am relatively new to struts, so others might know how to do it better, but here are two suggestions: - If you can, get the Array/ResultSet/whatever to a standard java Collection or Map before you get to the JSP layer. This might seem like an extra layer of work, but it will provide some freedom between your presentation and model layers. Are you using the entire struts framework, or just the taglibs? If you are using only the taglibs, are you following a "Model 2" design, or is the controller and model code in the JSP as well? What specifically do you have to iterate over in your JSP? - If you absolutely have to iterate over constants in your JSP, rather than try to work around the logic:iterate tag, use the JSTL forEach tag. It works in struts applications, and in fact struts developers are encouraging JSTL use when possible. You can find a free implementation of that tag at the apache site. http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html While I have yet to use it, this tag appears to have the syntax you want: <c:forEach begin="0" end="100"> I will loop this for each number<br> </c:forEach> -Greg Ludington --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
