MobiScroll Select Preset - jquery-mobile

The mobiscroll documentation states
This preset enhances a regular HTML select to select the values with a scroller. The original select is hidden, and a dummy input is visible instead. The value of the select is maintained by the preset.
The sample HTML code they provide uses inline styling to hide the original select element
<select name="City" id="select" style="display:none">
However, when I do this and setup the mobiscroll replacement to appear inline
$('#select').scroller({preset:'select',theme:'default',display:'inline',mode:'scroller',inputClass: 'i-
txt'});
I find that although the scroller appears I still end up with what looks like an input element above it. This does not happen in their demo code but there I note that what they do is something like this
<div id="select_cont" style="display: none;">
<select name="City" id="select">
but that simply hides everything including the mobiscroll replacement. Looking under the covers I found that calling
$('#select').scroller({preset:'select',theme:'default',display:'inline',mode:'scroller',inputClass: 'i-
txt'});
introduces a dummy input element into the DOM.
<input id='cities_dummy'...
I can get the dummy to hide itself by issuing a
$('#cities_dummy').css('display','none')
immediately after creating the scroller. However, I cannot understand why things are working differently in the demo code. I have noted that they are using jQuery Mobile v 1.1.1 whilst I am using the very latest version.
Perhaps this issue is related to versions? Or is there something else at play here? I'd much appreciate any help.

I figured it out. It is all down to the
inputClass:i-txt
bit in the scroller options settings. In the demo code they are probably playing with this class via script depending on the value of the display property in the options object. The point is this - in order to get the original select to disappear when the scroller display is set to "inline" you must define i-txt (or whatever input class you use) as
.i-txt{display:none}

Related

grails fields plugin <f:display is 'chopping off' bootstrap dropright action with a table of values

grails v 3.3.9, fields plugin
fighting with fields plgin and theres a problem when rendering domain objects and using bootstrap
i've got a sample here from a simple standalone page to show the problem
<p>f:display category </p>
<f:display bean="maintenanceAgreement" >
</f:display>
<hr />
<p>f:field category</p>
<f:field bean="${this.pageScope.maintenanceAgreement}" property="category">
<g:render template="/_fields/map/displayWidget" ></g:render>
</f:field>
<hr />
in essenence i have added a template in "/_fields/map/displayWidget" that renders a drop right table on a button
when you render a map field directly from your Domain object the sample table opens and you get all of the table
however when you
you can see the differences between using f.display (has clipping problem), f.field ( which seems to work) and f.all that ignores my _fields/map/_displayWidget.gsp
I dont want to have not use the fields plugin but its not working with bootstrap templating
has any one come up with a fix for this problem?
the project demo page is here
github standalone page to show rendering problem
the attached shows the output as you try each and select category property
well goldarn it another 2 days down the pan - but i have it !
I thought at first it was something to do with fields plugin processing. so i hacked a clone of plugin project locally and added some bits so i could watch it/debug step through it
in doing so i noted that my dummy web domain class page i'd cut across to the plugin didnt have the clipping problem. but the styles were not the same so i copied main.css and grails.css from ordinary project back into the plugin, then re rendered in the browser - and the clipping happened again.
so its in the css!. some very careful watching of browser and looking at the browser 'inspect' indicated that the clipping seemed to be enabled very early on in the journey.
so in my dummy page i just used
I then spent a day wandering round the various bits of fields plugin as its not that well explained anywhere.
if you look at the plugins taglib display method, by default that triggers the /templates/fields/_list.gsp. naming is a little odd but its the gsp that renders the domains persistent attributes as an ordered list - the plugins default _list.gsp looks like this
<ol class="property-list ${domainClass.decapitalizedName}">
<g:each in="${domainProperties}" var="p">
<li class="fieldcontain">
<span id="${p.name}-label" class="property-label"><g:message code="${domainClass.decapitalizedName}.${p.name}.label" default="${p.defaultLabel}" /></span>
<div class="property-value" aria-labelledby="${p.name}-label">${body(p)}</div>
</li>
</g:each>
</ol>
so after much exploration coming up through templates, from the bottom I ended up right at the top with the '
so nearly there now. back into main.css that i'd copied in. if you edit that, down around line 215 you get this style. If you comment out the overflow property - its all fixed !
.property-list .fieldcontain {
list-style: none;
/*overflow: hidden; */
zoom: 1;
}
I tried auto, scroll, and visible but that seems to much about with too much of the page so best to just comment it out.
once you do that - the rest of the rendering of your forms starts to work !! blimey one line of css for all that pain. Attached is the page using
Lastly through out all this, id ended up digging through /tracing fields plugin. What a nest that is. Not really finished here, but basically
with no body just renders a label and no content. So you either need to provide provide a body tag, say to get the value field displayed.
as
if no widget template has been defined then the renderDefaultDisplay is called which again has very limited options for controlling the rendering by falling through a 'switch (prop.type)' and basically calls either g.format (bool), g.formatDate (but no LocalDateTime/LocalDate Support) or g.fieldValue, non of which are bootstrap enabled.
if you call
these two diagrams are not beautiful but just high level pseudo code walk through for what the core tags are trying to do. One day i'll try and pretty that up but it might help you if you get stuck
I'll raise a bug for the main.css clipping directly to the grails team and see what happens, but you can comment the line out yourself if you fall foul of it.

aria-live on textarea not working with JAWS

I am using html textarea to simulate a command prompt. On typing a command command (e.g. ipconfig) and hitting Enter key, the command output gets appended to to the text. To read the output I have added aria-live="polite" attribute to the textarea which works fine with NVDA screen reader. However, JAWS on IE, starts reading from the top every time a command is entered. How do I make it read only the newly appended text like NVDA does?
So far I have tried aria-relevant="additions", role=log, role=alert attributes but nothing seems to work.
enter code here
<textarea id="commandPrompt" aria-live="polite"
rows="5" cols="45" wrap="off" spellcheck="false">
</textarea>
IN theory, you should be able to define precisely what should be read using aria-relevant and aria-atomic.
Unfortunately, Jaws doesn't follow standards very well. These two attributes are known not to always work as expected with Jaws, depending on the browser used, the element to which they are applied, etc.
This is probably not the answer you wanted to have, but if Jaws doesn't do what you expect, the only solution is most likely to put the text to be spoken in another element.
In a div or span you are much more mikely to have the expected behavior.

Can you use tooltips on other Dojo wijits such as ValidationTextBoxes?

(Follows on from Can you define tooltips in Dojo wijit template?)
I'd like to be able to popup some help text if a user hovers or keeps the focus on a Dojo wijit for some time. I know that these wijits come with some prompt behaviours such as when they are empty or on validation errors, but I'd like to be able to prompt regardless of the content of the control. For example:
<input name="tooltipTesting"
data-dojo-attach-point="tooltipMe"
data-dojo-type="dijit.form.ValidationTextBox"
data-dojo-props="placeHolder:'Type Something',
required:true,
value: '${blah}'" />
<div data-dojo-type="dijit.Tooltip" data-dojo-props="connectId:'tooltipMe'">
Got to love hovering over links. Sometimes you a get a free tooltip.
</div>
Programmatic definition of the tooltips works for plain HTML elements like anchors, but nothing I do appears to associate a tooltip with other Dojo controls. Advice?
You can programatically connect the widget to the tooltip using
tooltip.addTarget(widget.domNode);
dijit.Tooltip connects to the DOM node(s), not to Dijit Widgets (i.e. javascript objects), but you can always use widget's reference to its root DOM node accessible via widget.domNode.
There is also a problem with your markup: dojo-dojo-attach-point does not assign an id to the widget (you reference from the Tooltip via connectedId). Define id property <input id="tooltipMe"> to do so, then the ValidationTextBox itself and also the root DOM node of the ValidationTextBox will have the same id. Note that you cannot use hardcoded IDs in the widget templates.

submit button behaviour in IE

I have a problem in IE. Hitting enter when the focus is on the last input control sends the focus to the "Next" button. This submits the form. So far, so good.
The code in my base class WizardController looks to see if the Next submit button is null, as follows:
protected string NextButton
{
get
{
return ControllerContext.HttpContext.Request.Params["NextButton"];Nex
}
}
However, despite the form submitting, this property returns null unless the user explicitly clicks on the button with his mouse.
This is blatantly wrong, but I have no idea why it is happening.
EDITED TO SPECIFY THE PRECISE PROBLEM:
The problem only occurs IF there is ONLY one TEXT input control in the HTML form that gets rendered to the browser.
END EDIT
Andrew
I have finally found an explanation for my problem:
It seems to be a bug in IE, whereby if there is a single text input in the rendered HTML form, then IE will not submit the form properly. The issue is described (briefly) at:
Form Submit via Enter Key when using IE
In the above link, no description is given as to why the bug occurs, or since what version of IE, so a blanket solution is better.
The workaround suggested in the article is to add a css hidden text input (with conditionals for IE):
<!--[if IE]>
<input type="text" style="display: none;" disabled="disabled" size="1" />
<![endif]-->
This worked for me, so issue solved.
The following is included to document the issue as I experienced it:
Unlike the problem described in the article, my form did submit. However, when I tried to check which button had been accessed by hitting tab or enter key, no submit button was in the HttpContext.Request.Params collection. So the behaviour I saw was slightly different.
What the above article did identify is that this behaviour is only seen WHEN there is ONLY one text input control. A single check box, for example, does not cause the problem.
I hope that this documents the problem adequately... and that MS will one day correct the bug.
A simple work around might be to use a hidden form element and depend on that rather than the button.
<input type='hidden' name='action' value='next' />
If you have multiple buttons you can always use JavaScript to change the value of the action element just before submitting.

Link in input text field

HI All,
I know this is bit strange question, but please suggest.
I want to create a link on website url content in input type"text" field not any other html tag,Is it possible and if yes how.
Regards & Thanks
Amit
I don't know whether I understood your question correctly or not. Based on my understanding I gave the answer. Feel free to raise your question. Nothing is impossible.
</input>
It displays a text box. You can enter any data into it. If you press enter key then it forwards the page to Google.com
You can use SPAN instead of INPUT. This also serve the same purpose.
<a href="http://www.google.com" ><span style="border:1px solid blue;" >Link</span></a>
This is unfortunately not possible in the way you've asked it in HTML 4 or below. Even with HTML5 which has several new INPUT TYPEs, including URL, it only does validation and has some other useful functions, but won't give you want you want.
You might look for some jQuery plugins that can help you do this, most use the same principals behind Rich Text or other online/web-based HTML WYSIWYG editors. I've had trouble locating them myself.
These 3 situations (that I can think of right now) are pretty much what you will face natively with HTML4 or below, as text in an actual HTML4 INPUT textbox is pure text. It is not html and therefore NOT clickable. Here are some variations:
The INPUT tag's VALUE attribute, also referenced as the corresponding DOM object's "value" property (which is basically what you've been doing, and the most you can hope for, if you decide that you MUST have the text that's ACTUALLY inside the textbox (because the text inside the textbox is the VALUE attribute, as I have it with "http://yahoo.com" in this example):
<input id="myTxtbox" type="text" value="http://yahoo.com">
where the INPUT's VALUE = "http://yahoo.com", which you can retrieve with:
in pure javascript:
document.getElementById("myTxtbox").value
in jQuery:
$("myTxtBox").val()
When your link/url is the text in between the and , i.e. the text/innerText of the textbox. This is useless for your question/scenario since it's not clickable, and more importantly NOT INSIDE the textbox. However, someone might want to use this to retrieve any text that you may be using as a label (if you're not using the <label> tag itself already that is):
<input id="myTxtbox" type="text">
http://yahoo.com
</input>
The textbox's text/innerText is NOT an attribute here, only a DOM object property, but can still be retrieved:
pure javascript:
document.getElementById("myTxtbox").innerText
jQuery:
$("myTxtBox").text() -- you would use this to capure any text that you may be using as a label (if you're not using the tag).
The result being: http://yahoo.com
When your link/url is the form of an ANCHOR () with an HREF to your url (and visible link text) in between the and , i.e. the innerHTML of the textbox. This is getting a bit closer to what you want, as the link will appear as, and function as an actual link. However, it will NOT be inside of the textbox. It will be along side it as in example #2. Again, as stated in example #1, you CANNOT have actual working HTML, and therefore a working 'link' inside of a textbox:
<input id="myTxtbox" type="text">
<a href="http://yahoo.com">
http://yahoo.com
</a>
</input>
Once again, similarly to example #2, the textbox's innerHTML is NOT an attribute here, only a DOM object property, but can still be retrieved:
pure javascript:
document.getElementById("myTxtbox").innerHTML
jQuery:
$("myTxtBox").html()
The result being: http://yahoo.com
You could simply do this :
<input type=text value="link" readonly>
So whenever somebody clicks the textbox, it works as a link, and since it's read only, there wont be any text input/change.
Be careful tho, for it wont look like a regular link and might cause confusion, or may be misinterpreted as a normal textbox.
This is how I did it with JavaScript and JQuery. This wraps the entire text field in a hyperlink, so essentially the entire text field is click-able, which may not be the functionality you are looking for. It worked for my purposes though.
The reason I didn't just use a $(nameTextField).click(function(){...}) structure is because the text field I'm using has the disabled attribute set, so click functions aren't fired. That's why I had to wrap the text field in a hyperlink.
// Make person name a hyperlink to page in new tab
var nameLink = "/exampleUrl/?initStudentId=$" + studentId;
$("#studentNameLink").replaceWith($("#studentNameLink").html()); // Unwrap any previously wrapped text fields
$(nameTextField).wrap("<a id='studentNameLink' target='_blank' href='" + nameLink + "'>"); // Wrap text field in anchor
$(nameTextField).css('color', '#326699'); // Make text blue
$(nameTextField).val(studentName); // Set text field value
Half the people here missunderstood it. The OP would like to have the content/value of the input fields to be hyperlinks instantly and NOT the fields themselves.
It is doable... although it's not an input field but the appearance acts like such one.
Use the following: contenteditable=true
HTML
<div contenteditable=true>
<a id=lnk style=-moz-appearance:textfield href=http://www.google.com>http://www.google.com</a>
</div>
or optionally -webkit-appearance ..depends
JavaScript
var lnk=document.getElementById('lnk');
lnk.addEventListener('click',()=>{
window.location.href = lnk.getAttribute('href');
});
http://jsfiddle.net/Dezain/jm9mzrzp/
You want someone clicking a textbox to actually be treated as a link click?
Sounds malicious to me but you could bind the focus event via javascript to a window.redirect().
I don't know if I get the question right. As I've understood you want to be able to type in a ...-tag into an input-field. No other tags should be allowed. You can achieve this by using PHP for example:
<!-- HTML-Code -->
<input type="text" name="link" />
// PHP-Code
$link = strip_tags($_POST['link'], 'a'); // Remove all other tags than the <a>-Tag...
Is that what you mean?
Yes, it is possible, but it's not that simple. You need to create div, or other tag you prefer, that will be always floating over your input, using CSS positions, and create anchor inside it.
For example, virtual keyboard img is embedded into input field that way on russian Google page (http://www.google.ru/)
Because of browser-compatibility it's not a simple task.
EDIT: Understood your question a little more. You still need first part of the answer, and you will need to handle keypress event inside your input. When symbol is entered you will need to update your floating div.
So now task is difficult even more. Maybe you should revise your model and not the code.

Resources