If one has a Float field in a domain class, the Grails view generation uses a
<g:field type="number" />
and one gets a
<input type="number" />
type of html field, which purely allows integers .... unless I'm just unable to get it to work differently.
Can one override the scaffolded generation to use something else for Floats, e.g. a simple text field, so that a floating point value can be entered?
Thanks
P.S. I can't find any documentation on the g:field tag, apparently new in this release. Can you refer me to any reference you've seen or include the documentation in this post? (if available)
Voting for the bug in the Grails bug-tracker might help get it fixed. There's also a workaround
This could be fixed by using the widget constraint which allows you to define a custom html element to be generated by scaffold.
Exp:
description widget: 'textarea'
http://grails.org/doc/2.2.x/ref/Constraints/widget.html
Related
In HTML, you can use <input type='number' /> to restrict the user's input to numbers only. It also adds little increment/decrement numbers on the input field. Is there a way to do this in Native Base (v3.2.2)? What is the associated onChange property (onChange, onChangeText, onValueChange, etc.)?
I have scoured the official documentation and have found nothing.
I tried to find the issue and turned out that react-native-web ( one of NativeBase core dependencies) is not passing the props to the HTML Input.
I have created a PR for its fix.
I'm struggling with a Struts2 date formatting issue. If I understand correctly, type conversion in Struts2 is locale aware, and any form fields/parameters that map to Date objects should be strings formatted in their Locale specific SHORT format; the default output for a Date object on the value stack is also output as the Locale specific SHORT format (unless overridden with custom formatting).
Although form fields have worked fine with dates, when using the <s:url> tag I can't seem to get the <s:param> tag to encode date parameters correctly. When I try something such as this
<s:url action="foo" >
<s:param name="endDateParam" value="#endDate"/>
</s:url>
the result is pretty obviously not the SHORT format:
/foo.action?endDateParam=Sat+Jan+14+00%3A00%3A00+EST+2012
I re-read the Struts2 documentation but they mostly discuss creating custom date formats in the i18n'ized properties files, which doesn't seem like the right solution.
Any help with this problem would be greatly appreciated.
You can send it like that :
<s:param name="dateFrom">
<s:date name="dateFrom" format="dd.MM.yyyy"/>
</s:param>
You've probably already solved this by formatting a string in the action the way you need it. This I would advise first, unless you are supper stickler for model/view separation or there isn't a one to one mapping between the action and the view in which case this zealousness my be justified.
Lets say you felt the formatting wasn't the business of the action in that case you could use OGNL to it's full effect:
Here is an example that displays the current date (it uses new to construct a new date but you can very easily just replace "new java.util.Date()" with "endDate". It was constructed this way so anyone can just paste it into their JSP without any action dependencies.
<p>
<s:property value="#java.text.DateFormat#getDateInstance(#java.text.DateFormat#SHORT, #java.util.Locale#CANADA).format(new java.util.Date())"/>
</p>
NOTE: requires OGNL static method access to be true. Easiest way to do that is to add the following to struts.xml:
<constant name="struts.ognl.allowStaticMethodAccess" value="true"/>
Using OGNL to this level is a bit suspicious but it is easy to read and the intention is clearly view/presentation related. Although it isn't that easy to construct... The easiest way is to write everything as one line of java and then apply ognl syntax rules which you would find here:
http://commons.apache.org/ognl/language-guide.html
Also for quick reference:
http://docs.oracle.com/javase/7/docs/api/java/text/DateFormat.html
http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html
I have an (as yet) simple Spring 3 MVC web-app using JSP as the view technology. I am considering rewriting it in Grails before I get too far along.
One thing I like about Spring is the "form" tags provided in the spring-form.tld tag-library. Given a model property "myFormModel" with the "myProperty" property, this allows me to write something like: -
<form:form commandName="myFormModel">
<form:input path="myProperty" cssErrorClass="error"/>
The key here is that the form:input tag automatically does all the binding to the property in the command object, so generating (roughly) in HTML: -
<form>
<input type="text" name="myProperty" value="xyz"/>
Spring MVC will bind the form parameters to the class and pass the object to the controller. Less to go wrong.
(Please excuse the JSP and HTML, it's indicative, possibly slightly incorrect)
As I understand the GSP form tags: -
<g:form name="myForm" url="[controller:'myController', action:'foo']">
<g:textField value="${myFormModel.myProperty}" class="${...blah to select error}"/>
I cannot specify a "path" attribute: I must manually generate the name. When the path becomes complex (say a property of a item from a list), this can become hairy and noisy.
I cannot automatically specify both "normal" and "error" CSS classes: I must put EL into the <input> class attribute. Messy!
I must admit I am surprised that GSP is (what I consider) behind Spring, I thought it was all about making the obvious things simple and the hard things possible. Easy-to-read/implement forms would seem a no-brainer.
So, my questions: -
am I missing something?
should I (and can I) use the spring-form.tld in my GSP?
It makes me wonder what other gotcha's I will run into...
The beanFields plugin does everything the Spring form tags do and more. It makes working with forms about as concise as possible.
Is there a specific reason why I should be using the Html.CheckBox, Html.TextBox, etc methods instead of just manually writing the HTML?
<%= Html.TextBox("uri") %>
renders the following HTML
<input type="text" value="" name="uri" id="uri"/>
It guess it saves you a few key strokes but other than that. Is there a specific reason why I should go out of my way to use the HtmlHelpers whenever possible or is it just a preference thing?
Another benefit is that if your ViewData contains a value matching the name of the field it will be populated.
e.g.
ViewData["FirstName"] = "Joe Bloggs";
<%=Html.TextBox("FirstName") %>
will render
<input type="text" value="Joe Bloggs" id="FirstName" />
There are huge benefits:
It has overloaded methods to pre-populate the values (formatted, and safe for HTML) just like the ViewState.
It allows built in support for the Validation features of MVC.
It allows you to override the rendering by providing your own DLL for changing the rendering (a sort of "Controller Adapter" type methodology).
It leads to the idea of building your own "controls" : http://www.singingeels.com/Articles/Building_Custom_ASPNET_MVC_Controls.aspx
One thing is for consistency...I for one always forget the name attribute. Plus, you can extend the functions for your own projects. They're not called helpers for nothing!
The upside to using an abstraction layer is future proofing your code in a pluggable way. Maybe today, you create HTML 4 pages but tomorrow you want to create XHTML pages or XAML or XUL. That's a lot of changes if you just hard code the tags everywhere, especially if you've got hundreds of pages. If everything is calling this library, then all you've got to do is rewrite the library. The downside is that it is usually considered to be slightly less readable by humans. So, it most probably increases the cognitive demand on your maintenance programmers. These advantages and disadvantages really have nothing to do with MVC.
It actually auto populates your textbox based upon first your ViewData.Model.uri and second by ViewData["uri"]. Doing it manually you'd need to do <input value="<%Html.Encode(ViewData.Model.Uri"%>" />
I haven't been doing MVC too long, but I've already written some extension methods to generate menu tabs based on Html.ActionLink. It allows me to be consistent with my usage and, if I decide to change how my CSS menus work, only modify a single method to output the new tab format.
The other use that I have made of them is in conditional output using ViewData to supply values to the controls.
Is it mandatory in struts2 to use struts-tags. I mean can't we use following:
<td bgcolor="DEDBC6"><div align="left"><font color="#000000"><strong>
Employee Name * :</strong></font></div></td>
<td><input name="empname" type="text" id="empname" size="32"></td>
instead of following:
<s:textfield label="Employee Salary " name="empsal" required="true"/>
I had tried both but when i used 1st i didn't get validation message i.e "empname is required" that i wrote in action-validation.xml although validation is working well.
please comment ?
No, it is not mandatory. In fact a lot of struts2 users are sufficiently dissatisfied with OGNL and choose to use regular HTML instead.
But using the standard HTML tags has the drawback of loosing some functionality, after all that's why the custom tags are there in the first place. It is possible to get validation through validate methods on the controller class even with standard HTML.
If you are just starting out with the framework I suggest you learn the struts tags properly before going off the beaten path.
Is it mandatory in struts2 to use struts-tags.
No, but if you aren't using tags at all then you're not really getting very much out of Struts as a framework. Might as well do it yourself.
i didn't get validation message
If you're using your own markup you'll have to tell it to display the error message. eg.:
<s:fielderror><s:param>empcode</s:param></s:fielderror>
please comment ?
Please stop asking the same questions over and over again.
I don't see why you need any tags at all. Couldn't you just use Struts to generate JSON result types and then use calls to those in your otherwise static jsp pages using JavaScript and JQuery?