Re: JSTL - What's the point?

Chris,

But I think the JSTL was meant to be a base framework, allowing developers to extend and write their own tags. They're called "custom tags", and they can be pretty useful.

For example, I can write a tag that handles the logic for displaying a set of page number links. Then the web designer just needs to know how to place [foo:pagination style="xyz"/] on the page, and voila, the pagination comes out. Or, you could log an advertisement impression with a simple tag like "[ads:logImpression position="${pos}"/]. Then the code behind this tag can do whatever it needs to do -- in this case, log an impression to the database. The former example results in HTML output, and the latter doesn't.

The examples you give make perfect sense. Placing custom tags which encapsulate all the display logic within them is fine. The designer and the presentation layer don't see any of that logic. This is precisely the idea behind ASP.NET web controls like <asp:DataGrid> or <asp:Calendar>. I only took issue with having tags like <c:if> and <c:foreach> ingrained within the html. I didn't see them as being any improvement over scriptlets within html.

(I had to use [ and ] above instead of less-than and greater-than - blogger wouldn't let me enter less-than and greater-than!)

Yeah < and > are special characters. The browser interprets it as being an html tag and tries to parse it. To actually display it you have to use &lt; and &gt;.

There are some frameworks built on top of servlets/JSP/JSTL that provide higher-level custom tags, such as Struts and JSF, as you mentioned. Components such as "DataGrid" as nice for rapid development, but if you need to customize that component, the built-in tags may not work well. (I don't know much about DataGrid in particular, as I'm not familiar with .NET)

I dunno how custom tags like <ads:logImpression> are developed (I assume using JSTL/EL?), but in ASP.NET these web controls are basically classes. So the <asp:Calendar> control is actually implemented in System.Web.UI.WebControls.Calendar within the .NET framework. Its 'real' code - as in implemented using C#. So all the rules of OOP apply here. All web controls directly or indirectly inherit from the base System.Web.UI.Control class which provides some common functionality. And it's really easy to customize any functionality you would want. Just create your own custom controls that inherit from one of these base controls and override away. These controls also allow you to hook in callbacks for certain events which is another way to customize the controls. Check out this article which provides a nice explanation of both processes.

Could you post or link a simple ASP.NET example showing this separation of UI/model?

One of the areas where the Servlet/JSP model wins is in the clear separation between the control code and the presentation. There are two separate components. Requests (generally) hit Servlets after which they are forwarded to independent JSPs. In ASP.NET, there is only one component - the Page. Although this page is separated between into a .aspx file (UI) and a .cs/.vb file (code) using the Code Behind Model, these are compiled down to one component. So basically all requests go to a Page and then could potentially be forwarded elsewhere. It's sort of "backwards" to the MVC model. So the Servlet/JSP API model is richer in that sense. Having said this, the Code Behind model does have its advantages. Probably the biggest one being all the UI components are represented as objects which can be manipulated in the code behind page. Here is a simple explanation of the concept.