Jayson Falkner wrote: > Thanks for the comments Hans. > > > As Shawn and David, I think these types of actions make sense. It's > > dangerous to think that "one size fits all." > > Agreed, but could you elaborate on your reasons? You didn't explain why > it is dangerous.
Dangerous in a generic sense; if you think there's only one way of doing things, suitable for all situations, you're going to spend uncessesary long time developing simple applications, never get funding for your project because you can't show a working prototype in time, force some applications to be implemented with inferior technology, etc. > By "one size fits all", do you mean assuming everyone should only use MVC? MVC can be implemented in many ways. My comment about "one size fits all" was about the common argument for using a servlet controller in all applications; even though it's a good idea for many applications, it's not always the right choice. The right choice depends on many factors, such as the application complexity, the amount of people that will use the application, the current knowledge and experience of the people available to develop it, how long the application will be used, etc. > > But > > there are exceptions where I think it's perfectly okay to use the > > database access actions in JSP pages, e.g. > > * for a small, company-internal application, when no one with enough > > Java knowledge is around to develop servlets. I believe this is a > > very common scenario that is often overlooked when programmers > > discuss "the right way" to develop web applications. The alternatives > > in a case like this are likely that the app doesn't get developed at > > all, or that it's done with JDBC code is scriptlets, or (gasp!) > > using ASP and Visual Basic code. > > Are you saying the these JSTL tags are easier to learn then the > Java/Servlets required? Absolutely. If you have experience with a real programming language, learning Java in itself is a lot of work. Learning servlets, JDBC, and at least a basic idea about multithreading issues on top of that is just too much. And some people are not even interested in becoming programmers; they just want to provide a simple web interface to an existing database, with no bells and whistles. > What about understanding SQL and XML. Are you suggesting a developer > would understand these enough to use them, but not with a programming > language such as Java? Learning basic SQL is much easier than learning Java. For the last four years or so, I've sold a commerical product that makes it easy to develop database-driven web applications. It started out as a set of servlets embedded with <servet> elements in web pages and then moved to JSP custom actions when JSP 1.1 was released. It has an EL similar to the JSTL EL, and pretty much the same set of features as JSTL implemented as custom actions. Most of my customers call themselves non-programmers but have managed to develop really nice, fairly complex web applications using the product, with just a little bit of hand-holding on my part. > What do you mean by "the right way"? Are you saying when developers talk > about how to develop, "the right way" is equivalent to the only way that > should be done? Yes. Just look at some discussions about this subject on various mailing lists. > Overall your opinion seems to be the JSTL tags would just be easier and > accomplish the same thing. I tend to think they are not easier at all, > just a different approach. If you're not a programmers, it's definitely easier to learn how to use JSTL than to write the equivalent logic in Java. If you already know Java, I agree that it's mostly a "different" approach. But even though I know Java, I tend to use just JSP and JSTL for simple sites; for me, it's simply faster and easier. > Do you think it is wise to promote the use > of these tags to new users? Especially when it may result in a JSTL > skillset compared to a sound understanding of what most people consider > the best method of developing JSP/Servlet Web Applications. Like I said earlier, some people don't want to become programmers and build complex web applications where the advantages of using pure Java code in servlets, beans, and other component types shines. If you try to force them by making "the right way" the only way, they will just use other technology where they have a choice. Besides, as should be clear by now, I don't subscribe to the idea that MVC with a servlet controller is "the right way" for all applications and situations. > > * for any simple application, when its clear that it will not go > > through major extensions; using just JSP pages with action elements > > is probaly very cost-efficive in this case (lower development time). > > Probably? Is it quicker for you or any projects you have helped on? Yes, see above. > I have a hard time believing this would ever occur. Certainly if you > have to train developers the what and how of MVC then it would take more > time, but if the skillset exists certainly not. Not sure what you refer to by "this", but using MVC even for a pure JSP app is a good idea and not too hard to learn. They just have to read my book :-) > > * for prototyping an idea; if the proof-of-concept is successful, > > the app can be redesigned with a servlet Controller, filters, and all > > the other goodies after getting some experience with the basic > > application functionality. > > This is another argument about development time? What about a MVC style > design pattern is so time consuming? Part of it is likely the compilation phase with Java code, even though I know that some containers actually recompile Java classes automatically. But it's also the additional components that need to be developed. For a simple two-page web app (a form for entering a search criterion and a page that displays the result), I only need to develop two parts if I use just JSP and JSTL. If I use a servlet controller, I need the servlet (if I use Struts, I need an Action class), a bean to encapsulate the database access, I still need the two JSP pages, and I typically need to define a few mappings in configuration files (web.xml and struts-config.xml if I use Struts). > > As Shawn, I also see the URL actions as a perfect fit with the View > > in MVC, no matter if you use servlets or not. XML processing can > > About the URL components. The import action seems nice, but not really > practical. Is there a good case where it would be desired to directly > import external content in to a web app? If the content needs to be > further manipulated it makes sense Java would be desired to properly do > it, so importing some XML, perhaps from a Web Service, is something that > would much better be done by a Java class. Again, you assume that there's someone around that knows Java; that's not always the case. The import action is basically a more powerful version of the standard include action, sporting features that makes it play better with JSTL (supports EL attributes, well-defined error handling so the catch action can be used the deal with errors). If you don't use the XML actions, it's still useful for including pieces of common content. > Do you think the url tag is more helpful then a custom anchor-like tag? > e.g. <a href="<c:url/>">link text</a> versus > <c:a url="http://...";>link text</a> > The custom anchor-like tag syntax is cleaner, and it would be easy to > code any URL rewriting logic in to the custom tags setter method. Shawn answered this one exactly like I would have, so please see his reply. > What is a good use for the redirect tag? I often use it in a Controller page to redirect to a result View page so that a reload of the result page doesn't invoke the Controller page again, as it would if I used forward. I have also used it on a site that tracks the number of times people clicks on the links for external sites; the link goes to a Controller page that increments a counter and then redirects to the requested site. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
