The success of a technology is that it finally occupies a concept. When we applied to this concept, the first thing we think is that this technology is implemented, long time, forming a self-proven process. Some techniques are in their position, it is really a matter of sighing it. JSP TAG is this technology. Some people think that JSP TAG is just an extension of JSP, just a Syntax Suger, which is reflecting a dilemma faced by this technology. Here, some JSP TAG design defects have not degraded this technique, just hope to throw bricks, causing everyone to discuss this technological improvement.
Quote: JSP TAG is the server-side expansion tag mechanism, which is the basis for a series of Java server-side technology. However, several major defects at the beginning of its design have made this technique overwhelmed.
Compare the DOTNET platform we can know that a background label mechanism is needed, JSP TAG is the only standard (JSF and other mechanisms depend here), but it can be designed to all hopes that it is developing developers that have created it. In fact, I am very disappointed with this technology, of course, we have proposed a corresponding alternative. Used in our development framework is a redesigned XML dynamic label mechanism. My point is based on JSP TAG technology, which cannot develop server-side technology with DOTNET, so this is a crime of standard. JSP TAG should not be a JSP supplement, it takes the XML of this big ship, and should go to the road, and should be a chicken rib on the application.
Quote: 1. JSP TAG is closely bound to the JSP model so that business logic is difficult to abstract to TAG. And from the JSP environment, the technical investment in JSP TAG will be unworthy. Here, business logic may be somewhat improper, easy to cause misunderstanding. Because my work is done in the middle part, my original interest is based on JSP TAG development a series of expansion technologies, such as caching, etc. Our XML tag technology is independent of the JSP model, used in the front desk for interface rendering, in the background for workflow description. And it is very convenient to combine with other XML techniques, such as integrating ANT.
Quote: 2. JSP TAG's encoding logic is very cumbersome, especially when writing Loop and container labels. It does not support TAG from the TAG itself before 2.0. The main obstacle is applied. This is definitely a major problem, how many people go to develop JSP TAG themselves, mostly use others' finished products. Difficulties in preparation is to negate the reuse of interface elements. Many people respect Tapestry, in fact, if the JSP TAG technology is convenient, why bother to build a completely different model.
Quote: 3. Use the method of directly maping the properties of the XML tag to the object attribute to cause the TAG object, and have to solve performance issues through ugly pool mechanisms. Moreover, performance issues directly limit the use of a large number of small labels. This is a real difficult, a system designer must consider.
Quote: 4. JSP TAG is a fully dynamic design, a large number of optimizations that can be performed during the compile period, basically all the operations occur during the runtime, limit performance. Our XML tag technology is the first compilation and then run, plus stateless design, can be controlled on performance. My friend Hotman_x is a C and JS masters. Under his strong demand, our XML tag has also added a mechanism for multiple compilation.
Quote: 5. Although the nearest version already supports XML format, it is not in place for XSLT, etc., for example, XSLT cannot be used to interface the JSP file. simplest
...
Quote: 6. JSP TAG requires the use of custom tag names, and cannot enhance already existing HTML tags, resulting in editing in the visual editor. TapeStry thinks it is better. Our XML tag mechanism also supports attribute extensions.
