I'm not a java programmer (I come from asp.net c#) but I'm considering writing a small java application to upload files. In my web app, the user needs to upload a spreadsheet to my server and I want to check the file size and extension before the upload. Most uploader seems overly bloated for what I'm looking to do and I want to build something really simple.
What do I need to do to make this? Eclipse seems to be the best IDE for java. What else do I need and how difficult would it be to write an uploader?
Thanks.
I don't want to steer you away from Java, but you should be able to check file size and extension with javascript. That should only be a dozen or less lines of javascript and should be pretty fast (runtime) since an applet doesn't have to load.
I've been working on REST java ee webservices using Jersey (jax-rs). These allow you to define custom paths, accept and return types (ie text/xml, multipart, etc), methods (GET,POST,etc) and be just about has finely grained as you would like. I haven't done anything with file upload, but I found an example here to get you started. Jersey is a stable, growing, highly-extensible framework (did I mention it supports MVC) and that's why I'm suggesting that you adopt it. Here is a tutorial to get you started with jax-rs, and of course there's always the project site for reference.
Hope this helps.
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.
Are there ways to receive a byte array or string array from the serverside to GWT client and open it as file?
The byte array is already in memory and we don't want to write it to a file in the server and pass the URL back to the client.
Thanks
GWT Java is compiled into Javascript.
So, try writing a Javascript-based app first, to open your server file "as a file" by your Javascript client. Even if you do not know Javascript - then at least, perform a thought experiment:
- What are the limitations placed by the brosers
- Why do browser conventions place such limitations?
What your javascript app cannot do, so too your GWT app.
What you are thinking is to use File IO API to access your files sitting on the server. There are two possible reasons why you wish to do that:
You are familiar with File IO and you want to do on GWT Java what you have been doing for years with Java, and you are too fixated to change your perspective.
You want to write a web-based interface to your operating system, and you have grand plans for your app.
If you are in situation 1, you are lucky. You simply need to change your perspective to respect the asynchronicity and remoteness of thin-client-server communications.
But in the case that this is a Mt Everest that you have to climb and you still persist in trying File IO patterns on GWT, then you need to be prepared for a large project. I am saying "File IO patterns" rather than "file io" because you would have to emulate them. Obviously, browser security technology does not yet allow you to open a file on the browser's system. And for that reason, there is no point for GWT to supply that functionality.
Secondly, File IO belongs to the java.io realm. And again, browser security does not allow you most of the functionality of java.io. Without the set of file.io functionality on GWT, how then can you have File IO.
What you can do is to scale down on your expectations of File IO and write down a specification of what the features of File IO you would like to have. Like, open, close, read, etc. Then you write a some GWT Java classes to let you perform those little tit-bits of emulated file IO.
So just now, I decided to google "GWT inputstream outputstream" and there are some opensource projects out there from whom you could borrow/steal some code to achieve your life long fulfilling goal of emulating client-server file io thro GWT.
But my advice to you is, you should translate your spec of functionality into a REST service. REST is how google docs is accessed. Study google data api and learn how they do it, including the authentication framework.
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.
After seeing some of the benefits of GWT, my partner and I decided that it would be a good front end for the web app we hope to build. A main part of this web app will be content management. We were hoping to use a CMS framework and put GWT on the front end, but all the open source CMS systems we find seem to be very tied to their front end.
Does anybody know of a CMS that would work well with GWT?
I think it all depends on how much integration you want, specifically, what you want to do with GWT. We have successfully integrated GWT with Documentum + Java on the back end.
With that said, our integration is fairly light. The site is largely a content oriented website, but we use GWT to:
Implement certain more dynamic widgets (e.g., text box with intelligent auto completion, font size changers).
Enhance content in the CMS to make it more animated (for instance, instead of displaying lots of content in a single screen, we use GWT's tab panel to display chunks at a time, while still allowing content authors to manage our content).
Implement "mini-apps" within the site.
Unfortunately, since this is something I do for a client, I cannot specifically mention the site by name in public, but if you're interested, I can share some details with you via e-mail.
No, but I can tell you that using a Java based CMS will make your life much much easier. GWT lives on RPC calls, and while translation / JSON overlays are possible, you're much better off with a Java backend.
You mind find this difficult, though, because when you want to use GWT you're doing a massive amount of work on the front end, leaving the backend mostly data processing and storage. Since very few CMSs are designed to do nothing more than processing and storage, you might be better off building your own.
That said, you might find it very easy if you're open to using App Engine. The GWT + App Engine stack works really well, now has a great Eclipse plugin dedicated to it, and is free to get started with.
Try the Nuxeo CMS/EMS, which is implemented in Java. Search google for "nuxeo", and also search for "nuxeo gwt" for a variety of tutorials on integrating GWT with Nuxeo.
First, some background:
I will have to work on code for a JSP that will demand a lot of code fixing and testing. This JSP will receive a structure of given objects, and render it according to a couple of rules.
What I would like to do, is to write a "Test Server" that would read some mock data out of a fixtures file, and mock those objects into a factory that would be used by the JSP in question.
The target App Server is WebSphere and I would like to code, change, code in order to test appropriate HTML rendering. I have done something similar on the past, but the JSP part was just calling a method on a rendering object, so I created an Ad Hoc HTTP server that would read the fixture files, parse it and render HTML.
All I had to do was run it inside RAD, change the HTML code and hit F5.
So question pretty much goes down to: Is there any stand alone library or lightweight server (I thought of Jetty) that would take a JSP, and given the correct contexts (Request, Response, Session, etc.) render the proper HTML?
You need more than a web server. You've got to have a servlet/JSP engine, so there's no getting around that.
Jetty's quite light. Maybe Resin deserves a look, too.
I've never used JSPs, but I have played around with OOWeb. It's definitely lightweight, and follows the request/response model, but you'll be hard pressed to connect it with your JSPs without a lot of glue.
A couple lightweight containers are listed here. It looks like Tiny Java Web Server in particular is actively being developed. Unfortunately there's not much documentation available for it.
jetty and tomcat
those may be not light enough for your tastes though.
you'll find plenty of users and support on SO for tomcat, so that counts for something.
There is none ( afaik ) .
The only workaround I could suggest is to use Velocity instead. But, of course you would have to resign to jsp altogether and that could not the an option.
IF you do then you can isolate your test with Velocity move the result into a web.
Here's an article on how to use Velocity + Ruby ( or JRuby ) for an standalone solution.
http://martinfowler.com/bliki/JRubyVelocity.html