Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

So I'm not sure if this is really the right place to ask or even the right question but I want to give it a try.


We should have a database & webservice (or something similar) which runs in OUR office, clients cann access the application via the internet ("wohooo"). Clients must be able to create orders in a simple mask. There is a basic mask (which all clients have), but the mask can also have some client-specific stuff. When they created the order, a label with a barcode (which contains the order number) is printed locally (and automatically) at their office on a label-printer. They take the label and put it on a sample, which they then send us (on the real post-way). We get the sample, scan the barcode on the label and the order appears in our "administration-screen". We then have every information we need about the order (and the sample). Surely we also need a backend where our staffmembers can edit the client-specific mask and add some fields (for specific-clients) and other master-data.

All in all this doesn't sound too complex. The only thing which stands out a little, may be the automatic print of labels at their place I guess. Because of this reason it may not be possible to use a "server-side only" architecture (like jsf or spring with jsp and so on), because you have to have access directly on their local printers.

So I thought a good way is maybe to use spring (with Hybernate, JavaBeans (JEE)) together with JavaFX which would allow to access local printers and so on. I thought we could just make a webinstaller/webstart for the application, which installs the JavaFX clients for the clients. The JavaFX client could then communicate with the webserver (spring) and insert the order there, get all required information like the order-number for printing the label and so on. For the backend in our office I could also imagine to use JavaFX...

So where's my question?

Well its simple: Is this a good way to do it? Are these fitting technologies for doing it? Or is it already to complicated and this could be accomplished in a much easier way? If so what do you suggest?

Naturally I also want to lay a big focus on easy extensibility and maintainibility.

share|improve this question
I have no experience with cloud print from google but it may be of some use to you. –  Mike May 30 '13 at 14:57
Can you just display the label in a web page for the user to print? –  kevin cline May 30 '13 at 15:19
ideally it would print in background. but you mean, I could show it to the user and put a "print" button there, so he can print manually and I wouldn't need any "client-javafx", but could do it with jsf (or something) similar only? –  OschtärEi May 30 '13 at 17:13

1 Answer 1

up vote 1 down vote accepted

Do all clients have a label printer? Is the only way to be an effective client is with a label maker?

Can you just as easily scan a plain old sheet of paper with a barcode that might be included or contained with a packing list that a client would include in their material shipment to you?

In any case, a special client side solution beyond browser HTML/CSS/JS would probably not be necessary from what was described here.

  • A bar code can be generated dynamically on the server side.
  • A recommended packing list that includes the bar code can be sent to the browser as accompanying documentation with their order receipt.
  • A browser can be coerced to automatically suggest a page be printed. The page could be an order receipt (which includes the recommended packing list with bar code). The user still has to choose to proceed with the print job, but are not obligated to.
  • Provide a facility to view and reprint past/recent/last order receipts (including the recommended packing list that contains the bar code) in case a user unknowingly cancels the first, workflow induced, prompt to print. Printers can be problematic so having a recovery opportunity is a good thing.

Perhaps there are other features that necessitate a particular client side solution, but so far, I do not see it.

share|improve this answer
I have exactly the same thoughts on this. And yes all clients WOULD have a label printer... but yes I also considred just presenting them the label and the order and let them decide where to print. The only thing is they HAVE to hit "print" themself ;) but the morke I think of it the less I think it's worth the trouble....Just as a side note: You'd also think spring would be a good solution? –  OschtärEi May 30 '13 at 18:30
I don't have enough information on what you are doing to say yes or no to whether Spring makes sense. Spring is a fine, robust, mostly stable, generally well supported set of libraries, but it is also fairy heavyweight with its own set of limitations. It is a solution for many, but until you have a better idea what you want out of it, I guess I wouldn't dive right in. –  JustinC May 30 '13 at 18:48
Well the first part of the implementation, is only the thing I wrote. But it may be (I don't know that yet) possible that in the far far future it will be extended to a fully featured LIMS (en.wikipedia.org/wiki/Laboratory_information_management_system)... that's primary why I'm considering spring. –  OschtärEi May 30 '13 at 19:11
Integration with [lab] instruments makes it a bit less straightforward. If the instruments come with their own logging and reporting package, you may eventually only need an 'upload' or 'monitor-and-sync' capability, which still makes the question of a thicker client lean towards the nays. If the instruments frequently do not have a friendly logging or reporting facility, a thicker client might be particularly useful. Factors of usefulness and costliness of the logging and reporting package weigh into the equation too. Again, something that you may want to look at a bit closer. –  JustinC May 30 '13 at 19:24
Thank again for your thoughts. I see your points. Will mark your answer as correct soon (just want to see if others have something to say, and when not marked answered they are sometimes more encouraged :) ) –  OschtärEi May 30 '13 at 19:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.