|
"I tend to use control or attribute files that hold attributes for certain pieces of the page. Also, I use style sheets very extensivley." ---------- I find that people want to design their own pages, or outsource the page development to another firm that specializes in web content design. What if the customer wants to move to a different application server with different tags? Or if they simply want to add something that you haven't thought of? They'll have to go through your code to change that stuff. You have two possibilities: a servlet that delivers a complete web page from top to bottom with little or no control by the customer (other than some "attributes" which you've chosen), or a component based design where widgets supply dynamic data in a component manner to be placed on the web page as the designer wishes. You methodology is equivalent to the same monolithic programming practices that midrange programmers have used forever: the programmer designs the interface from top to bottom, and when the end user needs a change, they have to ask the programmer to change something and recompile the code. If, on the other hand, you deliver flexible data components that can be placed anywhere on the screen, this allows a designer the ability to design the page however they see fit. The more loosely you couple the widgets with the page content, the more flexible the design is. The end user can go to an outside firm that has web content expertise to design the pages. They simply need to leave "holes" in the website where the dynamic components go. In my opinion, there's no way you design a professional website without this level of separation. There isn't an RPG programmer (or Java programmer) out there who knows both the nuances of business programming and the ins and outs of web design. If you try to do both, you're likely going to be mediocre at one, if not both. "Assume you have an engine that allows customer to order t-shirts. But, there are 100 different companies you're acting as a server for. Each of the 100 companies has a different "face" to their website. Using JSPs the way I think your describing them means you would need at least one JSP for each company, then multiply that by how many "pages" the site has." --------- Absolutely incorrect. But you might think that, because you're not an expert web designer - you're an expert programmer. An expert web designer will design a single JSP that in turn uses a style sheet. For common business functions (such as file maintenance) it's easy to build a common widget that can be plunked into a simple JSP - this gives you many file maintenance progams with one widget. At the same time, you can set the style by included a style sheet in the JSP, thereby allowing different users to have different styles. And all of this can be under the control of a web content designer, where it belongs, and not a programmer. I don't know if you've ever seen the amount of work involved in creating a really creative and good-looking web site - take a look at http://www.edeployment.com for an example. The number of iterations that went through was incredible - to have to recompile a servlet every time we wanted to make a change in an image or a position would have killed us. "Using an attribute file I can use one CGI program (Servlet, eRPG, etc), read the attributes for the site and then dynamically build my HTML. No hardcoding (you learn not to do that right away, at least I did)." ----------- Yes you can, and as long as I like what the programmer thinks looks good, then I'm in good shape. In the real world, my clients each have their own idea about what looks good and what doesn't. Some want splash screens, some want frames, some want bottom border navigation, some want drop down menus. Some find their own applets to use. With the CGI approach, every change like this requires programming - programming that can in turn break the original, working code. It's a terribly bad design decision to have to recompile the code that delivers dynamic business data whenever you need to change the site's appearance. "I find it hard to believe that a non-programmer could do anything more than a very simple JSP code, and most sites aren't simple. When you say non-programmer, do you mean someone like my mom (Manager of GNC for the past 10000 years), or do you mean a "super user" who understands iteration and boolean checks, HTML and web design, but doesn't necesarily know how to "program". I assume you are leaning closer to the latter, but when you say "any user" you're really bending the definition to a point that is misunderstood by some." --------- By non-programmer, I mean "web content designer". An expert web content designer probably has as much or more technical knowledge about HIS area of expertise as you or I do in ours. It's just that their expertise doesn't involve RPG or Java - it instead involves HTML and style sheets and ColdFusion and Dreamweaver. While it's feasible for an RPG programmer to become an expert in DDS design, it is not possible for someone to be expert in the wildly disparate disciplines of programming and web content design. And so, if you want to take advantage of really good web design, you'll need to separate the programming from the web content. And this is why CGI programming is bad. Period. If you program CGI, either in RPG or in Java (servlets without JSP is essentially CGI), then you are locking your clients into your idea of what a good web page is, and frankly, web content beauty is definitely in the eye of the beholder. Joe +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.