I have a application developed based on spring web flow framework. In my application i need to display some advertisements for that i opted for OpenCMS. But Integration of OpenCMS into my application im unable to do that. All available tutorials are like integration of web applications in OpenCMS. Here my requirement is reverse. Any inputs for this will be grateful.
Here some queries i want to know.
Can we Create webservice in the OpenCMS?
Can we call that webservice from my application jsp page?
Any inputs will be grateful.....
Thanks
Eventually a duplicate to Integration of Java application with OpenCms, however the question there is the other way around, how to integrate Spring into OpenCms.
Yes, you can implement web services within OpenCms, you can basically do anything within OpenCms that you can do with Java, JSP, Servlet technologies. You can deploy your own custom jars, taglibs, implement RESTful services, etc.
I think it would be good to explicitly know your difficulties or question in the very detail.
I mean, if you just want OpenCms to act as a web services back end, then it's not 'real' integration, then it's pretty much loosely coupled. Then, you just handle OpenCms as any other web services backend, not much difference. And this way would be pretty easy in terms of 'integration'.
Then, you would let OpenCms return json or xml, instead of html, by creating the templates and assigning them to your resources (i.e. structured content in OpenCms, using cms:contentload tag, but outputting json). That's "basically it". Therefore, not clear where exactly you're currently struggling within OpenCms, please let me know some more details and the current status of your OpenCms setup, experience, etc.
Related
I have an application currently running based on servlets (app server glassfish). External applications make an HTTP call to that servlet and get response once successfully achieved what its designed for.
I need now to shift the whole application to JSF2.0 as it needs a front end and sticking to servlet/jsp is not an option.
My questions are:
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
The way how you described the old application sounds much like a web service.
JSF is a component based MVC framework, not a web service framework. So JSF is basically the wrong tool for the job. If you want to continue with the standard Java EE stack, look at JAX-WS (SOAP) or JAX-RS (RESTful) instead. The latter is "the" standard web service framework these days.
See also:
Servlet vs RESTful
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
Like BalusC said, JSF is not exactly what you need and is not designed for what you intend to use it for, webservices are. That being said, you could achieve your goals using JSF if developing an effective web service is not in the cards for you ,either because of a lack of technical expertise on your team or the time factor or other technical constraints require you to serve your customers via a webapp (I honestly can't think of any but hey, you never know)
That being said, I'm assuming you already know your way around JSF2: take a look at this answer to a question somewhat similar to yours. Ultimately, since you're in the Java EE 5-6 stack, I'd strongly suggest you begin work on developing webservices (for basic requirements,they're fairly straightforward to develop). You can download a tutorial here or use oracle's tutorial
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
Unless you give us your specific use case, there are very few and far between reasons maintain a servlet within a JSF app. Yes, application,session and request scoped beans are accessible from within a servlet. They're simply stored as objects within the scopes they're named for, application scoped beans within the applicationScope, session scoped beans within the session and request scoped beans within the request.
You may use your JSF webapp to serve low level http requests, but it's a square peg in a round hole chief.
I have to develop an application which takes XML reports stored in File System parse it and put it into database and display the reports by querying the database in various MIME types(XML,JSON,RSS and HTML). So what I have done till now is parsed the XML reports in the file system ,setup schema for database in MongoDB,put data in database using Spring-data and also managed to have a web service which shows rough draft of reports in XML,JSON and RSS feed.Now I want to display the reports in HTML as well and my supervisor suggested me to use Backbone.js to dispaly it in HTML format by calling the web service.Kindly advice me to choose b/w Backbone.js or write another Spring MVC web service which generates reports in HTML.
Thanks in advance
Swaraj
What you are asking are two different things and choosing between them.
You have to know what your overall objective is with the webapp is and what framework is best for it.
Short answer, Spring MVC integrates with Dojo.js right out of the box, which might do what you need to do, but since your supervisor is suggesting otherwise your options are:
Use Spring MVC to construct and display the data in the HTML using what ever render of your choice.
Or
Build out your Spring MVC wepapp API so that you can use a JavaScript MVC framework, such as Backbone.js or one of the many others (see TODOMVC for samples), to interact with your spring controllers.
Option 1 might be easy enough, used in conjunction with JavaScript or jQuery and plugins
Option 2 would be good if your webapp is complex and will be mostly a SPA (single page app) that utilizes a lot of JavaScript and you want a way to organize your js code better. See JavaScript MVC diagram for an example of how it works.
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.
Background:
I am an intermediate web app developer working on the .Net Platform. Most of my work has been defined pretty well for me by my peers or superiors and I have no problem following instructions and getting the job done.
The task at hand:
I was recently asked by an old friend to redo his web app from scratch. His app is extremely antiquated and he is getting overwhelmed by it breaking all the time. The app in question is an inventory / CRM application and currently each customer requires a new install of the app (usually accomplished by deploying it on a different domain on the same server and pointing to a new database).
Currently if any client wants any modifications to the forms such as additional fields, new features, etc my friend goes in and manually adds those fields to the forms, scripts, database etc. As a result all installs of this application are unique. There is no one singular source repository and no one single version of this app. Generally new features are overtime rolled into the other sites, but still this is done on an individual site by site basis.
I will be approaching this on a very modular basis. Initially I will be coding a module that will query an external web service for some data, display and store it, and periodically update it automatically. The next module will likely be for storing and displaying inventory data. This way I want to over time duplicate the current feature set of his app 100% but do it incrementally.
The Million Dollar Questions
I want to make the app have user
configurable form fields. The user
should be able to go to an admin
page, create a new forms page of a
certain category, and then specify
what fields he wants in there. He
could say 'create a new text field
called Item # and make it a
requirement" and that will get
stored somewhere. All forms will be
dynamically rendered to screen based
on what the user has configured. Is
this a good way to go about the
problem of having no idea what a
customer could want in a form? and
thus be able to store and display
form data of any sort ? What sort of
design pattern should I follow here?
I am familiar with asp.net and
the .net framework in general and
have decent knowledge of javascript,
html, silverlight, jquery, c# etc
etc. I can work my way around web
apps in a good way, but I am not
sure what sort of framework or tech
I should use to accomplish this
task. Would ASP.net 3.5 webforms be
the way to go? or should I look into
ASP.NET MVC? Do I use jquery and ajax for
complete decoupling of frontend and
backend ? or will a normal asp.net
page with some spattering of ajax
thrown in working with a codebehind
be the order of the day?
Just looking for general advice before I start.
I am currently thinking of using ASP.NET 3.5 webforms, jquery for clientside animation, ui, manipulation and data validation, and sqlserver + a .net or wcf webservice for backend.
Your advice is much appreciated as always.
I've recently implemented a white-label ecommerce system for an insurance company that allowed each partner to choose their own set of input fields, screens, and order the flow of the application to suit their individual needs.
Although it wasn't rocket science, it added complexity and increased development time.
Consider the user configuration aspect very carefully In hindsight both my client and their clients in turn, would have been happy with a more rigid system.
As for the tech side of your question, I developed my project in VS2005, using asp.net webforms and webservices with a SQLserver back end, so the stack that you're looking at is definitely capable of delivering a working product. ASP.net MVC will almost certainly help as far as testability goes.
The biggest thing I would change now if I was going to start again would be to replace the intermediate webservices with message based services using nServiceBus, MassTransit or the like. While the webservices worked fine, message based communication should be quicker and more reliable.
Finally, before you start to code, make sure that you understand the current system's functionality inside and out. If the new system doesn't do something that the old system did, it will be pretty obvious to the end users straight away.
I am really having a problem about what to use as an alternative for web flow. I have read that not all functionalities should be handled by web flow. Only those which needs complex xstate management. For those easy stuffs like just login, editing or deleting records what will I use as an alternative for web flow?
Spring Web flow is specifically designed to implement complex page flows. It is an extension of Spring MVC and a tool to specify page navigation rules and manage navigation.
Spring Web flow provides fundamental answers to the following major problems in web application development:
How to specify page navigation rules?
How to manage navigation and conversational state?
How to ensure modularity and code reuse?
It is also integrated with JSF component model and used mostly for enterprise application development. There are not so many alternatives but but for Vaadin component model you can consider Lexaden Web Flow as possible alternative.
How did you build websites before Web Flow?
My understanding is that if something needs "back" functionality that has state information stored - like a "wizard", for example - Web Flow is the way to go. If you don't have state, I'd expect you'd build those pages as you always have.