I am using GWT/Spring to develop web applications. currently my appln supports only IE7. it also supports other browsers like firefox. but alignments are changed across the browsers. how can make the web application view is same in all the browsers? PLease help me.
Thanks!
There is no silver bullet in terms of cross browser compatibility. This is a huge area and highly dependent on the specific HTML and CSS you developed for your application. Going for that "pixel perfect" compatibility can easily eat up hours and hours in tweaking and is often not worth the effort. Like Piyush mentioned, it might be more productive to make sure your site looks nice (not broken layout) in the browsers you are looking to support rather than trying to make it look identical everywhere.
Best advice I can give you is to adhere to HTML standards (which tags can be nested inside which etc), use CSS for styling, don't over-use tables unless you absolutely have to and don't create layouts that will break if one element is a pixel off (like moving a an inline div to a new line just because it rendered 101 pixels wide instead of 100).
EDIT: this is a very useful little javascript library I have used on several occasions, http://rafael.adm.br/css_browser_selector/. What it does is to add classes to your <html> element based on the browser. That way, you can create specific CSS to target a single (or family) of browsers for those exceptional cases where you have to go in and style specifically for one browser.
I also have a GWT-Spring application . I use EXT-GWT - GXT from Sencha . GWT basically compiles the components for different browsers .
The
<module>
<set-property name="user.agent" value="gecko1_8,ie6" />
</module>
compiles the code for different browsers . But as is common with all apps , We use different css for different browsers and tweak these as necessary . There are quite few javascript libraries that would help you but you may come across integration issues with GWT .
Dojo is a nice UI library to look at...
Although, JQuery is more known for its browser support, dojo is much simpler.
But in general, there is no method without hardcoding for each browser to display things exactly the same. The point in browser support is to have a nice interface for all browsers rather than the exact same interface. In General, you will be fine as long as you use a strict HTML standard.
Hope this Helps
JQuery might be helpful for you, but remember 100% cross browser support without some dirty tweaking is really hard to achieve..
this is a nice link for cross browser jQuery support
Related
I have what I think might be a strange question to ask.
Recently I was playing with some java web frameworks (jsf with primefaces) and I noticed that it's quite good at handling form data or when you play along with the jsf components. I also did a project using grails and again it was useful for form data.
But the moment you want to do something which requires a little deviation; then I found myself doing weird things (examples are tag clouds with large strength values using primefaces and single page webapp forms with grails).
This resulted in some very messy html+javascript code for my grails things(which I blame on my inexperience with javascript). This was done because I was using expression language (grails in this case) to populate some of the javascript. The worst part was that I had a bunch of custom javascript code inline with my server pages (I could of refactored a little out but I think one would still have alot of javascript calls inside a single page).
So now to the question(s) :)
[main question] Are there any resources that demonstrates how to design or at least implement maintainable javascript with server pages (gsp, xhtml, etc) ?
The reason is that I find that there are some neat javascript frameworks, but using them with server pages seems a bit unnatural if one takes into account the expression languages for server side frameworks? Unless it's normal to do this type of thing :) ?
Are there appropriate frameworks for Single page webapps using java?
My current answer is that GWT, Vaadin (based off GWT) and perhaps JavaFX qualify. Maybe ZK, Flex and (Grails/Roo + Flex/GWT) also qualify as well?
Are java web frameworks still useful for presentation layers?
My current answer is that they might be when you are dealing with portal type webapps or Web 1.0 apps for lack of a better word. The other case is that they could be when you use alot of role based security and you want to filter things out based on roles, but even that has counter arguments.
My other answer to this is that it might be better to use a java server to provide your web services and then rely on something else to do the front end?
This might be OP, but for single page apps, it's easier to serve up data from the server via JSON(P)/XML/whatever and then use things like Backbone to process and modify the view(s) accordingly. That way, the server can use REST/SOAP/websockets/whatever, and the browser app becomes a full-fledged app.
I haven't actually done this, so don't quote me, but I imagine that it should make sense.
Just out of curiosity, between <applet> vs <object> for a Java applet, which one should I use? I know that <applet> is deprecated, however Sun still recommends the use of <applet>.
Is there any drawback between the two tags? Because when I use <object> for Mac in Safari, it causes a problem saying that the page can't load, even though the page loaded properly, and when I check the activity window it said that the class was not found/cancelled. For example:
Use applet if you have found that it works more often. The object element was introduced as a theoretical unification that would be a catch-all for any embedding of external data. It never worked well, and modern HTML development has effectively abandoned the unification idea. HTML5 introduces audio and video, for example and keeps img (logical unification would surely deprecate img, because an image can be embedded with object).
Use deployJava.js as mentioned in the applet info. page..
..To avoid browser compatibility issues, the Deployment Toolkit script provides JavaScript functions that automatically generate the HTML required to deploy RIAs. Developers should invoke these functions to deploy their solutions in a consistent fashion across various browsers.
Then you don't have worry about whether the script writes an applet, object or embed element.
As an aside. Copy/pasting the text from the Activity window would be a lot more useful than a screen-shot. Now I look (squint) at it, it seems the only two lines of output that are in any way relevant are:
http://admin.file-lift.com/css/none not found
http://admin.file-lift.com/com.pspinc.util.FileUploaderApplet.class cancelled
The css/none is not a class or a Jar, and neither of them exist on the server. So that applet has problems beyond the HTML elements used to deploy it.
Use <object>. <applet> was deprecated back in HTML 4.01.
Unless you're targeting a stone-age environment, there is not reason to acknowledge the existence of the applet tag.
I think Sun has a point. HTML5 says:
The applet element is now obsoleted so that all extension frameworks
(Java, .NET, Flash, etc) are handled in a consistent manner.
In other words, it's no longer valid for reasons of theoretical purity and not because of any practical problem. Frankly, I find <applet> simpler and more reliable to use in the real world and continue to use it.
While deployJava.js might hide the gory details away, the reality is that under the hood, it still uses <applet> in some circumstances.
I've read a bit on client-side browser languages and tried a few out but I'm not convinced I know of all the options. To make it clear, I'm looking for something that can be processed either through the browser or otherwise on the clients computer with minimal need for additional installations/configurations.
At the moment I know of JavaScript, Java, and Flash ( I'm aware this isn't actually a language, but seems pertinent to mention it still as an option). If at all possible it seems like avoiding Flash would be best, but it's still a consideration. I know there are various flavors of JS and Java but I don't really know of any that make the end-product that different than just the raw language. Java and JavaScript both seem relatively slow when it comes down to more complex and weighty apps, though performance is always improving as our browsers and libraries get better.
All this said, is there anything available or about to be available that will do things better?
JavaScript is the only native browser language that’s widely supported. Flash isn’t native, but it’s the most widely-supported plug-in.
Nothing else yet seems to be installed widely enough to be worth considering in general, although obviously you should always try to figure out what the actual/intended audience of your specific project has installed.
JavaScript performance has come on leaps and bounds in the latest versions of all browsers as it’s become more widely used.
As far as interface programming goes, the only thing JavaScript has built in is the DOM interface, which lets you programmatically control the HTML page that the JavaScript is running on. The DOM interface is pretty raw and basic, so there are lots of frameworks that try to make it more palatable (like jQuery), and frameworks that seek to provide libraries of desktop-like UI controls (e.g. jQuery UI, Cappucino).
JavaScript is the main language for client-side browser development that interacts with the elements on the page, does ajax requests (update screen without a full page refresh), etc. Depending on your specific requirements, I would recommend JavaScript, as its most likely the tool that will accomplish your needs.
Java is NOT a client-side browser language, Java is a programming language, you can write apps in Java and embed them in a website, that is called a Java Applet. This will require that all users have a JRE installed on their machine for your applet to work.
Java has nothing to do with Javascript -- they share some similar syntax, and thats about it.
Flash is a browser plugin, if you want to write a flash application, ActionScript is the language it uses. It still requires that anyone going to view your application have the Flash plugin installed.
HTML5 is the future.
Currently many features are achieved with JavaScript, but these are being wrapped in libraries (e.g. the "polyfill" library Modernizer and even in other languages, e.g. Java with GWT. This is an area in a greater state of flux than most.
You forgot unity.
Unity is an up-coming client-side application development platform. It does require installing just like flash but it's a lot more powerful then flash and seems to be picking up popularity.
Unity has a lot more inbuild framework rather then doing it in HTML5+JavaScript. I would say these are your two main options. For an example of javascript & html5 in action look at cloud9ide
One of the big advantages of unity is the 3D engines.
Java applets are so 1998 and are not an option.
I'm a full time Java developer of around 4 years, professionally. I'm a GWT fanatic. I love Java. Here's the problem: In my free time I often fall victim to the verbosity of my favorite tools for doing "heavy" development. I also often fall into the trap of obsessively engineering my software. I'll end up with the most beautiful unfinished implementation, ever.
So, here's what I normally work with.
GWT - I use this for dynamic UI and web layout. I love the ease of re-use and it has taught me to absolutely hate javascript. I really can't even bring myself to do much HTML/JS anymore.
Hibernate - POJO to Database, easy-peasy. What i really need from this other than the mapping is that it allows me to have an application that works across multiple databases.
Spring - Mostly security. I've written my own custom LDAP bits for a project.
XML - I've used dom4j and other implementations, including xstreamer. I'd like to use JiBX for XML transport. The problem with this is that I need XML messages that conform to a specific standard rather than being autogenerated. Object->XML->Object are also common enough that it can be a performance bottleneck with large messages (250KB+).
I tried Lombok for a little while and liked it but had occasional issues with it and then I blew up a partition and lost all that work. I don't really feel like doing the same thing again (half the fun was in learning how to do it, now that I know... meh). This taught me why other people want to reduce the explicit code and replace it with an implicit system.
I've been looking into Grails but that runs me into the JavaScript problem (you know, that I don't like it) pretty quickly. I could use GWT with Grails on the back end but I get back into the problem of getting deep in the weeds with GWT. It has also occurred to me that there might be a way to have Grails tags in GSP that are made up of GWT widgets. I'm not really sure how I feel about that.
Another problem I have with Grails is that validation logic before form submission is separated from validation constraints after submission. I don't see how they can be unified (yet) to produce "pretty" front-end validation. I went out of my way to start a JSR-303 compliant validation project for GWT to help solve some of this problem for GWT and really liked the results. It isn't finished but I still find it useful.
So, help me find a better way!
TL;DR - I want to have a Database (and Database-Independent) to GUI solution that allows for dynamic web programming all in one language. Failing that, as close to one language as possible.
TL;DR is TL;DR - I hate JavaScript now, help.
EDIT: I know that it is techincally impossible to do "Web 2.0" development without JavaScript. I'm just trying to not be the guy who has to write it. (Getting a tool such as GWT to do it for me from a language I do like, for example.)
Just learn JavaScript.
Resistance is Futile
...and you will be assimilated.
PD: I'm an ex JavaScript enemy. Now it's my favourite language.
You can certainly develop an entire Web 2.0 project without coding Javascript using GWT (we have), but at the end of the day you still have to know HTML/CSS & Javascript.
This might sound like a stupid statement, but it's not once you consider that GWT is not a perfect abstraction, nor is it designed to be. It wasn't written in Java so that you didn't have to ever code in Javascript again, instead they did it because Java has better IDE's, is statically typed and makes maintenance a hell of a lot easier.
So yes, by all means go with GWT (and check out the new OOPHM, because it's AWESOME) but don't forget that you'll always need an understanding of the underlying frameworks of the web, if you want to develop for the web.
Have you heard of Echo?
It doesn't provide the database part of the problem, but it would work well with any database that you can work well with.
Echo is a platform for building
web-based applications that approach
the capabilities of rich clients. The
applications are developed using a
component-oriented and event-driven
API, eliminating the need to deal with
the "page-based" nature of browsers.
To the developer, Echo works just like
a user interface toolkit.
The latest iteration, Echo3, features
the ability to write applications in
either server-side Java or client-side
JavaScript. Server-side applications
run in any Java Servlet Container and
do not require developer knowledge of
HTML, HTTP, or JavaScript.
You might want to take a look at some of the AJAX powered JSF libraries. IceFaces and RichFaces are both solid.
Been there, done that. I was a GWT developer for 3 years... I started using it in v1.1! GWT is fantastic, and works really well for small applications. But the development comes to a crawl once you it a moderate application size, even if you divide your application in sub-modules.
It is also quite ironic that a UI framework has such limited UI creation tools. :)
Personally I bit the bullet and learned javascript. It isn't as bad as I thought. Especially with jQuery. :)
Obviously there is no perfect framework. But just the fact that GWT has been out for 3.5 years now, and it still largerly ignored in the Java world should tell you something. Since you're doing this on your free time, I would recommend learning the most popular framework: Struts. You'll see its limitation, and also why it is so popular. Of course, you'll need jQuery for that 2.0 functionalities. :)
Take a look at JRapid, a rapid development platform for Java developers. It generates very powerful Ajax enabled UI without the need of coding.
Not sure if you would like this , but have you heard about Haxe?
You might not like it but its AIO (all in one) solution (sort of).
I can understand your dislike of JavaScript and it certainly has its problems but I think your fighting nature at this point.
Web 2.0 is strongly based on JavaScript for a good reason as it provides the ability to perform tasks on the client machine without requiring page loads.
I'm sure there are alternatives but if you want the look and feel of Web 2.0, you will end up doing a lot more work with little reward. JavaScript is the accepted and functional tool for the job.
I'd say stick with GWT and just drink more of the Koolaid. It's a completely awesome development model that seems to be lost on those who haven't tried it.
If you want to improve your GWT experience, jump to the bleeding edge (I work off trunk, it's quite stable) and use the other Google originated projects like GIN, gwt-incubator and Guice. Especially watch Ray Ryan's GWT best-practices Google I/O talk: http://www.youtube.com/watch?v=PDuhR18-EdM
As for the "framework" part: forget 'em. Just use normal servlets and let GWT take care of the RPC for you. Servlets are a pain when you have to deal with JSP and you're own AJAX calls, but when they're only implementing asynchronous app logic, it's not that bad at all. Guice Servlet makes it all quite easy. You can still use a JVM hosted language to write your servlets if you want.
GWT has an incredible advantage over other JavaScript frameworks in that the layer of abstraction it provides allows for major future advances without any changes to your code. If the GWT compiler and browser detection scripts can take advantage of new browser features then you benefit from a simple recompile.
The big annoyance I see in your requirements in XML... hopefully that's just for integration with a 3rd party service and your client-server communication can just be GWT-RPC.
I don't use javascript or ajax, in medium-large application they create a lot of problem with compatibility, because moving some part of code inside client, create security breaches and problem with different browser.
I use only HTML(5) and CSS2/CSS3, and I have a lot successes.
I use this 2 ways:
using "puzzle-techinque". Write a lot of small and simple template (or tiles) to create the big page. I use only JSTL and Spring tag, with Rich/Prime/Ice-faces I encountered a lot of problem with rendering, page building and flow controller, so I discarded them.
using my custom library to parse HTML pages. I create template with my custom grammar, put inside the parser and write on output stream. This is the best way.
If you say me your preferred language and context, I can help you to perform JS-free.
My question concerns Google Web Toolkit (GWT). I'm about to begin development for a project that will reside on an Intranet where some users may have JavaScript disabled. After seeing what GWT has done for Google Wave I've been very interested in learning and applying it to this new project, but if it isn't accessible to those users then I don't think I'll be able to use it. I noticed that the example applications on the GWT website don't work at all with JavaScript disabled. So, can GWT be used in a way where content and functionality is still accessible to users with JavaScript disabled? If not, wouldn't this be a massive oversight by Google?
If it's of any use, this project will be using Spring MVC 3.0 with Hibernate and JPA.
The whole problem that GWT solves is JavaScript and AJAX programming. If you aren't targeting browsers that have that enabled, then GWT is not for your project. I wouldn't say its an oversight at all. Developing a framework that would leave JavaScript optional would either be very lowest common denominator, or very frustrating, as many features would have to be noted as requiring JavaScript.
Q: Can an entirely javascript based framework work with javascript turned off?
A: No
You could of course detect whether javascript is enabled and build an entirely different site for those users, but why bother? Tell them to turn javascript on if they want to use your site. Let's face it 30% of the internet is broken without javascript, and turning it off is very rare these days. That's 90's thinking that is ;)
GWT is a great tool in cleanup the badness of JS that is for certain, but it can't fix the bad developments and the whole world of other bad JS sites. So the cops and govs turn off them perhaps for a reason. The various flash are good looking and very interactive but I always find them over do the presentation as to the content and functionality. The ones that offers both doesn't seems to be very robust.
If you really like GWT and they are turning off the JS for the world, will they willing to turn it back on if the incoming JS contents are striped out at their internet gateway?
GWT: Java->JS "compiler".
So, no.