Why JSP Sucks So Hard

by Marc Hedlund

Related link: http://java.sun.com/products/jsp/



I've been working (again) on taking a project from HTML to JSP, and doing so reminds me (once again) how completely horrible JSP is.



JSP has this nice impulse to take Java code out of HTML pages and put it into JavaBeans or other Java classes, where it belongs, so the HTML author doesn't need to know Java. Great, that's great. Unfortunately, the "not Java" that is included in the HTML page is completely alien to (most) HTML authors, that it might as well just be Java for all they know or care. So I have to put <exec:iterator condition="<%= shopBean.validate() %>"> right here, or nothing on the page will work? Yeah, okay. How do I test that again?



The result of this is simple and stupid: once again my UI engineers will be taking perfectly good HTML written in Dreamweaver and tearing it apart, throwing out some of it and rewriting other parts of it, just to make it work with the JSP they're writing. Once they're done, the HTML author will have absolutely no clue what the page does any more, and will have no desire or ability to edit it. When we insist that no really we need this redesigned, we'll spend twice as long doing it (doubling our costs, negative ROI, bad technology choice, yadda yadda yadda) since the HTML author will need that long to write in sample data and then have the JSP author tear it out again.



This is completely stupid. It's as if your compiler tore up your source code every time you compiled, and you had to go back and reverse engineer your source again in order to change the binary. Stupid! JSP is only an effective solution when the JSP author is also the HTML author.



I want something different. (Yeah, yeah, I know. HTML templating languages are one of the most over-implemented pieces of code ever. Every single Web design shop, tools vendor, large Web site operator, and two-bit commentator like me has their own stupid solution to the problem. I'm tilting at windmills. I'm wasting my breath. Whatever. The reason there have been so many solutions, and there continue to be so many solutions, is because the problem is still completely broken. It wastes my time and the time of the people I work with and I still want it to be better.) I want something that lets HTML people write and keep their source code in their favorite tools, adding dummy data and seeing how it looks, and lets them add hooks for the Java coders in a way they'll easily understand.



This general problem -- separating markup from other kinds of document information -- was handled very well by Cascading Style Sheets (CSS), which separate document markup from stylistic presentation information by linking the HTML document to an external style document. CSS did this by adding very minimal changes to HTML itself -- namely the "class" and "id" tag attributes -- and putting almost everything in the stylesheet.



I think what's needed instead of stupid JSP is exactly the same type of solution for separating code and HTML. Give me a "code" attribute that I can add to any HTML tag, and overload the "id" attribute. Have the value of the code attribute be an opaque string referring to a codesheet, linked to the HTML document by a a '<link type="text/ccs" rel="codesheet" href="code.ccs">' tag. Have the codesheet use a CSS-style rules specification for indicating which Java (or whatever) class should consume tags with that code or id attribute. Then tell the HTMLer to add the "code" and "id" attributes to the right place in their existing documents, and they're done.



What's important about this is everything it doesn't try to do:




  • It doesn't try to handle class or method namespace collisions in the HTML document -- no need for clumsy and confusing XML prefixes. (Instead, namespaces are managed in the codesheet, centrally named for the whole site.)

  • It doesn't try to let the JSP taglib author create whatever kind of tag they want, confusing the hell out of the HTML author and the HTML author's tools. (Instead, the tagset is defined by the HTML standard the HTMLer already knows.)

  • It doesn't require the HTML author to have a JSP environment in order to author their pages. (Instead, they can put in sample, dummy data to see how the page will look when the code is running, and the Java coder can discard that data on the code side.)

  • It doesn't bind the HTML document to any programming language or paradigm. (Instead, it keeps the author to HTML, and lets the codesheet swap out implementations without changing the HTML.)

  • It doesn't require the HTML author to learn anything new in order to move from a static site to a dynamic site. (Instead, they can use their familiarity with CSS to understand the transition.)


I know I'm glossing over a lot, but I think this is the right model. Has someone already done this? I'd love to see it, if so, that I might boot JSP out the window as it so richly deserves.


73 Comments

anonymous2
2002-12-13 12:04:13
Tapestry Does this
That's how tapestry does things.
precipice
2002-12-13 12:18:15
Tapestry Does this
Tapestry gets close, and I certainly like it better than JSP, but it's not the same as what I want. Thanks for the reference, though. -Marc
anonymous2
2002-12-13 12:55:25
Junky article
I really do not understand why you publish this
kind of junky article. He should learn how to use JSP properly first


amoss
2002-12-13 13:39:39
Junky article
Junky, why? I am a JSP (Struts/JSTL/Taglibs) developer and have been for quite a few years now. In working as a consultant and within a couple different corporations I have come across various (and sometimes over engineered) frameworks that aren't easily understood or manageable when coordinating between HTML developers and the framework developers.


He has a point in the relationship and working model between the two. Scriplets, home-grown taglibs and XSL/XML may seem convenient, easily understandable and employable to a programmer (software engineer), but it sure does bewilder and hinder production amongst the HTML developers and designers who sometimes have a heavy hand in the day-to-day building of web-based UI applications.

shodson
2002-12-13 14:22:00
ASP.NET?
ASP.NET comes close with their "code-behind" approach. Each ASPX (an ASP.NET page) can inherit from a code-behind page, and the code has access to any DOM element in the XHTML document in the ASPX file. It uses a very tag-lib-like approach by allowing the user to create custom "server controls" for embedding complex display logic into your own XML namespaces.
buchansa
2002-12-13 14:26:08
Zope TAL?
Zope's Template Attribute Language (http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL) may come close.
precipice
2002-12-13 16:46:59
Zope TAL?
That is close! It's still language/toolkit dependent, which is too bad, but there are some good ideas in there. Thanks for the pointer, I didn't know anything about this. -Marc
anonymous2
2002-12-13 17:03:40
XMLC
What about Enhydra's XMLC (http://xmlc.enhydra.org)? By adding ID attribute in HTML, every element can be converted to Java classes.
anonymous2
2002-12-13 17:04:04
XMLC
What about Enhydra's XMLC (http://xmlc.enhydra.org)? By adding ID attribute in HTML, every element can be converted to Java classes.
precipice
2002-12-13 17:29:46
XMLC
Excellent! That's really close. Thanks very much for the link. It wold probably be pretty easy to graft a codesheet-like document into the backend that would be exactly or almost exactly what I want.


My only complaint on first glance is that XMLC seems to overload the "class" attribute, which might cause a conflict between a style and a code backend. I haven't thought this through yet -- maybe that works perfectly well.


Thanks again for the reference.

kteague
2002-12-14 16:45:15
Zope TAL?
TAL is open source, and not integrated too deeply into Zope (as far as I know the TAL code is well seperated into it's own product) -- so it would be tricky but not too hard to port it to other languages such as Java. Of course, you could not support the 'python:' syntax, but then if you want proper seperation of logic from interface you don't want to support that feature anyways.


It would be kind of nifty if several different web application frameworks all supported the same template language. Then if you need to port a portion of an application from one framework to the other you could just copy the template portion straight across without any modification.


As a Zope user who writes HTML by hand, and who used to write a lot of DTML (Zope's older templating language which is quite similar to JSP), it's a lot nicer writting TAL. When you are just viewing straight HTML text and trying to imagine how it will look in a browser, it's a lot easier to visualize the TAL code than it is the DTML code.

anonymous2
2002-12-14 16:59:55
use simple HTML conventions
I like postprocess the web page with a stylesheet that recognises the parts which should be dynamic and inserts whatever the app server needs to liven it up.


The stysheet matches on certain ordinary HTML items that are convenient to create in dreamweaver or whatever. For example, any named table is replaced with a dynamic table and its rows become templates for the generated rows.


Admittedly, its sometimes difficult to pick up enough information in the static page to liven it up. And its difficult to make this approach completely general. Buts it can be pleasant to use.


The key is to use HTML names/ids just as a convention between the page author and the logic author and not be tempted to provide more general data navigation/selection within the page (as you say).


- Arnold


Its not a completely general approach perhaps,

anonymous2
2002-12-14 17:46:03
Quixote
Your comment about "tilting at windmills" reminded me of Quixote (http://www.mems-exchange.org/software/quixote/ ) . I have been a Zope user for a while, but Quixote does have its points after you've been struggling with DTML for a while. TAL/ZPT is supposed to make that pain a lot less, but I haven't had a chance to get into it so far.


What I would like the Quixote team to do is to sort of implement what you have talked about in your article. I would like to see a way of embedding PTL into regular HTML.


Please do give it a look.


-LninYo

efsavage
2002-12-15 09:31:41
Many choices to make.
OK first, I have my doubts about you when you say you get "perfectly good HTML written in Dreamweaver", but that's not really the point here. Your answer is simple, its XSL. Now that is only half the answer, you will have to pick some product that will translate your XSL into final page, and I would recommend starting by checking out Caucho's XTP Pages on its Resin servlet container. If anything XTP stands out because the pages don't have to be well-formed XML/XHTML to use the benefits of XSL.


Another option would be JSTL. I've been using it recently and find it removes 95% or more of java code from JSP. However, its syntax is still not quite down to the HTML level. What was this:


<%
User user = (User)session.getAttribute("user");
%>
Hello <%= user.getName() %>


is now:



Better? yes. Perfect? no. Usable? If your HTML designers have half a clue, yes.

mentata
2002-12-15 09:37:14
glad you spoke up
mentata
2002-12-15 09:42:18
sorry, accidental submit
While I don't believe JSP is all bad and plan to integrate it into my own products soon, I believe it opens the door for problems, and should be used with care.


I'm very glad Sun delivered Java back-end first, with mature specs for servlets and beans preceding something more cosmetic like JSP. Look at what happened simultaneously with ASP: bad design, massive inefficiencies, poor security, and program logic spread all over a website. By catering to the quick and dirty crowd, Microsoft created what might have been the ultimate software maintenance nightmare. They are busy rectifying the mess with their own component architecture, but the Java crowd should learn something from those early mistakes. I don't know what Sun was smoking when they suggested servlet functionality would be replaced with JSP, but long live servlets.


Do yourself a favor and design your application first, code JSP last.

precipice
2002-12-15 10:18:08
Zope TAL?
You write:
---begin---
It would be kind of nifty if several different web application frameworks all supported the same template language. Then if you need to port a portion of an application from one framework to the other you could just copy the template portion straight across without any modification.
---end---


Yes, this is part of what I was looking for -- this is a benefit of decoupling the HTML document from the templating language. Unfortunately, this would make codesheets hostile to the economic interests of commercial systems (since it reduces switching costs). It seems like it would benefit, though, tools like Zope -- the Zope authors could argue that their system is the easiest to use in starting a project; and if for some reason you outgrow Zope, you have a transition path to a larger system (as long as it also supports codesheets).

tomdavies
2002-12-15 17:41:32
Tapestry Does this
You'd better use it for your next project, and implement or suggest some enhancements then ;-)


Your description of what you wanted was quite 'broad brush', but Tapestry does sound quite close.


Tom

tomdavies
2002-12-15 17:42:11
Many choices to make.
In Tapestry (sf.net/projects/tapestry) the HTML designer sees:


Sample J. User


Which will show up in their WSIWYG tools just fine...


Tom

anonymous2
2002-12-15 20:31:58
jsp

I wonder what the author thinks of XSLT ? :-)


IMHO, when the suggestion is made to migrate HTML to an XML->XSLT combination, the same arguments apply, multiplied by a factor of 10.

anonymous2
2002-12-15 23:17:52
agree!!!
thank you for your spoken
kbedell
2002-12-16 08:29:05
Something similar to what you are asking for exists
To begin with, I have mixed emotions about what you are describing. As the author of a book on Struts, I have a lot of experience using JSP and various tag libraries. I like its power and flexibility and the way I can integrate everything with my back-end Java code.


That being said, I've worked on projects with beginning JSP/Java developers that came from an html/scripting background. Many times JSP is very frustrating for them to learn. Just understanding error messages is really hard if you can't read a stack trace or understand the calling sequences.


I believe a version of what you are asking for exists in the latest version of Cold Fusion MX. It comes with its integration with Apache Axis.


Here's how it works:


  • The Developer builds web services and exposes methods as web service end-points using Axis. Web services replace beans.
  • The front-end developer then creates scripting variables and "maps" them to web service parameters similar to the way you are describing mapping variables to bean parameters.
  • When the front end developer invokes the web service calls, the variables are populated with the results of the web service call.


This works pretty well and really simplifies things. The front-end developers use Cold Fusion MX - which is a GREAT tool for them - and the back end developers use Java and expose methods as web service calls using Axis.

anonymous2
2002-12-16 09:35:51
A similar proposal, related to TAL
See http://lists.zope.org/pipermail/zpt/2002-May/003303.html
for a thread about a proposed CSS-like extension to Zope Page Templates. There hasn't been much action since then, but I still plan to build it when I have time.
anonymous2
2002-12-16 17:43:21
Most Over Implemented
Actually, frameworks that convert Java objects to database tables and back again are the most over implemented.


anonymous2
2002-12-17 12:15:59
HTML authors?????
Gee, maybe you guys in the state have money to burn, but up here in Canada, the person who writes the JSP/HTML/Struts or what have UI code is also able to write EJB's, Java Beans, business delegates, LDAP clients and SQL queries.


You'd never get a job up here if all you knew was HTML (nor should you!!).


What I'm trying to say is that instead of whining because using JSP makes HTML unreadable to your "HTML" authors, hire real programers who know what their doing.


We love JSP up here, especially when used with Struts, and we've never run across your problems...



anonymous2
2002-12-17 13:18:10
Dynamator does this
Take a look at Dynamator (http://dynamator.sourceforge.net). HTML stays completely pure. Programmers create a file that specifies how to transform HTML into a server page or program. This is simpler than it sounds, and lets programmers use the language of their choice (JSP or Java or XSL or PHP or whatever).
mentata
2002-12-18 05:17:57
canada must be a little behind
The one-man-band was the way things were done stateside about 6 years ago, but the distribution of labor is intelligent and inevitable. There are plenty of people working today with a knowledge limited to HTML. Many are called graphic designers or editors, and they serve an invaluable function: putting a human face on the products of tech-weens. Somebody like that might've even helped to catch the misspelling in your post.
anonymous2
2002-12-18 06:20:04
Not just JSP
Every web scripting language has this problem. JSP, ASP, ColdFusion, PHP, etc. They all suffer from this. Ranting about JSP doesn't make it a bad technology any more than ColdFusion is or ASP is. It is a cost of integrating dynamic content with a more rapid development cycle than a pure code solution.
mxc
2002-12-18 07:05:32
Impossible division of labour
I must agree with the poster from Canada. Web technologies are such that it is almost impossible to get people designing web pages who only know html. They will at least need to know a scripitng language especially javascript. It they have to know that then its not so hard to learn the jsp tags. If its pure html then it can't be much more of a brochure site for which one doesn't need the power of jsp.


The point on testing the look and feel is valid though. JSP is streak ahead of any other technology out there for seperating the presentation from the code. ASP sucks badly and my brief experience with .net indicates that it is impossible to use ASP.net without being a programmer.

jimroepcke
2002-12-18 17:21:45
Zope TAL?
You write:
---begin---
Yes, this is part of what I was looking for -- this is a benefit of decoupling the HTML document from the templating language.
---end---


This is how WebObjects does templating/components (and Tapestry, since it's based on WebObjects concepts).


Suppose you have a WebObjects component (WOComponent) called Example. You'll have an Example.java file for the Example class, and an Example.wo directory containing two files: Example.html and Example.wod.


The .html file defines the presentation of the component, and can contain WEBOBJECT tags for including other dynamic elements or subcomponents. The WEBOBJECT tags will have a name="..." attribute whose value will match a block in the .wod file.


The .wod file contains the bindings between the LoginForm.html file and the LoginForm.java class. (The .java file isn't kept in the .wo folder, typically in the same folder as the .wo is in)


Example.html file:


This is a string.


Example.wod file:


foo: WOString {
value = myString;
}


Example.java file:


public class Example extends WOComponent {
public Example(WOContext c) { super(c); }
public String myString() { return "thing"; }
}


The result of rendering that component is:


"This thing is a string."


This is obviously a simple example that hardly shows the power of what WOComponents can do, but shows you how the "code" is out of the HTML, so to speak.


What is interesting about ZPT/TAL (I have been learning Zope recently so I'm getting familiar with it) is it doesn't use is own tag names but instead these attributes on common HTML tags...


like:


This dummy text is a string.


I like that because it can be loaded into Dreamweaver and will show something representative of what the end result will be, unlike loading the .html file of a .wo component. Dreamweaver doesn't know about WEBOBJECT tags.


However, your idea (and Evan Simpson's on the ZPT list pointed to earlier) about using CSS files is truly excellent. It gives the best of the WO and ZPT worlds: It can use standard HTML tags instead of domain-specific tags (ie: WEBOBJECT), and puts the code in a different file than the HTML, the weakness of ZPT/TAL.


I think WO and Zope would benefit from this addition to their respective templating systems.


And JSP... throw it out the door already! The concept sucked when it was called ASP, and using Java instead of VBScript was never going to make it any better. :(


Jim Roepcke

anonymous2
2002-12-18 19:51:41
Why not XML/XSLT?
Why not just give the designers an XML doc and tell them to transform it to HTML? They can easily test the transformations with the tool of their choice.



anonymous2
2002-12-18 20:37:51
Apache::HTML::ClassParser
paul lucas's Apache::HTML::ClassParser (perl) does something along these lines: http://homepage.mac.com/pauljlucas/software/html_tree/man/Apache_HTML_ClassParser.txt


he credits erik ostrom for the idea.

anonymous2
2002-12-19 02:01:55
Re: Why not XML/XSLT?
XSLT is even harder than JSP for page designer. There's not tool like dreamweaver that will allow you to visually design an html page by using xml and xslt.
natalieng
2002-12-19 20:11:36
Still looking for a perfect solution...
I have used both JSP and XSLT to create web applications. Neither approach allows me to completely separate the business logic from the presentation layer.


JSP can easily be abused because it is too easy to embed Java code directly in the Java page. One has to design the app very carefully and make sure the developers are very discipline to avoid the problem. Even if we manage to avoid littering the JSP with Java code, I found it hard to properly troubleshoot JSP. Also, the tags mixed in HTML are hard to read.


Using XSLT to generate HTML makes it mandatory to have programmers to write and maintain the presentation layer. The problem is - most developers either do not care to, or are not capable of making the web app look pretty, which in these days is very important. XSLT is best used for automating business processes - to transform business documents from one form to another to integrate diverse systems.


In an ideal world, presentation layer should be done by graphic/web designers. However, I still haven't find a good framework / technology that will allow web designers to use their favorite tool to create AND maintain dynamic websites. Can someone who has used Tea or JApple in a real world share their experience?


p.s. Don't know if it's a Canada thing - the web projects that I have done or seen, none of them have web designers doing the front end. The developers generally create everything - HTML, Javascript, Java, and SQL.

bazzargh
2002-12-20 05:03:31
Re: Why not XML/XSLT?
Actually there are plenty of tools like that. eg.
http://www.exln.com/products/stylusstudio/whatsnew.shtml
http://www.geocities.com/zmin_1998/features.htm
http://www.trl.ibm.com/projects/freedom/xslbydemo_e.htm


It is also possible to create XSLT from HTML (in much the same was as XMLC works). The problem is getting page designers to mark up the semantically significant parts of the page. An example of this approach is wh2fo ( http://wh2fo.sourceforge.net/ ) which creates xsl-t stylesheets to generate xsl-fo from the html you can save from word2k, and a separate xml 'data' document. Obviously you can switch the data document and generate different documents with the same style.


I know there are issues with XSLT (I wrote the code for a large commercial site which used it to present the same content on the web, wap, digital tv; perfomance at the time sucked bad in comparison to JSP) but it makes you think about what the /content/ is you're /styling/. I'll admit its not as easy as JSP, but as Dave Pawson said in his XSL-FO book, research has shown that there are cost benefits as soon as you move beyond serving your content on more than one medium.

hlship
2002-12-20 06:48:15
What's Missing?
I'd be interested to know what you find missing from Tapestry; not much from reading your blog.


What you are calling a "code", Tapestry accomplishes with the jwcid attribute (Java Web Component Id).


Instead of a "codesheet", Tapestry has a page specification (or, in the upcoming 2.4 release, implicit components and bindings).


In terms of your last two bulletpoints ... I don't think the HTML guys can ever work in a total vacuum. Surely, just the process of marking some tags with a code (or jwcid) attribute already binds them to a particular paradigm. What's important is that the two sides (HTML and Java) can work effectively without interfering with each other, even if they are physically separted (it's often the case that HTML comes from one set of contractors and Java from another, in large scale projects).


Last bullet point overlaps the previous; just to know what to mark is going to require an understanding of some paradigm. And, again, what's important is working without interference, rather than working in a vacuum.


Tapestry templates looks like HTML and, in fact, are standard (X)HTML ... with additional attributes on some tags (the jwcid attribute that identifies a tag as a placeholder for a component).


Tapestry templates are designed to preview properly in WYSIWYG editor, for example:


User Name


... is a Tapestry component (using the new 2.4 syntax). When previewing, you see the sample text "User Name" ... in production, you see a dynamically generated value (typically taken from a business object).


These changes to the HTML are not so onerous for the HTML guys; they can see something is special with this tag (the jwcid, the [[ ... ]] syntax in the tag) and know not to mess with it, or to grab a Java developer to work with it. You can intuit a lot just from what's there, even without a Java guy looking over your shoulder.


In fact, I've been pleasantly surprised to find that the HTML developers take to Tapestry style development faster than the Java developers, perhaps because they have so much less to unlearn.


I know of several groups and consulting organizations that work exclusively in Tapestry, just because it supports the HTML/Java split so well.

anonymous2
2002-12-20 07:36:02
please....
shouldn't htmlers learn a little more anyway?? i did, i'm better for it!
anonymous2
2002-12-20 07:46:12
RE: canada must be a little behind
The only Companies I've encountered Stateside that do it the way you just mentioned are either huge (having an IT staff well over 10 :) ) or are Consultancies. Visit any small/medium business and you will still find that those who develop the Intra/Internet sites are 'one-man'bands'.
zodiac1
2002-12-20 11:45:02
What about XForms
If you want separation between data and presentation markup, you should look at XForms. While not really supported on today's clients, there are Java and Javascript implementations as well as server side implementations available. It may not be exactly what you want, but it does provide the separation you're looking for.
anonymous2
2002-12-20 13:38:46
This is what I love about PHP
This is why I don't recommend Java for web development, and just use PHP. With many template implementations out there for PHP, it's simple to have someone use dreamweaver and just put little {MY_VAR} where the data goes!


~ Busting up Gorts since 2002 - gortbusters.org ~

anonymous2
2002-12-21 09:25:48
Much Ado About Nothing
This debate about JSP and other templating technologies seems to be getting out of hand. What is the percentage of template code versus static HTML in any template for a visually complex page? 5 percent? 3 percent? Let graphic artists draw their pages with tools that generate HTML. Let programmers insert templating code in the generated HTML. Programmers can hack that, can't they? Artists need not see not only JSP tags but even HTML tags. Programmers, on the other hand, should be able to read HTML.


Following this practice in my own work hasn't let me down yet. An artist sends me HTML files and I go over them and insert templating code turning pages into templates. I am not even going to mention what teplating technology I use because it is entirely irrelevant. My artist sure couldn't care less.


To make this process work, avoid any logic more complex than iteration in your templates, or you will have too much work to do adding template code to an artist's HTML. But that's kind of common knowledge now, isn't it?


Happy programming, fellows!


Paul Yunusov

mentata
2002-12-23 08:13:14
even for small guys
I agree that very small IT departments can't always split these functions and I'll admit my view may be somewhat skewed because I've worked for larger enterprises. However, a business with more than 10 computer people isn't necesarily "huge", and it often isn't the computer people who determine the view layer in the first place. Higher level stakeholders are starting to view their web presence as a strategic asset, and people in marketing or public relations roles are contributing an increasing amount of content, particularly the overall look and feel of a site. More graphic design work is being outsourced, too. The trend is going undeniably in these directions, even for small businesses. In short, there is a healthy demand for separation of the view layer from the underlying logic, evidenced by the many posts to this article, the many alternatives suggested, and the question of JSP itself.


Sorry for the poke at Canada; I wasn't being serious. You should see how far behind people are where I live (the *deep* south).

anonymous2
2003-01-20 17:45:51
Your weblogs suck big time
Hey, who said the HTMLs generated by Dreamweaver is perfect. If you say so, you are the ultimate idiot and ultimate sucker in this Universe.
anonymous2
2003-01-31 08:23:47
Ever heard of XSLT translations dumbass?
Your Java developers have their code expose an XML result, and your design people write an XSLT translation that operates on the XML. No need for the Java people to tear apart HTML, the design people have dummy data to test with, voila. Just means that your design people need to learn how to do XSLT, but I'm sure their feeble little minds will cope with that much easier than learning Java. Perhaps even your pathetic intelligence will be able to grasp it with a few years' worth of coaching
precipice
2003-01-31 08:35:07
Ever heard of XSLT translations dumbass?
The idea here is to make less work for people, not more work. The proposal I suggested, I think, reduces the amount of work for both the developers and the designers, whereas your proposal increases work for both of them.


And by the way, I'm willing to say that a technology or a group is stupid in my weblogs if that's what I think, but at least I sign my name to my opinions. Are you so unsure of your opinions and thoughts that you can't even bear to sign your name to them?


-Marc Hedlund

anonymous2
2003-02-04 01:06:22
I agree.
I totally agree. I'm using JSP on my current project and I can't wait until I'm finished so that I can write my own templating engine.


I don't get why everybody is so set on using either EJB or JSP & Struts.


Just look at JSP. For an example let's say you have a UserBean that represents a User in your database. Say the UserBean has three properties...


id
name
organization


Well, if the programmer decides that he wants to rename 'organization' to 'company' you'd better get out the JSP and start editing. Way to go guys! Great division of M, V, and C.


Struts isn't exactly a killer app either. Oh, but it's soooo user extensible. Yeah, great. If I want to write all of the functionality I need I'll start from scratch.


Ryan

anonymous2
2003-02-05 11:22:32
XMLC rules
I used XMLC on two projects. Since then, I used JSP + Struts. There is no comparison.


XMLC could use some helper methods. So, I created a simple library of static methods to further simplify development. Binding HTML pages to the middle-tier is "a joke" -- it's trivial.


JSP/Struts advocates are dolts who don't understand that what you choose NOT to model is every bit as important as what you choose to model. Ever hear of Occam's Razor? The Gordian Knot? The KISS Principle? "MVC" and "OO" are not Holy Grails, you goddamn losers. TCO is the goal. Maintainability is the path. Lost sight of that? No wonder your startup can't turn a profit.


What's worse than working on a JSP-based project is interviewing for projects at money-hemorraghing startups bent on using these pathetic technologies. Out of the few jobs out there, most involve JSP/Struts. So, I have to suffer interminably through questions from "knowledgeable idiots" about "why is MVC/Struts so good?"


You've probably noticed I'm getting sick of this industry. We're a bunch of hamsters running on a Habittrail (tm). The only company with good design sense is Oracle (declare-->generate). Everyone else deserves to go bankrupt.

anonymous2
2003-02-05 11:33:39
Ever heard of XSLT translations dumbass?
Yeah, I heard of them. But, with XMLC, HTML/graphic artists need not learn XSLT.


Why should they learn something they don't have to? Stick that in your feeble mind.


Loser.

anonymous2
2003-04-09 07:41:14
Ever heard of XSLT translations dumbass?
They should learn it because it's going to be increasingly harder to find a job without knowing it.


If they are designing newspapers or brochures, tehy don't necessarily need to know data transformations, but guess what? They are writing web pages that access and display data.


If someone can make a pretty webpage but cannot handle XML, s/he should go back to doing nice static graphic design, and leave web design to people who can think with both sides of their brain.

anonymous2
2003-06-26 18:50:07
use simple HTML conventions
Try Cold Fusion much simpler and more powerful than most app servers to write web apps.