There is some important information related to the user that is stored inside TabContainer control of ajaxcontroltoolkit. However, if javascript is not enabled, the tabcontainer just disappears (instead of degrading gracefully). So I decided to have list contents of the tabs myself all in one place one after another but inside the noscript tag. Any problems you see with this?
Any alternate suggestions?
Sounds reasonable to me. And shame on Microsoft for not thinking towards graceful degradation!
I'd say this is exactly the situation where the noscript tag was made for. So yes go for it.
Related
i'm new in cakephp and I have started with version 3. I want to build a beautifull app and because I'm not good in design, I would really like to use a free template or buy one that I can use within cakephp.
So, I would really appreciate all your propositions and ideas or best practises. The easy way will be the best because I don't have a lot of time with this project. Thank you in advance.
If you don't have a lot of time like you mentioned, the easiest way to go ahead and get started is to paste a lot of the code in your default.ctp layout inside of src/Template/Layout/default.ctp.
You'll notice there are some lines of PHP already in there that are relevant to fetching blocks of css, meta tags, and other bits of code that could potentially exist throughout your project.
Find the main layout of the theme your trying to use - the one that will be consistent across most of the pages. That's the one you'll use for default.ctp. Compare what's already in default.ctp and make the comparable adjustments around the HTML in that document while keeping the important lines of PHP there as well.
For other important pages like a login or registration page, just create a new document for those, like 'login.ctp', then inside the function that loads the page (maybe 'login' inside of UsersController'), change the default layout with this line of code:
$this->viewBuilder()->layout('login'); // without the .ctp ending
This way you can create one-off layouts that don't really match any other page.
As a user experience requirement, I need to create a dynamic dashlet.
According to what I need, a dynamic dashlet would be a special dashlet that can load inside "almost every content". I say almost every content because of course this kind of dashlet would have its own limits of course. At the same time, it would be nice that the dynamic dashlet has the ability of being maximized, what in fact would show the real content (for example, an Alfresco page).
Perhaps my question is ambiguous, but the intention to give the user the chance of check execute common functionality inside that special dashlet, this way the user doesn't have to leave the dashboard improving the user experience as a consequence.
Did anybody have had such requirement or similar before? Would that be possible to do?
I would like to know some tips and suggestions in order to find out the right approach.
Thanks in advance.
You could try re-using the webview Dashlet which can also show another page.
The only problem is that not every part which is visible in Share can be accessed via url. Sure the template gets build up by regions of *.ftl's but that doesn't mean you can 'just' view the *.ftl.
The only 'dynamic' thing I see is making a custom page template which shows one or couple of regions which are dynamically build by the url.
e.g. pointing to share/page/customPage?region1=documentlibrary should insert the documentlibrary template within that page and thus it can be shown within the iFrame of the webview Dashlet.
Actually the documentlibrary is a bad example, because there is already a portletMode available for Liferay. But hopefully you'll get my point.
I'm setting up a sharer on my site pages, and i've found different links for using the sharer :
share.php
sharer.php
sharer/sharer.php
Which one is the right one to use ?
In the Facebook doc it says the second one, but only with the third was i able to share to a fan page (no linked profile).
Is there a difference between sharing on a profile or on a page ?
Thanks.
There is not much difference among them, it is just their looks and size that is changed using the property type.
I would strongly recommend against:
"The Share button has been deprecated in favor of the Like button, and will no longer be supported.
Please use the Like button whenever possible to drive maximum traffic to your apps."
So, instead of waking up with an nonfunctional share button, you'd be better off with a like button, or implementing a share button from scratch using the JS SDK.
Also, I can tell you for a fact that most of the people would share on their own wall rather than on a page.
The correct one to use is sharer/sharer.php
<a href="https://www.facebook.com/sharer/sharer.php?u=example.org" target="_blank">
Share on Facebook
</a>
https://developers.facebook.com/docs/reference/plugins/share-links/
Is it possible, on a Django webapp, to hide certain links from those users who do not have the permission to click the link?
I bet there is a per-link way to check if the user has persmission to click the link, and then show the link (or not) based on that test. However, when there are a lot links spread across a whole bunch of web pages, that can be ridiculously tedious. Are there any ways to achieve this across the whole website with a setting or something?
write a template tag similar to spaceless that goes over its contents and removes all links that are not accessible. this would save you from having to touch each link manually.
It might be possible to write a custom template tag that would accept a link url, reverse it, introspect what permissions were required for the target view, and then conditionally display it.
You'd still have to touch every link in every template that you wanted to make fancy like that, and it would probably be an ugly beast. All in all, it's probably easier if you come up with a more centralized way to control access.
I'm developing a blog application using Django. Currently, the URL /blog/ displays the front page of the blog (the first five posts). Visitors can then browse or "page through" the blog entries. This portion is mapped to /blog/browse/{page}/, where page, of course, is an integer that specifies which "page" of blog entries should be displayed.
It's occurred to me, though, that perhaps the "page number" should be an attribute of the querystring instead (e.g., /blog/browse/?page=2), since the content of the browse pages is not static (i.e., as soon as I add another post, /blog/browse/2/ will have different contents than it had before the post was added). This seems to be the way sites like Stack Overflow and Reddit do things. For example, when paging through questions on Stack Overflow, a "page" attribute is used; likewise, Reddit uses a "count" attribute.
Extending this thinking, I realize that I use the same template to render the contents of both /blog/ and /blog/browse/, so it might even make sense to just use a URL like /blog/?page=2 to page through the contents of the blog.
Any suggestions? Is there a "standard" way of doing this, or at least a "best practice" method to use?
For my money, the best general purpose approach to this issue is to use the django-pagination utility. It's incredibly easy to use and your URLs should have the format you desire.
I prefer to use the GET URL parameter, as in URL?pg=#. It's very common and provides a standard visual clue to users about what is going on. If, for instance, I want to bookmark one of those pages or make an external link, I know without thinking that I can drop the pg parameter to point at the "latest" front-page index. With an embedded #, this isn't as obvious... do I leave off the parameter? Do I always have to set it to 1? Is it a different base URL entirely? To me, having pagination through the GET parameter makes for a slightly more sensible URL, since there's an acceptable default if the parameter is omitted and the parameter doesn't affect the base URL.
Also, while I can't prove it, it gives me the warm fuzzy feeling that Google has a better chance at figuring out the nature of that page's content (i.e. that it is a paginated index into further data, and will potentially update frequently) versus a page # embedded inside the URL, which will be more opaque.
That said, I'd say this is 99% personal preference and I highly doubt there's any real functional difference, so go with whatever is easier for and fits in better with your current way of doing things.
EDIT: Forgot to mention that my opinion is Django specific... I have a few Django apps so I'm relatively familiar with the way they build their URLs, and I still use a "pg" GET parameter with those apps rather than embedding it in the URL directly.
It seems like there are two things going on. A static page, that won't change and can be used for permalinking, like an article, as well as a dynamic page that will update frequently. There is no reason you cannot use both. URL rewriting should allow this to work quite nicely. There's no reason to let the implementation control the interface, there is always at least one way to skin every cat.