So, i've been using javadoc for quite a while and know that it supports basic text formatting like <strong> <em> <ul> <ol> etc..
Today i was doing some javadoc, and i wanted to put in <input/> and <select/> so i wrapped it in a {#literal ..}
But i noticed that javadoc wasn't complaining when i put those in without it wrapped in #literal.
To my surprise, i looked at the method signature and read the javadoc, and it actually PARSED the fields.
So my question is, is there a practical use for putting html elements like input and select? And furthermore, isn't this a security concern if somebody generated a web-based javadoc from eclipse?
The reason for allowing HTML is to support basic formatting (font styles, lists, tables, etc). I cannot think of a reason that you would want form controls in there. Likely, preventing such usage wasn't deemed important enough to spend development cycles.
Related
Is there a way to add to a description in a methods quick documentation? I have some methods I created that I plan to use later down on the line and want to add to its quick documentation to remind myself what the method is for in case I forget, without having to go into the method itself to read comments describing what the method does.
Is there a way to add to a description in a methods quick documentation?
The best way to document your methods is giving them (and their parameters) meaningful names.
Comments should not repeat what the code expresses itself. But no generator will ever look into your head to extract your intention from there. It rather will analyze the code and build the comment based on what's already written.
Therefore (meaningful) comments cannot be generated.
There are two valid reasons why you should write comments (yourself):
Interfaces
Interfaces need (JavaDoc) comments to explain the contract behind the method, to express the callers expectation as a help for the implementer.
odd ball solutions
Is there something in your code done in an unusual way?
Then add a comment why you did it so.
There might also be comments for legal reasons e.g. copyright marks, license texts and alike. But there should not be any other comment then this, especially nothing generated.
If you want to put comments in a single place for an entire project, or keep comments co-located with a set of files, try using a README. These are usually written in Markdown for easy conversion to beautifully formatted HTML for easier reading. Try an online markdown editor.
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.
I want to build a CMS/Wiki, I would like to make it with HTML5.
Unfortunately I have been looking for a Wiki rendering engine that could take as input Creole 1.0 syntax and render it as HTML5, Can anyone point me to a library for this purpose?
My second option is to write a renderer for XWiki to support HTML5. Any ideas of how to develop such thing?
The XWiki Rendering engine already supports Creole 1.0 as input syntax, and the output conforms to their recommended HTML output, including the <pre> and <tt> tags for verbatim text (one for block, one for inline). Most of this HTML will be valid HTML5 as well, except for the tt tag which has been removed.
tt was perceived as a purely stylistic tag, and semantically more meaningful tags like kbd, samp, code and var had been available for a long time. The problem is that there are too many alternatives available, so it's hard to pick just one tag to represent correctly (from a semantical POV) all the things that tt is being used for. Should we add 4 different verbatim syntaxes to Creole? Or should we just use code everywhere and ignore its semantics, making it the new tt? Or maybe use pre both for inline and block content, and change the CSS so that it's not always a block element?
Anyway, in order to implement a new html/5.0 syntax renderer, you'd probably have to copy the xhtml module, change most of the classes to just inherit their xhtml/1.0 equivalent, except for XHTMLChainingRenderer where you should alter the way beginFormat and endFormat behave. You should also make an HTML5 parser, so also extend the XHTMLParser class and add another handler for code tags (we should probably do this by default, since it's a valid XHTML tag that we're currently ignoring).
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.
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.