I am experimenting with OpenDolphin after a while of being interested in it's concept,
I am at the defining requirements phase with some friends for a project we want to make with hopes of earning some money from it this project's concept will be based on a server/multiple-client model where we want the server to have most of the logic, we have average to little experience couple of years each doing java projects but not anything big or exactly with the latests tools, so we struggled a little bit understanding the building process of the gradle setup, and after running this project, we are now faced with tons of groovy projects demos.
And I am struggling to keep my friends interested in the library as they think using what we know best is a better option than trying to understand a library that would mean to learn asap a new language
(we are not that lazy but there is some people that is helping us as consultants/associates and we are afraid that if we dont start producing something we are gonna lose their support [we are not earning anything from this yet but without them as "productowners", we wouldnt know what are exactly the market needs]).
I have watched multiple videos and videos like this: http://www.youtube.com/watch?v=z54hEJvpZys
are amazing , I think that is exactly what we need.
I would like to know if maybe there is an example/tutorial in java maybe a screencast,blog or recorded webinar of how to make a simple application where the server binds to a port and multiple java clients update the value and sends a pair of commands.
I dont know something like server starts, puts a default value in a variable, client connects and sees value, second client connects sees value, and a command is sent to server "erase", and both clients see that the server erased it and another command is sent "default" and server sets variable to default.
I am not asking for that exact example but something that I can read to make it like that.
I tried making something like that using the .8 release and I was utterly lost, but i think that an easy example like that could help me to make them see how good of a tool this is,
"Install this in your laptop, that's the server run it and see how my client and yours are synched automagically".
Ok, you made a good choice of technologies :-)
It appears that the Dolphin JumpStart project (https://github.com/canoo/DolphinJumpStart) covers exactly that combination: OpenDolphin with Java, view in JavaFX, built with Gradle (use dist/jumpstart-gradle.zip) and jetty as the minimal server implementation.
The Jumpstart project is also explained in a step-by-step fashion as part of the OpenDolphin user guide (http://open-dolphin.org/download/guide/guide/howto.html).
Concerning your question about the shared tacho demo: this demo is using only one server that all clients connect to. The "clients" update each other over the server-side event bus. To that end, we do not open any specific sockets. It is all plain HTTP POST that goes trough all proxies and firewalls and needs no special infrastructure.
your concerns are very understandable.
First let me clarify that you can use Java, Groovy, JavaScript or any other language that runs on the JVM with OpenDolphin. What would be your preferred language for a demo?
For a demo that shows many clients that share a common value, I would recommend the SharedTachoDemo.
As for making the build setup easier, we do have to make choices in the demos since there are so many combinations of build system (ant, maven, gradle), structure (all-in-one, multi-project), implementation language, IDE integration (intellij, netbeans, eclipse), server infrastructure (jetty, tomcat, grails, glassfish, jboss, weblogic, webshpere, ...), and last not least the intended UI toolkit (Swing, JavaFX, HTML5, others). If you tell me your preferred combination, I can point you to the respective resource or create one for you.
cheers, Dierk
Related
I did a pretty fair bit of scouring, yet could not find anything useful which answers my questions. Either that or I am asking the wrong questions.
I am trying to make a web application which gives a user a graphical view of the server desktop. I have understood that somewhere in here X engine has to be invoked and I have also understood that this is not something that php can accomplish primarily because its a language which processes before sending requests, please correct me if I am wrong in this regard.
You may say that what I am trying to accomplish is something akin to what teamviewer does only on the web. My dilemma is whether I should be using python or java for this task, both would be pretty apt for the task, but which one would be better?
Please give your suggestions
To allow the user to interact with the desktop in real-time, you need to run the application in the users web browser. Interaction with a webserver would just be too slow to do anything meaningful. I do not know about any way to execute Python in a web browser, so I would rule it out. Some of your options for client-sided code execution are:
Javascript (the recent addition of Canvas and WebSocket made it suitable for this kind of problem)
Java Applets (felt out of favor recently due to security problems)
ActiveX (IE- and Windows only, very rarely used in a public context nowadays)
Flash (a popular but dying technology)
I am developing an client-server application where client gets updates every second (lets say 1000 fields) . I also need to draw waveforms from at client side.Server is already existing.
For this type of application which will be better ? GWT with intermediate server or Java Web Start which directly connects to existing server in terms of performance, difficulty to code ?
I don't see that much difference among them. I'd even say that they are separate things. Webstart is how your client will get the app: from some site.
Webstart is a bit easier to mantain, since your client will get it everytime it starts.
Deploying a stand-alone can be a bit harder, depending on your infrastructure.
Performance: just the "download" part of the webstart can be a bit heavier. I thinkg performance is almost the same, after ir began to execute.
Difficulty to code: it's just a matter of experience. Your code in both them will be almost the same, since they'll do the same things.
Mantain / upgrade : easier to mantain and upgrade the Webstart than installing a client on each machine.
Consider using a JFreeChart DynamicTimeSeriesCollection, seen here, distributed via java-web-start. A thousand fields in a scroll pane is possible, but JList or JTable would be considerably more efficient.
If the server already exists, the issue is more about the best way to connect it to the client, than whether or not to use GWT. For example, if you want server-push rather than client-pull for the updates, that changes things somewhat. However, assuming you need to do some vector graphics, and pull information from a server (I'll assume that you can use either JSON or XML to get server information), you could use several different JavaScript toolkits to do this directly, without Java or GWT needed at all.
For this type of application, Dojo would be one fair option. It has fairly good portable vector graphics, it's pure JavaScript and it is finally at a stage where documentation is OK. GWT would be a useful bet if the server didn't already exist, and where you wanted a decent set of controls usable on the client side. But for rich graphics, I'd look at JavaScript options like Dojo, Raphael, or even jQuery. Dojo does support line charts, and that might be a good basis for waveforms.
Some of this depends on the nature of the server. If it uses a different protocol from HTTP, or doesn't really provide easy JSON or XML access, you're probably better looking at a client-server package that does make the bridge between client and server simple.
GWT might be an option here, but it is designed more for robustness than for very fast development. And if you are fitting with an existing protocol, it could be a fair amount of work.
I've tried searching for similar questions here and I don't think I've found anything that matches what I'm looking for. I would like to know where to start in developing a (most likely) database-driven Java application that could keep track of customers, invoices, and quotes for my dad's auto shop. There will be a couple computers in the shop that will need access to it.
I was thinking of having a server in there to handle the database and let whatever machines need to access it use a client app.
Almost all of my experience is in a LAMP environment but I have been trying to learn as much as I can about Java and feel pretty comfortable playing with it in Netbeans or Eclipse.
I'm not asking anyone to tell me how to make it or anything. I would just like to know where to start learning. Is MySQL a good match with Java or should I use something else? I've been wanting to learn Java and I figured this would be a good project to learn on but everything I read seems to give only bits and pieces of what I want to know.
Java and MySQL work well together. Here are some things I would recommend to get started:
JDBC (Java Database Connector) - use it to connect to MySQL
Swing programming - used to create the GUI front end that users will interact with. While NetBeans has a drag and drop GUI builder interface, actually understanding what's going on under the hood is very important.
GlazedLists is a great project for showing dynamic content in table format, such that you can easily filter, sort, etc. Given you will probably have table views of customers, etc., I would look into this
If I were you I would definitely set the bar a little bit lower and try some easier projects to start with (ones that do not require database connectivity, for instance). Once you're a little more advanced with Java, then I'd start work integrating a MySQL table with your app.
I think that most of the answers to this question will prove useful as a starting point
You'll never find a complete subject list to learn java or any other tecnology, I suggest that you should start by writing down the requirements for the project and start "trying/failing" at what you want to do. Bits and Pieces are a very good way to learn.
You could try building different test applications, to get the feel of java, and slowly start using all parts needed to build your application. Common concepts used in small database-driven Java applications are:
JDBC, a java database connector
A client/server architecture (needed if multiple clients need to keep their data synchronized)
Synchronization
A swing GUI
A learning path that worked for me was:
Build a command-line driven java application
Build a test application with a graphical user interface (GUI).
Build a test application with a client/server architecture, but with only one client
Build a test application with a client/server architecture, connect multiple clients and keep them synchronized.
Build a java application with a JDBC database connector, set up a MySQL server and connect the server in your client/server architecture to it.
You can search for each of the concepts on the internet. It should be easy to find tutorials that will teach you how to use them.
MySQL should work well with Java.
In any case, if you use JDBC (a generic API to access SQL databases, part of the standard Java library), you should be quite independent of what underlying database you are using (apart from vendor-specific SQL extensions).
Suppose i have one website with simple pages in php like
page1.php
page2.php
Now there is one page where i want some detailed functioning and i want to use python for that and it will look like
page3.py
and in other page i want to use java like
page4.jsp
Provided i have installed python , java on webserver.
Is it possible?
Yes. It's possible. Where you will find yourself in trouble is when you want to share server-side information among them (I.E. sessions).
Other than that, you can use (but I would advise against it) all languages you want on a website.
Yes, it is possible, but you definitely should NOT do it.
Communication between pages running different technologies will not be elegant, if for no other reason than the fact that you won't get a shared session pool. Session bridges are possible, but they are a pain to do.
I would say you are making a mistake if you can't just pick a single language for your core web layer.
Yes it is very possible, as long as the server can serve the files you want to use. If it doesn't have python, you can't use python.
It depends on the web server. Apache can do it. Just make sure you have the appropriate handler modules for each file type, and use the AddHandler configuration directive to map each type to the appropriate handler.
Also, to be pedantic, you can not only use all three of those, but you can actually integrate them at the session level, since all of those languages are available on the JVM. So, in one container you can run all of the PHP, Python, and Java code. You can share session state, reuse connections to the database (via server wide connection pools), leverage Java libs in your PHP and/or Python code, etc.
I'm not saying this will be "drag and drop" easy, but it is possible, and even practical if you need that kind of close integration (vs integration via a database or filesystem). There will likely be nuances in ensuring that the Python and PHP code runs properly on the Java implementations as well.
Short answer: Yes, many web servers can handle generating pages from multiple languages.
People are talking about session...
Almost all server side technologies today support custom session providers, where you can hook up some code to share you session between different HTTP modules and binders.
If you are starting to write a web site from scratch, and you need to write all of your code for yourself, than probably you will choose to do it in one programming language (only for your comfort of coding).
But... where it's all starting to change? When you want to mash-up some open source and community source code to make a web site. Let's say a store & community with ASP.NET to mix up with CRM like Sugar CRM (which is in PHP).
In that case you don't need any session sharing, just users sync procedure in the DB.
Also, if you choose IIS 7 (Windows Server) or Apache (using Mono project you can run ASP.NET on LAMP), you could run them both on the same machine.
And remember, the most important thing is TIME TO MARKET! So saving code time can be crucial for you success.
ENJOY!
I work for a PHP development company and all the time these ASP.Net companies come to US for whatever reason I've never understood. We build them forms in PHP usually dynamically pulling in the layout - sometimes hosted on a subdomain, sometimes hosted directly in IIS with the PHP module. Its very messy and bad, it can be done but I'd say avoid it.
You can use Apache Reverse Proxy to do it and session must be readable between programming languages. I use Go, NodeJS and PHP in one website. Session is saved in Postgresql. The hardest part is all programming that is used in your website can read session with same format and saved in same place. I have used github.com/yvasiyarov/php_session_decoder to read and save session with Go and save it in Postgresql so PHP can process that session
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 9 years ago.
Improve this question
I've just stumbled upon the following new java web framework: Play
http://www.playframework.org/
http://www.playframework.org/documentation/1.0/home
with such a stunning list of features, I'm pretty much surprised I haven't heard of it before...
Sounds like the java web development promised land...
has anybody tried it? any real experience with it? do you think it's worth studying it?
I agree with Jason that Play might just prove to be better than Grails. With four Grails projects under my belt (preceded by two Tapestry projects and one Wicket project), I'm seriously looking at Play next.
One of the things I thought was cool about Grails is that "everything's Groovy." That is, you use Groovy to write everything (except the HTML and the CSS) -- domains, controllers, services, page templates (GSP), tag libraries, Hibernate API (GORM), unit tests (GUnit), and build scripts (GANT). You can even write shell scripts in Groovy. So, being able to code all aspects of an app using a single language again seemed like a simplification that was long overdue -- hearkening back to the days of writing desktop apps in a single language like C++ or Delphi. However, I've learned that one size does not fit all here.
For one, the IDE support for Groovy isn't great. IntelliJ does the best job, but with Groovy being dynamic, it can only go so far. The refactoring tools do not (cannot) catch everything, so you can't trust them 100%. This means you have to be especially vigilant with unit testing. Here again, because Grails relies so much on dynamic "magic" that happens at runtime, the unit testing in Grails must rely on an extensive mocking layer to emulate it, and that mocking layer is quirky. A third issue is that much of the so-called Groovy code that you're writing is actually domain-specific-language (DSL) code. (To make a long story short, DSLs are short-hand Groovy, taking advantage of the fact that in Groovy and lot of the syntax is optional.) Grails uses different DSLs for various configurations, URL mapping, etc. and it is inconsistent. How you specify log4j settings, for example, looks nothing like how you specify the data sources, and neither looks like the pure Java upon which Groovy is based. So, the promise of "everything's Groovy" falls apart anyway.
That being the case, I see where the Play team is coming from.
Going back to regular Java for the domains, controllers, services, and JUnits makes sense. Strong typing means the IDE can reliably help with inteli-sense, code navigation, refactoring, etc. (And thus you don't need to pay for IntelliJ if you're happy with Eclipse.) Having to write more verbose code in order to gain back strong tool support seems like a good deal to me right now. We'll see.
I like that I still get to use Groovy in the page templates. I'm afraid I may end up putting more code in the templates than I should, though.
I have no experience with JPA, but it seems like it's pretty close to what GORM does for me, so that's cool.
The Spring IOC support in Grails is completely transparent whereas Play's support seems minimal; however, I think that IOC is way overused and I'm perfectly willing to hand code a Spring XML mapping on the rare occasion that I really need one. (One of my open questions is that I'm assuming that JPA has transaction support which is why Play doesn't need Spring for that like Grails does, no?)
I've never been a fan of Python, so I cringed when I read that Play uses Python for its build scripts. But I agree that Grails' GANT scripts run pretty slow. Plus I find that, while GANT is a huge improvement over XML ANT, it's still hard to wrap your head around the ANT concepts. The Grails GANT scripts are pretty convoluted. So, I'll go in to it with an open mind.
The Play "application module" model sounds to be just like Grails' "plugin" model, so that's cool.
I'm quite impressed with the Play documentation that I've read so far. I had a huge number of questions going in, but half of them were answered right off the bat.
I'll report back again later as I dive deeper in.
I've tried Play and I'm impressed: it does a great job of delivering a useful development model that is far simpler than most frameworks'. More than anything else, the runtime's ability in 'development mode' to parse .java files directly is worth a lot: just reloading the web page in the browser without running a build script or waiting for a redeployment is worth a lot of development speed. The error messages shown in the browser are really good too.
Another thing that impressed me was the overall aesthetic: it is perhaps a small thing that the tutorial application actually looks good (both the code and the web page design), but this extends to the whole framework, the API as well as the documentation.
After prodding from a colleague I looked at it, followed the tutorial, and got hooked. Getting immediate feedback right in your browser means you don't have to use an IDE. I love Eclipse, but let's face it: after you've added some extras, it's not as stable as a simple text editor. On a Mac with TextMate you can even click on the error message in your browser and TextMate pops up with the cursor on that line.
Testing in Play is also nicely done, with one button press you run unit tests, functional tests and Selenium-based tests.
Play is exciting because it's still small and uncomplicated. It uses just ant to build and does so in 25 seconds. Contributing to the beautiful documentation is a matter of editing the .textile files and reloading the docs in any play app.
That's how I wound up on a quest to translate the tutorial to use Scala, adding to the Scala support where needed to get it as nice as possible.
I like it, I'm using it for small projects and so far it looks perfect for the job.
However, there's one thing I miss very much that's been left out on purpose: Service/DAO/Model layers separation! Documentation says it clearly, one of the goals of Play is to avoid the "Anemic data model":
http://www.playframework.org/documentation/1.0.1/model
but in my experience the classical Service/DAO/Model layers separation saves tons of development time when the application needs to be refactored! With Play you're stuck with static methods that rely on Play-specific transaction management and peculiarities...
However, many thumbs up for: development speed, code cleanness, and in the end... fun!
I've used Grails, Tapestry 4/5 and straight Java/JSP/Spring/Hibernate.
I think this is going in the right direction for the first time in a long time. Grails was a really good first step but Play! looks like something that could really have legs. Scala support is coming in 1.1. If there is a chance I can write my controllers/domain in Clojure, I'm sold ;)
Since one year and no visible bug after 18 small releases, we use Play! 1.2.4 in a production "absences" intranet application for a school (actors: >100 teachers, > 700 students, administrativ team). Client side has been written with FLEX 4.6 from Adobe (very beautiful views). Data are send and receive in AMF3 format (Cinnamon module). We use a own simple dao layer based on JPA EclipseLink and MySql for the DB. Application is stored on a Linux virtual server. I'm a very fan developer of Play for its simplicity and its very productive approach.
I like the look of Play, but haven't tried it. From scanning through the docs one thing that stood out was the heavy use of static methods. From a unit testing point of view this always makes things much harder (I'm thinking mocks), and is a departure from the OO-everywhere approach in typical Java development. Maybe this is the point, but it's just something that made me a little less enthused...
I currently build web applications at work using play framework which does massive data processing. I must say that the speed that play offers alone is significant and more than what RoR can provide. Besides, play is a java based framework and hence Multi-Threading can be done easily. Next is the sheer performance you get when you use java-based modules like Japid and Netty along with play.It's like an endless amount of tweaking can be done for performance. A must try in my opinion.
I'm using Play in a small project, and seems to be exactly what they've said about. But one feature I think should to be present by default in the framework: ability to work with more than one datasource (e.g. use more than one database schema). This is the only missing feature I've found until now.
Regards,
Uilian.