Try to render elements based on device screen size, say for example I have two DIVs (desktop and mobile) and I wanted to render desktop DIV for desktop user only and mobile so on.
<sly data-sly-test="${ANY_LOGIC_HERE}">
<div class="desktop-render">
<button type="button" aria-label="${item.Label}" class="btn btn-primary btn-desktop">Click Here</button>
</div>
</sly>
<sly data-sly-test="${ANY_LOGIC_HERE}">
<div class="mobile-render">
<button type="button" aria-label="${item.Label}" class="btn btn-primary btn-mobile">Click Here</button>
</div>
</sly>
I know there was some CSS/JS trick, but I need it through server sides. So that on-page view source can have only one div.
Before answering this, I'll remind you that it's generally bad practice to render different markup per device/user-agent. That makes your pages non-cacheable and user-agent is generally not very reliable. There are other techniques, from client-side DOM manipulation to dedicated mobile pages (which you could redirect to in case the device is a mobile).
That said, there's a helper MobileUtil that you could leverage in your Use-Object/Sling Model to determine if the device requesting the page seems to be a mobile.
Make sure to check all AEM server-side mobile APIs!
Related
I'm new to the Ionic framework, and I'm using Ionic 3.
Even though I use a form in my app, I'm still getting this warning in the browser:
[DOM] Password field is not contained in a form:
Why is that, and how can I fix it?
What is it?*
Chromium project (mostly Google Chrome) wants to change the world and make all passwords, as well as all form data autosaved and autofilled by default. The people behind this decision claim that will make the web safer†. While Firefox also promotes autosaved and autofilled form data, Chrome goes further admonishing web developers to comply with form element scoping that's more convenient for the browser.
At the same time, Google Chrome uses heuristics to determine what a "form" is on the web page and doesn't actually need individual form elements to be wrapped in a <form> element.
Additionally, Google Chrome treats all web pages, all forms and all form fields as if they are filled by the end user, where password is user's own password. A use-case where e.g. company administrator fills in new joiner's initial password is not supported.
The shortened URL in the form takes you to Create Amazing Password Forms page the the Chromium projects. Today the text there is very patronising, thus I'll omit the link.
†I neither claim to agree with Chrome/Chromium, nor claim that Google is in the position to profit from autofill via lock-in or access to user data; that's out of scope.
How can I fix it?
Simple: ignore it.
It's only a notice in developer tools in one of the major browsers.
Solution 1:
I think you are using Chrome browser. If you will try on Mozilla, it will not give the error. Please refer to this link for more details:
https://github.com/aws-amplify/amplify-js/issues/165
Here is the example:
<div className="myform" onSubmit={this.validateLogin()}>
<div className="myformgroup">
<label>Email</label>
<input type="text" placeholder="Email" id="email"></input>
</div>
<div className="myformgroup">
<label>Password</label>
<input type="password" placeholder="Enter the Password" id="mypassword" value=""/>
</div>
<div className="myformgroup">
<button type="submit" id="loginButton">Login</button>
</div>
</div>
Is returning the password field is not contained in a form.
Solution 1:
After changing the master div tag to a form as I have in the following:
<form className="myform" onSubmit={this.validateLogin()}>
<div className="myformgroup">
<label>Email</label>
<input type="text" placeholder="Email" id="email"></input>
</div>
<div className="myformgroup">
<label>Password</label>
<input type="password" placeholder="Enter the Password" id="mypassword" value=""/>
</div>
<div className="myformgroup">
<button type="submit" id="loginButton">Login</button>
</div>
</form>
it will not return the warning.
Solution 2:
Install aws-amplify in your project directory as explained in https://github.com/aws-amplify/amplify-js.
I'm having inconsistent results when using social media "widgets", more specifically the Facebook Like button. It is shown differently on different browsers.
I'm trying to use the "large" version of both widgets. Whereas Chromium can display the large and small versions of the twitter widget without any issues, a quite different facebook button shows up.
At a first glance, it doesn't seem to be a rendering issue, as apparently facebook is using different source assets for the widget -- notice the white "f" and the baloon counter.
What's causing this and how can I solve it?
Code
<span class="fb-like"
data-size="large"
data-href="http://www.google.com"
data-layout="button_count"
data-action="like"
data-show-faces="false"
data-share="false"></span>
<a href="https://twitter.com/share"
class="twitter-share-button"
data-size="large"
data-text="TEXT"
data-url="http://www.google.com"
data-via="username"
data-related="username"
data-lang="pt"
data-show-count="false"></a>
<br>
<span class="fb-like"
data-size="small"
data-href="http://www.google.com"
data-layout="button_count"
data-action="like"
data-show-faces="false"
data-share="false"></span>
<a href="https://twitter.com/share"
class="twitter-share-button"
data-size="small"
data-text="TEXT"
data-url="http://www.google.com"
data-via="username"
data-related="username"
data-lang="pt"
data-show-count="false"></a>
<script type='text/javascript' src='//platform.twitter.com/widgets.js?ver=4.6.1'></script>
<script type='text/javascript' src='//connect.facebook.net/pt_BR/sdk.js#xfbml=1&version=v2.8'></script>
Result
Firefox (50.1.0 Linux):
Chromium (51.0.2704.103 Russian Fedora 64-bit):
They're not shown differently on different browsers, they're shown differently if the user is not logged in (you're probably logged in Chrome browser, that's why this happens).
For some reason, Facebook is now using different styles for its buttons when user is logged in or not. And the whole thing is around this input:
<input type="hidden" autocomplete="off" name="new_ui" value="true">
It's not a configurable feature, they just release things as they go. :)
Facebook has rolled out new updates for logged in users and not logged in users. That is why you are seeing different buttons. While changing that an be impossible, another thing that comes to my mind is explicitly changing the default values and overriding the CSS aka CSS Reset.
Default: https://developers.facebook.com/docs/plugins/share-button/
Also this:
Why jquery ui button looks different in Firefox and Chrome
I have form, which I use for users to login to the site. It works in Chrome, but for some reason not in IE 9.
Here is the form:
<cfform name="loginform" action="login.cfm" method="post">
<div class="span12">
<div class="span2">
User Name:
</div>
<div class="span2">
<cfinput type="text" name="username" required="yes">
</div>
</div>
<div class="span12">
<div class="span2">
Password:
</div>
<div class="span2">
<cfinput type="password" name="password" required="yes">
</div>
</div>
<div class="span12">
<div class="span2">
<cfinput name="submit" class="btn btn-primary" value="login" type="submit">
</div>
</div>
</cfform>
I am normally accessing the variable as #form.username#, but it is empty if being used in IE.
The simplified use here:
<cfif isdefined("FORM.submit")>
username: #form.username#
</cfif>
I can't see anything wrong with your code above when I run it I have the username field available to me in the form scope correctly. What version of Internet Explorer are you using?
To better debug this I would suggest the following:
Look at the source of the first page and see if there is anything
strange there.
Install Fiddler2 (http://www.fiddler2.com/) then use this to see
exactly what is being posted to login.cfm.
Other things to look at:
Are you using a javascript or CF framework that might be interfering with things?
I don't see anything overtly wrong with your code either. Did you try this in Firefox as well? Sometimes you can get better debugging information there. Possibly an actual error message with it. Both IE and Chrome can do a bit too "good" of a job of obscuring errors on the page.
My suggestion would also be to use plain form tags. Don't use cfform tags. There's not much need for them here. They aren't really helping you much. You could do your own validation on those fields and know exactly what it is that you are validating. You could also test your field that way. Simply change that cfinput to an input and see if that field becomes available in your post. That would pretty quickly let you know that there's an issue with your implementation of the CFFORM tags.
And it's getting a little OT, don't forget to trim the input and wrap it in XMLFormat() and add cfqueryparams to your SQL lookups to minimize scripting and injection attacks. You can also use CF's scriptProtect or rewriting URLs in IIS to help. Allowing free-form entry to FORMs or URLs without any validation is VERY dangerous.
I'm trying to set up a form in jqtouch with several pages. Basically the user will answer couple questions, go to the next page, answer couple more questions and submit. But Jqtouch doesnt work if I set up one form and put the pages inside of the form tags. Any suggestion how can I solve this problem?
I had the same problem. You're probably using a type of master page to do this, try do pages with form tag like you page tag, eg:
<form id="home" class="current">
<div class="toolbar">
<h1>Title</h1>
<a class="back hidden" id="btBack" runat="server">Back</a>
</div>
<ul>
...
</ul>
</form>
I want to use the Tinymce Editor in my web application. I have a text area on it and I want to submit the data of that text area to the next page. That page should display the data it received. Can you give any suggestions how I can do this.
The best way to think of TinyMCE is as a special textarea. Just like you can submit data from a textarea and retrieve the content via request variables, you can do the same for a TinyMCE editor instance.
In your front-end code, you would have something like this:
...
<script type="text/javascript">
tinyMCE.init({
mode : "textareas"
});
</script>
</head>
<body>
<form method="post" action="show.php">
<p>
<textarea name="content" cols="50" rows="15">Content in TinyMCE</textarea>
<input type="submit" value="Save" />
</p>
</form>
...
Then, in your show.php page, you would retrieve the content like you would retrieve a textarea value:
<?php
...
echo $_POST['content'];
...
It's about as simple as that to retrieve the data and display it in your page. Of course, you would need to take security precautions in displaying data that is entered by an end user. Also, this is assuming you are using PHP as the back-end technology; but, the principles carry over to any technology.
And, consult the TinyMCE documentation for detailed instructions and information on advanced use cases.
You should start with this instructions.
Displaying html content is very simple. You need to place the written text one of yor pages receives on that page - that is all.