I have a question for experienced pf users, what is the best practise of creating site layouts, should i use frameworks like bootstrap and use it together with pf components or maybe i should create my own template. Another question does primefaces provide complete responsiveness for mobile devices? I have already learnt pf css grid but this is not enough.
The Bootstrap responsiveness does not differ that much from the PrimeFaces in terms of 'grid CSS' like things. But that is only a small part of the responsiveness. Components themselves should have responsiveness built into them to be really useful on devices with different screen real estate or there should be a different component set for other devices. Initially PrimeFaces create "PrimeFaces Mobile" but you had to create different pages or one page with lots if 'if-then-else'rendering wise.
Luckily, they have been adding 'responsiveness' to the existing components for several releases now and decided to deprecate the PrimeFaces Mobile in 6.2 and drop it in 6.3.
The responsiveness of the normal components can still improve (I filed two issued)and they picked those up recently most likely do to the deprecation of mobile.
Regarding the 'improvement', their existing menu components e.g. are not responsive (yet? but no enhancement issues file either) but they have good themes (layout/templates) on offer that do have responsive menu's in them (we use Serenity for which you can easily change the colors to fit your own needs)
Even though the themes are 'commercial', it saves you a decent amount of time and work so I do think they are a justified investigation.
Related
When I enabled data-search-pseudo-elements it causes a 100x+ slowdown in the performance of rendering rows with icons within a grid. Whats strange is that the grid virtualizes the rows, so really only 100 rows may be visible. Without this setting render time is .5 seconds. With this setting it is >30 seconds and often crashes the browser altogether. The icons in question aren't from pseudo elements, but I enabled this feature in my index.html for a targeted use in another part of the app.
Is there any way to use a pseudo class icon without enabling that, or to scope it to only affect a certain area?
Using data-search-pseudo-elements with the SVG/JavaScript implementation has known performance concerns, documented here:
Although you can use pseudo-elements with SVG and JS we do not recommend using this method. It does not provide as many usage options, is difficult to configure, and is the slowest method of using Font Awesome. (Painfully slow in some cases.)
At this time, there's no configuration option to limit the scope of the pseudo-elements search and replace feature.
If you're stuck using pseudo-elements but the performance with the SVG/JavaScript method is inadequate, then your best option may be to switch to the Web Fonts & CSS method.
That said, I'm curious to have a closer look at your scenario to see if there are any optimizations that could be made. Could you post a CodePen?
Anybody know of a good description of containers/layouts/panels/etc for GXT? All the tutorials I've seen usually pick one or two and just use them. Nobody seems to explain the who/what/when/where/how of using various combinations.
Thanx,
~r
PS
Actually I have a slightly complex app (~150 java classes; 8 separate tabs with lots of grids, and lists and tons of RPC calls). Seems my grids are not displaying a horizontal scroll-bar and I suspect it's because I'm using some container/layout combination that prevents it (not FitLayout ;-)
Best source to know about the container, layouts is GXT samples. They are available if you download GXT. You can also checkout the examples in the GXT site. Here is the link
I'm working especially with Java web applications (in which mostly with JSF, Java Server Faces). I'm less concerned with the rest of the technologies.
Since different web browsers function less or more differently from one another, any web application should be designed in such a way that it can be incorporated and executed in a defined way by most browsers (might not be all). Which points should be kept in mind to design a web application in such a way that it can function almost exactly on most browsers?
What are the major differences among different browsers which should be noted by web application developers?
you have to check all of these points befor developing web applications with any language...
Almost all web developers (ahem! – perhaps that should read “quite a lot of web developers”) are aware of the need to check how their site looks in a variety of browsers. How far you go obviously depends on the resources available – not everyone is in a position to check Windows, Mac, Unix and Linux platforms. The minimum test would probably be:
Firefox, as that has the best standards compliance and is the second most-used browser;
Internet Explorer for Windows – currently the most widely used browser. It is essential to check both versions 6 and 7 as version 7
fixed quite a lot of bugs in 6 but introduced a new set of its own.
(Microsoft is however still kicking developers in the teeth by not
making it possible to install both versions on the same computer; you
will either need two computers or one of the work-arounds available
on the net.) Version 5 should preferably also be checked; as of
spring 2008 the number of users is not yet negligible. However it is
now uncommon enough that you needn’t worry about cosmetic issues; as
long as the site is readable that should be sufficient.
Opera – growing in popularity due to its speed and pretty good standards compliance.
For some time I also recommended checking Netscape 4 as well, as it often produces radically different results from any other browser, and was very popular for a long time. However the number of users of this bug-ridden browser is now so small (under 0.1% and decreasing) that it can now probably safely be ignored.
Check printed pages
Print some of the pages on a normal printer (i.e. with a paper size of A4 or Letter) and check that they appear sensibly. Due to the somewhat limited formatting options available for printing, you probably can’t achieve an appearance comparable to a document produced by a word-processor, but you should at least be able to read the text easily, and not have lines running off the right-hand side of the page. It is truly extraordinary how many site authors fail to think of this most elementary of operations.
You should also consider using CSS to adjust the appearance of the page when printed. For example you could – probably should – suppress the printing of information which is not relevant to the printed page, such as navigation bars. This can be done using the “#media print” or “#import print” CSS features.
Some sites provide separate “printer friendly” versions of their pages, which the user can select and print. While this may occasionally be necessary as a last resort, it significantly increases the amount of work needed to maintain the site, is inconvenient for the reader and shouldn’t usually be needed.
Switch Javascript off
There are unfortunately quite a number of Internet sites which abuse Javascript by, for example, generating unwanted pop-ups and irritating animations. There are also a number of Javascript-related security holes in browsers, especially Internet Explorer. As a result a lot of readers switch Javascript off – indeed I often do myself. (I have a page giving the reasons in more detail.) Some organisations even block the usage of Javascript completely. Furthermore few, if any, search engines support Javascript.
It is therefore important to check that your site still functions with Javascript disabled. A lot of sites rely – quite unnecessarily – on Javascript for navigation, with the result that the lack of Javascript renders the site unusable.
Clearly if you need it for essential content, that functionality will be lost. But there is no reason why the basic text of the site should be unavailable.
Avoid nearly-meaningless messages like “Javascript needed to view this site”. If you have something worth showing, tell the user what it is, e.g. “enable Javascript to see animation of solar system”.
Switch plug-ins off
The considerations for plug-ins (such as Flash or Java) are very similar to those for Javascript above. Check the site with any plug-ins disabled. The basic text and navigation should still work.
Interest the reader sufficiently, and he might just go to the trouble of down-loading the plug-in. Greet him with a blank screen or a “You need Flash to read this site” message and he will probably go away, never to return.
Switch images off
If scanning a number of sites quickly for information, many readers (including myself) switch images off, for quick loading. Other people cannot view images. So switch images off and check that the site is readable and navigable. This means, in particular, checking that sensible ALT texts have been provided for images. (This check is similar to using a text browser, but not quite the same).
its worth to take a look at this link for more info
I am into a project in university, I would like to know that how can I use liquid layout in android so that different screen sizes must see the application according to its resolution?
In simple words, I would like to create an application whose layout is perfect in all the type of screens :)
I know how to create it in simple html/css in websites for PCs, but how to do it in android?
Can anyone please give suggestions/help/tutorial link?
Thanks,
Usman
Android provides "liquid" layouts out of the box - the layout dimensions and contained elements adapt to screen resolution automatically. It is gracefully handled by the Android framework. There are various kind of layouts available (LinearLayout, FrameLayout etc.) so you need to check carefully which type of layout is the best for you.
You should avoid AbsoluteLayout. While it is true it lets you specify exact locations (x/y coordinates) of its children it is less flexible and harder to maintain than other types of layouts without absolute positioning. It is now deprecated anyway.
Useful links:
To read more about different layouts see: http://developer.android.com/guide/topics/ui/layout-objects.html
Good tutorials are also available here: http://developer.android.com/resources/tutorials/views/index.html in the "Layouts" section.
AbsoluteLayout doc: http://developer.android.com/reference/android/widget/AbsoluteLayout.html
Update:
Layout itself will adapt to different kind of resolutions automatically but you need to keep it mind that elements contained in a layout can look differently. The same image will be smaller on high-res screen than on low-res screen. Luckily, Android provides a way to deal with this problem in a simple manner. You can supply different images depending on the resolution that a device has (this is a bit of a simplification because there are other factors eg. pixel density in addition to resolution that matters). By the same token, it is also possible to supply a different layout but it is not that common.
Links:
Full story on multiple screen support: http://developer.android.com/guide/practices/screens_support.html
Sample code: http://developer.android.com/resources/samples/MultiResolution/index.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I heard from more than a single source that SVG is dying, it is abandoned by Adobe.
How sad! What's will be next alternative to SVG?
SVG is an open standard, developed by W3C. I really don't see it dying any time soon. Just because certain companies decide to drop its use for their commercial products (usually because they need, or feel they need, something more customised), it does not at all mean SVG will disappear on a more global scale.
At the moment, it's undoubtedly the most widely used vector graphics format on the web. Just take for example the images on Wikipedia - for almost all diagrams SVG is either used or there is a notice stating that it should be used. Many other open source projects endorse it in a similar way.
Now, the XAML markup language (part of WPF/Silverligtht) has been seen as a competitor to SVG by some, but truly they only overlap in functionality to a certain degree. (XAML supports lots of other things such as data binding, events, triggers, etc.) Indeed, the general use of XML is much restricted in that browsers don't natively support it (and can't properly, because of the fact that it's tightly bound to MS technologies). I would not even believe that it's strictly a direct competitor to SVG, nor that Microsoft have intended so.
To conclude, I don't think one can envisage SVG dying out until something clearly improved (and open-standard) comes along to replace it. As far as I know, there is nothing like that at the moment.
Check your sources.
A lot of people want SVG "dead". A common way of getting something to happend is by spreading rumours that it has already happend. It's called a self-fullfilling prophecy (wikipedia). Don't buy into it, and please don't actually help those wanting it dead by spreading the rumor further yourself.
Is SVG dead?
No, it has just begun.
What's next?
HTML5, Canvas and SVG in one long glorious love-affair. Get your first-row tickets now!
(Actually here's a youtube video of html5, canvas and svg showing off the infinite resolution inherent in vector graphics. Somewhat lame but real, unlike rumors.)
SVG (Viewer) was abandoned by Adobe ages ago since most browsers support it natively.
Only IE is holding back the technology by not having native support.
Update: IE9 will have both native SVG support and native Canvas support! (Vista and above only though)
If you'd like to show your support for getting IE to support it natively add your vote and comments to these bugs.
https://connect.microsoft.com/IE/feedback/SearchResults.aspx?SearchQuery=SVG
Bring back VML! Just kidding ;) I don't think SVG is dying, but <canvas>'s adoption for HTML5 seems like the way things are going on the web.
I'd like to add my support for SVG. First, I believe that it is widely used in mobile technology though this is through conversations about 2 years ago rather than seeing code. It was one for the first languages developed by W3C to be used over-the-web and has been consistently supported for the last 10 years. I initially thought it would be a killer-app in 1998 and said so, especially since Adobe then had enthusiastic support.
Because SVG is a full XML dialect it can be easily mixed with other XML applications such as XHTML and MathML. It's possible to include XML information in SVG elements so that documents can be fully semantic (i.e. carry a data-meaning as well as a graphical one).
SVG is effectively feature-complete for a 2-D graphics language. There is no technical reason to invent anything else. It does high-quality rendering, animation and can support interaction through its own elements or through Javascript. It is therefore unlikely that major web software manufacturers will NEED to invent anything else.
The main problem is not that SVG is "dying" - it is not - but that it takes a long time for the various companies to converge. When they do I would expect SVG to emerge as a consensus.
Part of the problem is that graphics are not yet seen as a semantic problem - it's often "easier" to inflict a dumb animation on a client than to set up the infrastructure to send semantics over the web and repurpose at the client. But as the semantic web develops then standards such as SVG will be increasingly important. If, for example, you wish to mash-up geographical information then either you use a properietary solution such as GoogleMaps, or you look for a shared standard approach. You can never count on free proprietary solutions in the long run.
Note also that in many areas which receive public funding there is an increasing drive towards Open standards and this is another reason why SVG is well positioned.
Then there's this article posted Friday on Network World, titled EC decision expected to force IE to better support standards. In it, Håkon Wium Lie, Opera's CTO, states
Second, due to the increased competition stemming from the ballot box, browsers will improve their support for standards. This will result in a richer, faster web. For example, I believe that Microsoft's IE will add support for SVG, a standard that all browsers but IE support.
Of course, it's in his best interest to see IE falling in line, but behind, his browser. He gets to be cutting edge, but part of a larger 'standards' crowd.
While this is an question was asked before high res/ retina displays came to be the normal for mobile devices. SVG is having a big come back as vector graphics solves DPI issues on the web. You will be seeing more SVG on the web than before.
Even apple.com menu is svg now days!