Can you recommend a declarative table-generation taglib for JSP (with EL) that is still being maintained? I found a few, such as the Jakarata taglib and Display tag but nothing seems to have been updated in the past year or so.
Any recommendations would be appreciated.
It's true that Displaytag development seems to be moribund, but I'm using it in an application and other than a couple of minor issues we haven't had problems. The source is pretty clean and easy to customize/fix if you're desperate.
The main thing that's kind-of hard to do with Displaytag is to have a table viewing system that allows for user-driven column ordering. The ordering of columns is determined by the order of the column tags in the Displaytag JSP body, not by the order of columns as delivered in the table data structure by the server-side query action (or whatever generates the table data). It'd be possible to code around that explicitly in JSP, but it'd be quite a mess I suspect.
Display Tag which you mentioned is good one. It offers option for lot of customization.
Display tag is probably the most common, but it's still far for being good enough.I have used it intensively and it has severe performance issues, in special when you use custom Decorators. Decorators are needed much more often than they should be and you feel like writing html in old servlet's style.
Ordering is also a mess and it's made alphabetically, specially painful with dates in dd/MM/yyyy format ( I made a dirty workaround writing yyyyMMdd with display:none first of the formated value).
Parameter propagation for links generated by the tag is another headache, not impossible but very stupid to waste your time in such matter.
Exporting options are mostly nice and can save you a bit of time if your client just want what displaytag offers.
External pagination is also good.
Related
We have a rather large application, with a great deal of dynamic content. Is there anyway to force struts to use a database for the i18n lookups, instead of properties files?
I'd be open for other ways to solve this as well, if anyone has ever done i18n with dynamic content.
I don't know of an easy plug-and-play solution for this, so you will probably have to implement it yourself -- plan on spending quite a bit of time just coming to grips with how the localization features of struts 2 (and XWork) are implemented. The key will probably be to provide your own implementation of com.opensymphony.xwork2.TextProvider (and tell struts to use it by providing a <bean> tag in struts.xml). I can think of at least two ways of fitting this into the overall architecture:
Have your TextProvider implementation access the database directly. In the spirit of YAGNI, this is probably the best way to start (you can always refactor later, if necessary).
Alternatively, you could place the database code into an implementation of Java's ResourceBundle interface, which is what XWork uses internally. To me this sounds like an even more design-heavy approach, but on the plus side there are some articles around describing how to do this.
No, there is no built-in way to have Struts2 load localized content from a database. You would need to write that yourself.
What are your requirements? Do you need for users to be able to dynamically change field prompts, error messages, etc.?
You may be able to do something like that by building a custom interceptor. You could have the interceptor read all the key value pairs from your database and inject them into the value stack. The only thing I am not sure about, not really having messed with i18n with struts before, is if the i18n stuff pulls that information from the value stack. If not, I am not sure if maybe you could do something else in the interceptor to load up the information.
Building a custom interceptor is not too terribly complicated. There are plenty of tutorial sites out there, including (brace for self promotion here) my blog: http://ddubbya.blogspot.com/2011/01/creating-custom-struts2-interceptors.html.
Use properties files just for static content, like labels, messages etc.
For dynamic content start with a database table that includes a language-code-id for every language you want to use. All the dynamic content entries that are already translated go with their respective language-code-id added to their primary key. If a translation is missing, you can program your application to fall back to your default language in order to make things easier until the right translation is present.
Let your users provide their contributions in the language they like and store it with the appropriate language-id. Someone should provide the translation to the other languages in order to make the contribution complete.
...
PRIMARY KEY (`subject_id`,`language_id`),
...
I am tired of manually finding locators (id,xpath,css,linkText etc..) for web elements from my web page source. It also consumes more efforts. So, to avoid that I want to write a code that interacts with page source directly and generates locators details (e.g. id="xyz" , xpath ="html/body/table/tr/td/a" etc.)
To achieve this ,I think I can generate ID locator by using split() function of String object. But, what I don't know is how to generate xpaths, css and linkText locators for all page components?
Although I'd generally recommend to construct XPath expressions on your own (as you can better exploit things to mach against like class attributes), probably the most reasonable and convenient automatic way to determine XPath expressions for selenium is to use either Firebug's or Chrome Developer Tool's "Find XPath" feature. They both at least use #id attributes to shorten XPath expressions.
If you want to write some code yourself, eg. for embedding in other tools you use, you might want to have a look at the answers of "PHP XML - Find out the path to a known value" which solves the problem in PHP, or another one with answers for Javascript: "Javascript get XPath of a node".
If you're using any tools not working on the DOM (Selenium/Firebug/Chrome Dev' Tools/JavaScript will do), watch out for the problems I described in "Why does my XPath query (scraping HTML tables) only work in Firebug, but not the application I'm developing?".
There are (at present) no "tools" that do even a marginally decent job of synthesizing reliable and concise xpath or css based locators. I've been writing selenium and HTML/CSS code for nearly the duration of the industry, and the so-called CASE-methods that purport to do this job better than humans produces laughably flawed output more often that it generates useful material. However, I would add a codicil: there is hope.
By taking careful stock of the various XPath and CSS methods (see http://www.w3schools.com/xpath/xpath_axes.asp for some general guidelines) and using only the most minimal locator strings that will pass muster in Firebug, Selenium IDE and other similar plug-ins, one can progress gradually towards a better approach. In general one should (where possible) use only one component from an object's attribute list and avoid using dynamically defined quantities. Best practices would encourage picking class, name or id only if they are "immutable".
Mutability is a tricky issue: simply dragging a cursor over an object or clicking on it may change the class or css characteristics. Sometimes this can be surmounted by using only the "fixed" portion of the offending attribute. For example, a class might initially be 'tabContent', but when the cursor is placed over the corresponding object it might change to 'tabContentMouseOver'. You get the idea. By using an xpath locator string //*[contains(#class,'tabContent')] you stand a better than even chance of hitting the desired object, irrespective of whether it is clicked, highlighted, or even disabled.
The next "trick" I'd encourage you to consider is using the "buddy" principle; many objects (button-like ones in particular) nowadays consist of an image with no dynamic properties wrapped by a div that manages its event-driven behavior. For such situations you might find that //div[#eventproxy='tabObject']/following::img[contains(#src,'tabImage') and text()='Contents'] or something similar will cover all the bases. Contents will vary with your situation of course.
Make vigorous use of the hierarchical axes methods ('following' is one I use quite often), but only where necessary; sometimes '//' will suffice instead.
Penalize yourself for every unnecessary character, and reward yourself for methods which are concise and can weather frequent and severe code changes. Above all, persevere.
In general I avoid using "pure" CSS locators for the following reason -- they were never intended as locators. "Cascading Style Sheets" by their very nature are designed to impact the maximum number of web objects possible, and are very rarely unique to any one piece of content. Web-coders are notorious for changing these on the fly to produce spiffy new effects or restructure content to suit customer demands; why hitch your tests to content that is known to fluctuate? Besides, everything CSS can do (and I do mean EVERYTHING) can also be done inside XPaths if you so choose.
The canard about XPaths being "slower" than CSS methods I believe has been disproved often enough that it should be taken with several tablespoons of salt. Still, if you really feel more comfortable with CSS techniques, go for it! Experience will educate you better than any blurb you find in stackoverflow ever will.
Basic problem
I've come across a bit of a problem while writing my own custom JSP tags to "wrap" the spring MVC form tags. I've wrapped other tags successfully but come unstuck with the select and options tags, this throws an IlleagalStateException. I've debugged the spring code and found that the options tag looks for an ancestor select tag. I'm doing this with tag files so the spring select tag is actually in a different tag file. I guess that's why it doesn't find it.
So the questions is what can I do to get round this?
Possible solutions
I've tried looking for solutions but all I've found is other people having the same problem but no solution posted. I did ponder writing my own select and options tags without using the spring tags but I don't really want to have to replicate the binding that it gives you for free. I don't mind changing to use Java classes rather than tag files but I found previously that the output won't be evaluated as a JSP so you can't output another JSP tag.
Reasons for doing this
Having thought about this for a week since first asking the question I am now clearer on what I want to achieve.
To simplify the markup needed in my JSP's
Factoring out common code (e.g. form:errors after an input or getting a translation from spring:message)
To encapsulate look and feel (CSS goes a long way but often you need to change the markup too)
To be able to build enhanced components that extend the functionallity of the spring tags (e.g. render a multi-select as a picklist or display readonly inputs as text labels)
I'll be interested to hear what people think.
Thanks
Firstly, I'm not sure what you mean by wanting control over styling. I thought you could pass-in class and id attributes to Spring tags and they were copied through (? - although I might be getting confused with Grail tags, as I've been writing Grails apps lately). Edit: plus you can style Spring generated tags by referencing an outer element. E.g. surround your form elements with a div and then style the form elements like: #myDiv input { color: red; }.
From my experience (10+ years webapp dev), its not worth the extra effort to try and future proof your app. When you choose a framework like Spring MVC you are getting a lot of stuff for free, that you would normally have to write yourself. The cost of this free stuff is a certain amount of lock-in (as you said). Spring is pretty good when it comes to this aspect - you can use as little or as much as you want and its usually pretty straight forward to engineer it out if needs be in the future.
So my take is: use the Spring tags "as is". The likelihood of you needing to remove the Spring aspect in the future is very small. As such its a worthwhile risk to "put off" if/until that scenario arrises. You have likely already spent as much time and code trying to engineer your future-proof solution as you would've spent removing the Spring tags - that it outweighs any benefit it might have provided. And add to that - you've written that code and you and/or someone else will have to maintain that code now - versus letting the Spring developers maintain the code for you.
Lastly, if you really don't want to have this lock-in and want full control over styling, then write your form elements by hand.
<select name="foo_select">
<option value="">-- select a foo type --</option>
<c:forEach var="foo" items="${fooGroups}">
<option value="${foo}">${foo}</option>
</c:forEach>
</select>
I've thought about this for a good week now and this is the shortlist:
Give up and directly use the spring tags in my JSP's
Don't use the spring tags at all and replicate their logic in my own tags
Possibly write a tag class that extends or makes use of the spring tag class
Expand the scope of my tags to wrap both the select and options tags
Given the reasons for wanting to do this (which I have now clarified in the question), I've decided to go for the last option. I wasn't keen on this originally because I thought I might end up with hundreds of parameters but it's actually not too bad. The tag files are designed for wrapping common bits of markup so this is what they're for. I've also wrapped my own tag further so there is a picklist tag which outputs my custom select tag and then writes the JS needed to initialise it.
I think this is the best of the possible solutions I've come across based on what I wanted to achieve. This is what I'm going with but I'd still be interested to hear of other peoples solutions if they think they have something better.
I've done some php dev and the big trend in this language is using things like smarty or other template engine.
It usually roughly runs as follows :
load the template as a regular string,
look for its {tags}
replace each {tag} with the result of some code.
cache page with input parameters
render resulting page.
(sometimes add some OO principles such as template becomes an object...)
When I look at jsp, I see usage of scriplets, taglibs with complicated things like
<%# taglib uri="/tags/struts-logic" prefix="logic" %>
<%# page import="ghhghjjgj"%>
then :
<logic:if>some html </logic:if>
or worse :
<%= if (blabal) {%>
some html
<%}else ...%>
and so forth.
Okay, tiles enables me to glue together some jsp pages together which is really handy (like the include in php, sort of)
It seems to me that the php approach is much better in the way that :
It totally separates gui and model processing.
-It's easier to change the pages content when you are working on the behind part,
you're in a real java class with no complicated stuff like % # <%=. (who said
code behind ala C# ;) ?)
The C# approah is very interesting as well but I just want to adress the template part in my question and not start any C# Vs Java Troll war.
I do not also want to say php is better.
I just want to know why there is not a well installed templating engine in java and why we still use scriplets/taglibs.
So I guess I must be missing something.
Can some Java EE Web expert show me the flaws of my reasoning?
J2EE became Java EE a long time ago. Drop the "2".
No one should use scriptlets. It's 1999 technology. If you're seeing it in books, it's because the books are old. There's not a lot of good reasons for writing another servlet/JSP book now.
Custom tag libraries have fallen out of favor. JSTL is the standard. It's unlikely that you'll need more than that.
Templating is common - have a look at Velocity. One project I'm working on uses it exclusively for streaming HTML to the browser.
There are many template engines for Java, Velocity, for example. JSP compiles to Java bytecode. It allows for very fast execution. Whether this factor is important for you or not, depends on your task, for most web sites template processing won't be an issue.
I don't really understand the implications why it's great to write
{if blabal} some html{/if}
and not so good to write
<logic:if test="blabal"> some html</logic:if>
and it's worse to write
<% if (blabal) { %> some html <% } %>
but it's good to write
#if ( blabal )
some html
#end
I personally like to write my logic in java.
Type save
I know the syntax
However, to me it's not a matter of syntax wheter mixing template code and logic is a good or a bad thing. Thus I prefer Snippetory. I gets the logic out of the template while keeping the responsibility for consistence (ecaping stuff and the like), the look (formatting...) and internationalization in the template. The binding logic gets testable, easy to organize and reuse. The data model can be used as is and there's no need to translate it into a model sufficient for some kind of alien technology. In this case the template is rather a kind of a model where you copy the necessary data into rather than a process that self-services from a context.
Now, in this case we'll need to peaces of software to express the same thing, as it always happens as one uses the principles of separation of concerns to get software more maintainable.
Template:
<t:named-region> some html with a {v:value} </t:named-region>
Logic:
if (blabal) {
template.get("named-region").set("value", value).render();
}
Now as we look at this, it's quite a bit more code. Again this is typical to serparation of concerns. However, a quick look on the steps might make sense:
Access to the region is aquired.
Data is bound to the template. This happens fine grained, just like filling in a from.
The completed form is bound to the output.
The last step seems kind of dispenseable. I fill data to it, so it's clear I want to use it. But you have to be aware, render()is a short cut for render(template, "named-region"). So it's a discription how it is used. Thanks to this mechanism you can easily combine the building blocks of one file or even several files to an output of your choise. This leads to an surprisingly convenient re-use of those blocks.
And it gains me focus: When I'm fighting to get html, css and javaScript right I don't have to deal with 'how is the exact path to access the data?' or 'what are the exact case this button is displayed?'. It's just about 'there is logic, so it gets a name'. Very simple, very clean.
Of course there are some other engines this support for separation of template and logic like jByte (I used it for a while) or JTPL just to name a view. However, all of them seem to lack some functionality though, I decided to write Snippetory.
We have a rather large application, with a great deal of dynamic content. Is there anyway to force struts to use a database for the i18n lookups, instead of properties files?
I'd be open for other ways to solve this as well, if anyone has ever done i18n with dynamic content.
I don't know of an easy plug-and-play solution for this, so you will probably have to implement it yourself -- plan on spending quite a bit of time just coming to grips with how the localization features of struts 2 (and XWork) are implemented. The key will probably be to provide your own implementation of com.opensymphony.xwork2.TextProvider (and tell struts to use it by providing a <bean> tag in struts.xml). I can think of at least two ways of fitting this into the overall architecture:
Have your TextProvider implementation access the database directly. In the spirit of YAGNI, this is probably the best way to start (you can always refactor later, if necessary).
Alternatively, you could place the database code into an implementation of Java's ResourceBundle interface, which is what XWork uses internally. To me this sounds like an even more design-heavy approach, but on the plus side there are some articles around describing how to do this.
No, there is no built-in way to have Struts2 load localized content from a database. You would need to write that yourself.
What are your requirements? Do you need for users to be able to dynamically change field prompts, error messages, etc.?
You may be able to do something like that by building a custom interceptor. You could have the interceptor read all the key value pairs from your database and inject them into the value stack. The only thing I am not sure about, not really having messed with i18n with struts before, is if the i18n stuff pulls that information from the value stack. If not, I am not sure if maybe you could do something else in the interceptor to load up the information.
Building a custom interceptor is not too terribly complicated. There are plenty of tutorial sites out there, including (brace for self promotion here) my blog: http://ddubbya.blogspot.com/2011/01/creating-custom-struts2-interceptors.html.
Use properties files just for static content, like labels, messages etc.
For dynamic content start with a database table that includes a language-code-id for every language you want to use. All the dynamic content entries that are already translated go with their respective language-code-id added to their primary key. If a translation is missing, you can program your application to fall back to your default language in order to make things easier until the right translation is present.
Let your users provide their contributions in the language they like and store it with the appropriate language-id. Someone should provide the translation to the other languages in order to make the contribution complete.
...
PRIMARY KEY (`subject_id`,`language_id`),
...