Hello,
Can anybody guide me regarding this issue. I have tried searching a lot on this issue but couldn't get the right solution for it.
Thanks
That is by design, if you mouse off the manage button it should go away.
You could also upgrade to DNN 7 where the Manage button is gone altogether.
I had this issue too in DNN 6.2. If you are developing the module, you can do this:
I include in my View.ascx file:
<% if(DotNetNuke.Common.Globals.IsEditMode()) { %>
<div runat="server" id="showIfEditMode" >
<br /> <br /> <br />
</div>
<% } %>
This will push the module down while in Edit mode (when you will see the Manage button).
Related
Reference:https://codeburst.io/angular-vs-react-which-is-better-for-web-development-e0dd1fefab5b
The two identical example apps made with both frameworks/libraries, extracts below. When I click on the increment in react there is a very noticeable half second delay, whereas there is virtually no delay with the angular version. I amusing an iPhone 5. I was surprised as I thought react is supposed to be faster?
Angular:
<md-input-container>
<input mdInput placeholder='Edit your name' [(ngModel)]='appService.username' />
</md-input-container>
<span>{{homeService.counterMessage | async}}</span>
<button (click)='homeService.increment()'>Click!</button>
React
<Input
type='text'
label='Edit your name'
name='username'
value={appStore.username}
onChange={appStore.onUsernameChange}
/>
<span>{homeStore.counterMessage}</span>
<button onClick={homeStore.increment}>Click!
The issue here actually has nothing to do with either of the app's framework choices. If you try both examples on a desktop, you'll find that they work just fine. The difference is how the apps respond to mobile devices.
The angular app includes this meta tag in the head: <meta name="viewport" content="width=device-width, initial-scale=1">. This makes it so that the webpage sizes correctly on mobile devices, and removes the tap delay.
The react app lacks this completely, meaning the default scaling will be applied, and the click delay remains.
For more details on why this click delay exists, and why the <meta> tag changes this, see this article.
So my client has a website he's created on weebly and he wants me to add a page with some complex functionality. I went ahead and coded the page with angularJs, but now when I add it to weebly with an embed code element, the angular doesn't work. Any clue how to either
A) just add a page normally (.html file)
B) get angular to work within the weebly page
Any help is greatly appreciated
I guess it would really depend on what you are trying to do. Please provide your code, for reference.
To directly answer your questions;
You can add, at least some, angular JS. (I haven't tested it all, but what I did worked)
With Weebly you do not have the ability to add .html files as standard pages.
You CAN add a 'Page Type' to the Theme. (which is essentially an HTML file).
You can add a page and then assign said page type.
~
Example, adding the following to the embed code element will work.
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<div ng-app="">
<p>Input something in the input box:</p>
<p>Name: <input type="text" ng-model="name"></p>
<p ng-bind="name"></p>
I figured out this issue, the angular was working with embed, but not on weebley's editor site. Once deployed, the code worked fine
I have came across a strange issue regarding a logoff a user from site with my specific theme.
When I press the logoff link, then page is refreshed, but user is still logged in. When I changed the site skin to the default provided by the DNN, then there is no problem.
In completly diffrent site that I created with my custom theme, this links works also. I have disabled the javascript thinking that, maybe some js script mess something but result is the same.
I don't know where to start looking for this issue. Any suggestions?
Disabling javascript is a problem. The "logoff" link uses javascript.
GO back to your custom skin with javascript enabled, and use the developer tools to open the Console window. You should see information there that will help identify the problem.
Try messing with the order and priority of the javascript files in the .ASCX skin control. For example, if you have:
<dnn:DnnJsInclude runat="server" FilePath="jquery.one.js" PathNameAlias="SkinPath" />
<dnn:DnnJsInclude runat="server" FilePath="jquery.two.js" PathNameAlias="SkinPath" />
Try switching them around, or alternatively try changing their priorities, like so:
<dnn:DnnJsInclude runat="server" FilePath="jquery.two.js" PathNameAlias="SkinPath" Priority="100" />
<dnn:DnnJsInclude runat="server" FilePath="jquery.one.js" PathNameAlias="SkinPath" Priority="150" />
Sometimes there is a conflict in the order in which the libraries are loaded, even if it doesn't show up in the console.
You can read more about this in the Client Resource Management API
Finally, try comparing the several skins .ASCX files to each other, to see if something is missing in this particular one.
I'm using PayPal Payments Advanced with the hosted checkout pages for a mobile site and can't seem to get it to render as a mobile view on my phone. I've followed their documentation but nothing seems to be working:
https://developer.paypal.com/docs/classic/payflow/integration-guide/#hosted-pages-and-mobile-browsers
It clearly says:
PayPal’s hosted checkout pages are mobile optimized for iPhone, iPod and Android devices. This mobile optimized experience is available for all 3 Layout templates A, B and C. In the case of Layouts A and B, PayPal will auto-detect if the checkout page is being viewed from a supported mobile browser and will redirect to the mobile optimized checkout page.
We are using Layout B, which should be mobile friendly according to the above, but it definitely does not look mobile friendly. I've also tried adding TEMPLATE=TEMPLATEB to the POST data that hits this page but that doesn't work either. Here is a screenshot of what it looks like on my LG G4:
As you can see, it doesn't look very mobile-friendly. The thing is, when I click the "Checkout with PayPal" button it does go to a mobile-friendly version of the PayPal login, but I need this page to be mobile-friendly. Does anyone have a clue as to how I can get this to work or is this a limitation with PayPal?
Paypal screen became responsive when we passed SecureToken and SecureTokenId as querystring parameters instead of passing those values as form post.
That is instead of passing in form post.
<html>
<body onload='document.forms["myForm1"].submit()'>
<form id='myForm1' method='POST' action='https://pilot-payflowlink.paypal.com'>
<input type="hidden" name="SECURETOKEN" value="..." />
<input type="hidden" name="SECURETOKENID" value="..." />
</form>
</body>
</html>
We passed those values as querystring parameters.
https://pilot-payflowlink.paypal.com?SECURETOKENID=...&SECURETOKEN=...
Not very sure why PayPal is handling those differently.
Ok, so in our 'innovation lab', there is currently a push to use Ionic, an hybrid app framework built on top of Cordova for native access and angularJS for the ‘web code’.
There are also some projects which are pure mobile web, using Angular + bootstrap for responsive design for example.
The thing is some projects coming up will need to have both a mobile web site and native apps (ionic hybrid). Most features and screens will be the same, sharing back end and most of the UI but there still will be some difference.
So my question is; How to architecture a project so that it can be both an ionic project and a normal angular website with 2 different deployment approaches. Most of the code being reused but some views for the mobile website and some views for the hybrid app (using more native components and conventions), maybe some routing differences as well.
Is that even a good idea?
And in the shared code, is there a simple way to know in which case you are? some IF, some directives inactive outside of their context, etc.
It feels like there is some sort of missing link i may be unaware of.
Thanks in advance.
I'm working on this same problem. The approach I'm taking is to use separate templates, and when possible, key CSS off the device detection classes ionic adds to the body tag.
Desktop version (default)
.your-style
Mobile Version
.platform-webview .your-style {...}
.platform-cordova .your-style {...}
There's a repository on on Github that might offer some guidance.
https://github.com/jonathanwax/jw-ionic-desktop
To quote from of the source code from his project, you would create a folder for each view with the mobile version of the template.
For example your bootstrap desktop version of template.html could look like this:
<div class="container">
<h1 class="text-danger" id="helpHeader">Help Needed?</h1>
<li ng-repeat="help in vm.service.data"> {{ help.title }} - {{ help.content }}</li>
</ul>
<pre dir="ltr">HelpController: {{vm|json}}</pre>
And a ionic mobile version of this same template could be located at mobile/template.html
<ion-view view-title="Help">
<ion-content>
<ion-list>
<ion-item ng-repeat="help in vm.service.data">
{{ help.title }} - {{ help.content }}
</ion-item>
</ion-list>
</ion-content>
You could create a conditional to work with your router to serve the mobile template if you're in a cordova/mobile environment. I feel like maintaining two templates could be development hell. Which is why ionic snubs its nose at developing for the desktop--this is hard work! And prone to bugs. It's pretty much a flytrap ( ya know for bugs :) ).
We could try writing templates with conditionals, but I suspect different files may have less overhead.
A conditional approach to templating:
Test for mobile environment
var isMobile = ionic.Platform.isWebView();
In the template or view html:
<{{isMobile ? 'ion-container' : ' div class="container"'}}>
Or a use an ng-switch:
<div ng-switch="expression">
<div ng-switch-when="isMobile">
CODE FOR MOBILE HERE
</div>
<div ng-switch-default>
CODE FOR DESKTOP HERE
</div>
</div>
Depending on your application, you can get away with using ionic directives for most of your desktop application. You can sprinkle in desktop styling when needed. There's really not a huge amount of code that would actually need to be served by a different mobile/desktop template.