jpa-taglib 1.0, a JSP tag library for using Java Persistence API, has been released. This project has the goal of developing a tag library for JSP that enables use of the EJB3 persistence engine without scriptlets. The documentation implies that use of a Java EE container is required; there's no mention of using JPA outside of a container.

As the EJB3 specification (JSR-220) has not been finalized, the tag library may undergo minor changes, but at the time of this writing, the specification is at "Proposed Final Draft," so any possible changes might be very minor.

The tag library defines six tags, related to general tasks for data storage and retrieval:

• em, for retrieving an EntityManager
• tx, for transaction demarcation
• persist, for persisting an object via the current EntityManager
• remove, for removing an object from the data store
• find, for finding an object with a given primary key
• refresh, for refreshing an object with contents from the data store

What do you think of the tag library? The tag library authors don't seem to fully endorse managing the model in JSP, while providing capability to do just that; is embedding data access in a JSP a good idea?

Huh.. Are we giving up on MVC?

;P

Huh.. Are we giving up on MVC?;P

Yeah... many have already done so. Give it (MVC with or without Model 2) a try and go further.

MVC and web apps: oil and water by Harry Fuecks:
http://www.sitepoint.com/blogs/2005/12/22/mvc-and-web-apps-oil-and-water/

Is embedding data access in a JSP a good idea

No. It's potentially error-prone, and doesn't foster reuse, for a start. Anything that's in a JSP is not reusable except in a web tier, and not testable outside a full deployment, for a start. Also, IMO, delimiting transactions in the web tier at all (and especially in JSPs)

I don't see anything in JEE 5 that affects such thoughts around architectural best practice. E.g. JPA is a standard for ORM, and that's good, but it doesn't create a new class of product, just a new API for a well-understood class of product.

Rgds
Rod

This library is not for all IMHO. It should be clearly stated who will find this library useful: the developers of small/prototype apps. It is probably good if you need to quickly develop a draft where the architecture has not been developed yet.

This library will be successful if it is used in the correct way. Otherwise it will get the problems and bad reputation much like EJB -- not because it's a bad technology, but because it was mostly misused.

But I am not among the potential users of this library -- MVC and that's it.

+1.

I've always been puzzled on why JSTL was embracing those classes of tags, which implicitely allows/encourages developers to use them, even in MVC architectures.

Interesting, what does it mean "embracing" ? -)
If you do not need than do not use it. But in general this stuff could be useful, to compete with PHP at the end of the day. In general MVC looks good, in the many particular cases Model 1 could be enough.

Marina
Coldbeans

P.S.
It looks like a kick from NET Pet shop is needed for J2EE evangelists from time to time. Back to the reality ;-)

I've always been puzzled on why JSTL was embracing those classes of tags, which implicitely allows/encourages developers to use them, even in MVC architectures.

Sadly, I was on the JSR for the JSTL (JSR-52). Initial work was focused on collecting best practices from people who were doing tags, but it eventually turned into a more proactive group, which has its good and bad elements.

In some ways, the proactivity was excellent: it gave us the JSP EL, for example. In others, it was horrible: witness the SQL tags. Even when it was beneficial, it tended to be a bit myopic IMHO: the EL, for example, should have had pluggable renderers from the start (and I asked for it!) but only recently have we seen anything along these lines, and I still think it's underpowered for what it should be.

Sadly, I was on the JSR for the JSTL (JSR-52). Initial work was focused on collecting best practices from people who were doing tags, but it eventually turned into a more proactive group, which has its good and bad elements.

In some ways, the proactivity was excellent: it gave us the JSP EL, for example. In others, it was horrible: witness the SQL tags. Even when it was beneficial, it tended to be a bit myopic IMHO: the EL, for example, should have had pluggable renderers from the start (and I asked for it!) but only recently have we seen anything along these lines, and I still think it's underpowered for what it should be.

JSTL does average to good job for data output, but it does not bother about data input at all. What I want from JSTL is a combination of Struts HTML tags + BeanUtils for data conversion. Is it that hard to take HTML taglib from Struts and massage it? All that is needed is generating properly qualified field names on output, and populating (and type-converting) server-side objects on input. Struts was doing this for years. Of course, I can bundle Beanutils and HTML taglib together in a neat library myself, but this won't be a *standard* solution for common problem.

I am afraid that with new khalif on the block all web-related improvements in J2EE will be made in the sake of JSF. I don't expect another version of JSP anytime soon.

---
Michael Jouravlev
JSP Controls: Create page components with JSP

This library is not for all IMHO. It should be clearly stated who will find this library useful: the developers of small/prototype apps. It is probably good if you need to quickly develop a draft where the architecture has not been developed yet.

Yes, this is an important clarification. However, IMO it's usually incorrect to assume that using a sound, strategic architecture is going to be slower to prototype than a quick hack without appropriate architectural layering. Doing the right thing doesn't need to be hard. You may end up refining an initial architecture skeleton; but it's a lot different from using something that you know is unsuited for the long term.

Did the person who thought of this love coldfusion?

Sorry but this all sounds like a bad idea. On the other hand I'm sure someone will like it.

The only case I can possibly see for the use of these tags is if someone needed to dump a JSP file accessing the JPA for something REAL quick and REAL dirty. The only thing I can fathom would be something that might be easier to access via a quick JSP that either through a debugger or something more formal.

But, truth is, for something that quick, odds are the developer would simply cut and paste something from working code into a scriptlet, or call a DAO directly that hides all of the glue code anyway.

The reason I don't think that these tags are particularly relevant for Model 1 JSP coding is simply that they rely on the rest of the EJB stack to make this work.

Someone who is doing Model 1 coding typically won't make the leap to using the Persistence API and everything that comes with it. Model 1 is fast and easy to use because you need little more than a JDBC driver and a DB Connection. If you think through the slightest bit, you'll set up a connection pool and use that instead.

But beyond that, you may as well jump to Model 2/MVC if you're going to the trouble of configuring the JPA at all.

On the whole I support Model 1 coders, and things like the SQL tags from the JSTL. Just because it's not the perhaps best way to develop applications, there's no reason to exclude those who wish to do so, or are simply comfortable doing so, particularly for small applications of just a few screens.

Of course today, with things like JSC 2, for a small app like that I'd probably just drag and drop my way to quick app nirvana and ideally never have to touch an XML file or hardly anything at all. JSC 2 can very well make Q & D Model 1 apps a thing of the past.

So, I think these tags are simply redundant. If you were doing the kind of application that would use these kinds of tags, you probably wouldn't be setting up the infrastructure to support the tags. And if you had an application that was already leveraging such an infrastructure, you probably wouldn't need these tags anyway.

Tag libraries and JSP suck. Tag libraries look so compact and powerful, but they inevitably fail since the tag->java->html translation usually needs to be understood to use a tag. Also, tag libraries tend to not be flexible: if you use a tag, you can't mesh it with other tags to do new, customized processing. The tag does what it does, and can't do anything else.

Inevitably, using a template engine for markup of xml data services is more flexible, and more maintainable in the long run. If you run into something the original data service or markup doesn't do, you customize it. If you have implemented tags and then want to do something the tag library can't do (a VERY common occurrence, and usually happens when development is at full steam, you've already decided to standardize on approaches, tools, and design) you have to dump the tags and go my route anyway.

Doing data persistence control from a tag library can't be an improvement.

If people had properly architected their web and data access tiers, AJAX apps would be a lot easier to transition to.

Also, tag libraries tend to not be flexible: if you use a tag, you can't mesh it with other tags to do new, customized processing.

Why? Use tag files for example.

Dmitry
http://www.servletsuite.com

tag libraries tend to not be flexible: if you use a tag, you can't mesh it with other tags to do new, customized processing. The tag does what it does, and can't do anything else.

This is true for regular tags. How about prep tags? Say, instead of using <html:form> tag, you write something like this:


<%-- Create scoped variables --%>
<prep:form scope="page"/>

<%-- Use plain HTML tags with scoped variables --%>
<form action="${formAction}" ... onsubmit="${formOnsubmit}">
  ...
</form>


Prep tag works like a view helper, creating appropriate variables in needed scope.