In an interview today I mentioned that I had done some jsf work in a portlet. The interviewer asked for specifics on what the portlet-bridge does. I never looked into it all that much, just used it because I was told it would make jsf work in the portlet. All I could really say was that it allowed the requests to come from the portal to jsf in a way jsf would understand, and made it play nice.
What exactly does the portlet-bridge do?
From the spec linked by Jeremy Walton above.
2.1 What is a Portlet Bridge?
The Java™ Portlet Specification
defines a set of APIs for directly
implementing a portlet. A portlet
bridge is a technology used by a
portlet to bridge to an execution
environment where differing
abstractions are used for rendering
markup or processing user
interactions. Typically these are
well-known, possibly standard web
development environments. Examples
include JavaServer™ Faces and Apache
Struts.
The portlet bridge acts as the
translation engine between the portlet
environment and the targeted system.
It expresses the portlet request
context to the bridged environment,
executes the request and transforms
the response as appropriate for the
portlet environment. It provides an
abstraction of the portlet environment
for the bridged environment, and for
developers working within the bridged
environment. These developers are
freed to execute Faces views as
portlets, without the need to
understand the details of the portlet
APIs and development model.
To put it simply, a portlet bridge is
the technology that allows a Java web
developer to execute views developed
using other web programming
abstractions as portlets without
needing to know and or learn about
portlet development, concepts, or
APIs.
The Portlet Bridge for JavaServer™
Faces is the specific bridge
technology needed to support this
bridging behavior for JavaServer™
Faces.
Related
I was surfing the Internet where I found an article saying that Alfresco is a Content Management Framework as well as App Development Framework. While I understood it as Content Management Framework, I am not able to know about it as an App Development Framework.I tried researching over it, but could not find anything viable.
I want to know that how Alfresco can be used as an App Development Framework ?
Hi Alfresco has an application development framework, more info here:
Guides: https://community.alfresco.com/community/application-development-framework/pages/get-started
Angular 2 components repository: https://github.com/Alfresco/alfresco-ng2-components
Alfresco App Yeoman generator: https://github.com/Alfresco/generator-ng2-alfresco-app
JavaScript API repository: https://github.com/Alfresco/alfresco-js-api
Some videos:
https://www.youtube.com/watch?v=-OFI3izSDdk
https://www.youtube.com/watch?v=kjOgVbINAyU
In case you want a live support you can use the Gitter channel: https://gitter.im/Alfresco/alfresco-ng2-components
Well, if for App is meant mobile application, Alfresco has a Mobile SDK available for both iOS and Android which can help you create your own application to work against the Alfresco Platform.
Moreover there is another framework called Aikau which has one main goal
The main purpose of Aikau is to provide a library of widgets that can be easily assembled into a web application for accessing an Alfresco repository. The aim is not to replace Share but it was necessary to migrate away from its original implementation, which was based around the Surf paradigms of pages, templates, components and web scripts, towards a solution that provided for rapid development and customization.
This feature was first introduiced in Alfresco 4.2 and then extended in Alfresco 5.0
If you want to build applications for Alfresco you have a number of options available to you - as mentioned you can build mobile applications (and there are SDKs available to do this).
If you want to build web applications then you have the option of either customizing the default Alfresco Share client (which is built on top of the Alfresco Surf framework using a combination of YUI 2 and Aikau). Alternatively you can built your own web client by building a new client with the Maven Aikau Archetype.
The advantage of the Surf framework is that it takes care of Alfresco authentication across all the various APIs (WebScript, CMIS, Public API, etc) as well as providing lots of security benefits (CSRF, XSS white-lists, etc).
The advantage of using Aikau is that it provides a large number of out-of-the-box widgets that are specifically designed to work with Alfresco data and address Alfresco (ECM) specific use cases.
You are of course not limited to these options - you can build an application on top of any stack you wish, but ultimately you will want to be making use of the REST APIs that the Alfresco Repository provides.
Depending upon the application you are building you may also want to build custom data models and build in workflow via Activiti BPM as well.
I'm just looking through available technologies to create portlets using WSRP. So we have the following requirements (I'll try to explain so as I can):
backend part: Jax-WS webservices implementation (in fact JPA + some business logic)
frontend: portlets should use Jax-WS webservices and should be exposed through WSRP and consumed in Oracle WebCenter portal
everything should be built via Maven
I'm having troubles with selecting a proper framework for portlet development.
A couple of things which I'm considering:
ADF - has a big learning curve, tightly coupled to Oracle stack, I wouldn't like to use it
Vaadin framework - looks fine, but its latest version doesn't support WSRP Add on, so I will have to write something on my own
There are also a couple of others possible frameworks which I have not looked through yet: JSF, Spring Portlet MVC.
Maybe somebody of you has already used similar stack and can give some advice on which framework is more convenient for portlet with WSRP. I would very much appreciate any thoughts on that.
Thanks in advance
For me I used JSF with JSF-Portlet-Bridge, Struts and ADF
But I always preferred ADF since it gave me a quick way to generate WSRP portlets from Task-Flows.
If you are going to develop big list of Portlets, I'd tell you to consider ADF, even though the learning curve might be steep but it'll be worth it, and you already have knowledge in JSF it'll be an easy task!
We're planning on creating a feedreader as a windows desktop- and iPad application. As we want to be able to show Websites AND to run (our own) JavaScript in this application, we thought about delivering the application as HTML/CSS/JavaScript, just wrapped by some .NET control or a Cocoa Touch webbrowser component. So the task at hand is to find out which framework to use to create the HTML/CSS/JS files to embed in the application.
For the development of the HTML/CSS/JavaScript we would be happy to use Vaadin, GWT, or some other framework, as we're a lot better with Java than with JS. We favor Vaadin after a short brainstorming, as the UI components are very nice, but I fear that most of the heavy lifting will be on the server and not in the client (and that wouldn't be too nice). We would also like GWT, but the Java-to-JS compiling takes a lot of time and an extra step, and slowed down development time in the past when using it.
The question is: which development framework would you choose (given you wanted to implement this project and you mostly did Java so far) and why? If there are better framework options (List of Rich Client Frameworks), please let me know.
Edit: The application will need to talk to our server from time to time (sync what has been read for example), but mainly should get the xml feeds itself. Therefore I hope that most of the generated code can be embedded in the application and there doesn't need to be heavy activity with our server.
Edit2: We (realistically even if you doubt) expect at least 10000 users.
Based on my experience with Vaadin, I'd go for that, but your requirements are somewhat favoring pure-GWT instead.
Vaadin needs the server and server connection. If building mostly offline desktop application, this can be solved with an embedded Jetty for example. (synchronize with an online service only when needed), but for iPad you would need to connect online right away to start the Vaadin application.
GWT runs completely at the client-side and you can build a JavaScript browser application that only connects when needed.
Because Vaadin is much quicker to develop, you could build a small Vaadin version first and see if that is actually problem on the iPad.
On the other hand, if you can assume going online right away, you can skip the local server installation altogether. Just run the application online and implement the desktop version using operating systems default browser control (i.e. the .NET control you suggested). Then Vaadin is easier.
Vaadin is just framework base on GWT but have two very important features:
don't need to run GWT compiler. It is pure java. Of course if not add addons because then gwt compiler must run.
you don't need to write communication code. So you don't need to solve DTO problems, non-serializable object mappings and dont need to write servlets.
I use Vaadin in my work for one year and we haven't performance problems yet (desktop like application with ~500 users). IMO very good solution is to use Vaadin just for UI, logic move to independent beans and connect this two elements using Spring or Guice.
In this case you should use MVP pattern and Domain Driven Development.
Bussines beans is domain objects and logic that use view interfaces to send responses.
Custom Vaadin components (could extends standard components) implements view interfaces.
That way is good when you decide to change UI engine if Vaadin is not for you. Just rewrite guice/spring mappings and write new implementations of view interfaces.
My 3 cents:
If you decide to use vaadin, You will benefit from already GOOD LOOKING components. Since you dont want to write (alot of) CSS , vaadin is already good looking out of the box. How ever, Vaadin is a SERVERSIDE framework. User interface interactions will hit the back end even if they dont involve getting any data (e.g moving from one tab to the other) .
If you decide to use GWT, you will have to atleast style the application (this is not hard) . There is also the problem of long compilation time (but you can test and debug on hosted mode which allows you to run the application without compiling , then you compile only when deploying). The main advantage of gwt is that you control what gets sent to the wire, For UI interactions that dont require getting data from the backend, it will work purely on the client side. You the developer will determine when to send a request to the back end. (Doing RPC requests in GWT is very easy)
Hope this will help you make the decision.
My question is very simple, my intention is to generate a repository with your responses so it could serve to the community when selecting frameworks for developing enterprise general purpose applications.
This could apply very well for general purpose languages such as C++, C# or Java.
What Framework do you recommend for generating Layered Architectures?
Based on you experience why do you prefer the usage of some Framework versus your own architecture?
How long do you believe your selected Framework will stay as a preferred option in the software development industry?
This is indeed an overly general question, especially since there are so many interpretations of the very word framework, and within the world of frameworks many different kinds for different tasks. Nevertheless, I'll give it a shot for Java.
Java
Java EE
The default overall enterprise framework of Java is called Java EE. Java EE strongly emphasis a layered architecture. It's a quite large framework and learning every aspect of it can take some time. It supports several types of applications. Extremely small and simple ones may only use JSP files with some scriptlets, while larger ones may use much more.
Java EE doesn't really enforce you to use all parts of it, but you pick and choose what you like.
Top down it consists of the following parts:
Web layer
For the web layer Java EE primarily defines a component and MVC based Web Framework called JSF - JavaServer Faces. JSF utilizes an XML based view description language (templating language) called Facelets. Pages are created by defining templates and letting template clients provide content for them, including other facelets and finally placing components and general markup on them.
JSF provides a well defined life-cyle for doing all the things that every web app should do: converting request values, validating them, calling out to business logic (the model) and finally delegating to a (Facelets) view for rendering.
For a more elaborate description look up some of the articles by BalusC here, e.g. What are the main disadvantages of Java Server Faces 2.0?
Business layer
The business layer in the Java EE framework is represented by a light-weight business component framework called EJB - Enterprise JavaBeans. EJBs are supposed to contain the pure business logic of an application. Among others EJBs take care of transactions, concurrency and when needed remoting.
An ordinary Java class becomes an EJB by applying the #Stateless annotation. By default, every method of that bean is then automatically transactional. Meaning, if the method is called and no transaction is active one is started, otherwise one is joined. If needed this behavior can be tuned or even disabled. In the majority of cases transactions will be transparent to the programmer, but if needed there is an explicit API in Java EE to manage them manually. This is the JTA API - Java Transaction API.
Methods on an EJB can easily be made to execute asynchronous by using the #Asynchronous annotation.
Java EE explicitly supports layering via the concept of a separate module specifically for EJBs. This isolates those beans and prevents them from accessing their higher layer. See this Packaging EJB in JavaEE 6 WAR vs EAR for a more elaborate explanation.
Persistence layer
For persistence the Java EE framework comes with a standard ORM framework called JPA - Java Persistence API. This is based on annotating plain java classes with the #Entity annotation and a property or field on them with #Id. Optionally (if needed) further information can be specified via annotations on how objects and object relations map to a relational database.
JPA heavily emphasizes slim entities. This means the entities themselves are as much as possible POJOs that can be easily send to other layers and even remote clients. An entity in Java EE typically does not take care of its own persistence (i.e. it does not hold any references to DB connections and such). Instead, a separate class called the EntityManager is provided to work with entities.
The most convenient way of working with this EntityManager is from within an EJB bean, which makes obtaining an instance and the handling of transactions a breeze. However, using JPA in any other layer, even outside the framework (e.g. in Java SE) is supported as well.
These are the most important services related to the traditional layers in a typical enterprise app, but the Java EE framework supports a great many additional services. Some of which are:
Messaging
Messaging is directly supported in the Java EE framework via the JMS API - Java Messaging Service. This allows business code to send messages to so-called queues and topics. Various parts of the application or even remote applications can listen to such a queue or topic.
The EJB component framework even has a type of bean that is specifically tailored for messaging; the message driven bean which has a onMessage method that is automatically invoked when a new message for the queue or topic that the bean is listening to comes in.
Next to JMS, Java EE also provides an event-bus, which is a simple light-weight alternative to full blown messaging. This is provided via the CDI API, which is a comprehensive API that among others provides scopes for the web layer and takes care of dependency injections. Being a rather new API it currently partially overlaps with EJB and the so-called managed beans from JSF.
Remoting
Java EE provides a lot of options for remoting out of the box. EJBs can be exposed to external code willing and able to communicate via a binary protocol by merely letting them implement a remote interface.
If binary communication is not an option, Java EE also provides various web service implementations. This is done via among others JAX-WS (web services, soap) and JAX-RS (Rest).
Scheduling
For scheduling periodic or timed jobs, Java EE offers a simple timer API. This API supports CRON-like timers using natural language, as well as timers for delayed execution of code or follow up checks.
This part of Java EE is usable but as mentioned fairly basic.
There are quite some more things in Java EE, but I think this about covers the most important things.
Spring
An alternative enterprise framework for Java is Spring. This is a proprietary, though fully open source framework.
Just as the Java EE framework, the Spring framework contains a web framework (called Spring MVC), a business component framework (simply called Spring, or Core Spring Framework) and a web services stack (called Spring Web Services).
Although many parts of the Java EE framework can be used standalone, Spring puts more emphasis on building up your own stack than Java EE does.
The choice of Java EE vs Spring is often a religiously influenced one. Technically both frameworks offer a similar programming model and a comparable amount of features. Java EE may be seen as slightly more light-weight (emphasis convention over configuration) and having the benefit of type-safe injections, while Spring may offer more of those smaller convenience methods that developers often need.
Additionally Spring offers a more thoroughly and directly usable security API (called Spring Security), where Java EE leaves a lot of security details open to (third party) vendors.
To specifically answer the second question:
Developing your own framework gives you the burden of having to maintain it and educating new developers in using it.
The larger your framework becomes, the more time you have to devote specifically to it and the less time you thus have to solve your actual business problem. This is okay if your business problem is the framework, but otherwise it can become a bit of a problem, even for very large companies that can dedicate a group of people to such a framework.
If you're a smaller company (say ~15 developer max) this can really become a huge burden.
Additionally, if your own framework is the kind of framework that can take advantage of third party developments (e.g. third parties can develop components for JSF), then your own framework obviously won't be able to take advantage of that.
Unless of course you open source your own framework, but this will only significantly increase the burden of supporting it. Just dumping your source code on sourceforge does not really count. You will have to actively support it. All of a sudden your framework becomes their framework with maybe 'weird' feature requests and awkward error reports for environments that you have no personal interest in.
This also assumes that your framework will actually be used by external users. Unless it's really very, very, good and you put lots of energy in it, this will probably not happen if it's simply the umpteenth Java web- or ORM framework.
Obviously, some people have to take up the job of creating new frameworks, otherwise the industry just stagnates, but if your prime concern is your business problem I would really think twice of starting your own framework.
Very vague question, I'm not really sure it's ever a good idea to "write your own" at this point for a work project (unless writing your own, IS the project). If it's a learning exercise, fine, but otherwise go use one of the libraries written by people who have been doing it far longer. If you really want to get involved, read their code, try and contribute patches etc.
For .Net there is Sharp Architecture Which is a pretty popular framework for layered applications.
Here's some of the stuff I use (I don't use Sharp Architecture)
First, the infrastructure stuff
For Dependency Injection, I use StructureMap. I use it because it's way more robust and performant than anything I would or could write, and it's very well supported within the .Net community. It also sticks to being DI, and doesn't venture out into other things that I might want to use other libs for (AOP etc). The fluent configuration is fantastic (but many .Net DI Tools have that now)
For AOP, I use Linfu Dynamic Proxy. I know a lot of people that like the code weaver variety for performance reasons, but that's always seemed a bit like premature optimization to me.
For a DataMapper, I use AutoMapper. This is one where I'm on again off again. If you can do your mappings based just on convention, then great, I'll use it. Once I have to start tweaking the configuration to do special things.... to me that starts to get into the gray area where the code might be more clear with just some left=>right wrapped in a function.
Web/UI
Asp.Net MVC. Although to be quite honest, I'm having a falling out lately and may soon be moving to FubuMvc. Asp.Net MVC seems like it has split personalities in terms of API design (dynamic over here, static over there, using blocks to render forms, but System.Actions to render other things etc). Combine that with the fact that it's not really OSS (you can't submit a patch), and to me there's a compelling reason why the community should come up with something better that's OSS.
Persistence
NHibernate, Specifically Fluent NHibernate. Sure I'd love to write my own OR/M, but at the same time I'm certain that the hordes of developers who have worked on NHibernate are way smarter than me.
Services/Distribution etc
WCF for Synchronous calls
NServiceBus for Messaging and most async calls.
Most of this stuff is OSS, so how long will it be around, well, I would imagine a good long while.
This question doesn't work very well. Selecting frameworks is difficult, and very context specific. For each selection process you might end up with a simple shortlist and a simple list of questions to answer, but those lists do not transfer well to other selections.
The number of parameters and the parameter sensitivity influencing a decision is very large, and at enterprise level a lot of them are not technical.
Currently, there are no frameworks available that are ready to support these near-term enterprise needs:
the switch for most of the workforce from pc to tablet and phone;
the switch from web client and rdbms to p2p/disconnected based storage and distribution
Can anyone suggest whether "GWT" or "Vaadin" are a better choice to design an application? Also: what are the differences in coding style?
In GWT application logic is normally run on client side. It only calls server when it needs to read/save some data.
In Vaadin application logic is on server side. Client side must normally call server after every user interaction.
GWT advantage:
App logic (replies to user interaction) is faster as it is run locally in the browser. It's also relatively insensitive to bad network conditions. Network is used only when needed (to read/save new data), which saves net traffic (important for high traffic sites).
In this regard Vaadin is slower and introduces a lag in UI interaction which is annoying to user. If network is bad this will show in UI responsiveness.
Vaadin advantage:
App logic is run on the server so it can not be inspected by the user. Arguably (Vaadin claims) that makes it more secure.
A few more points:
A fundamental difference is that in GWT you have to separate your application into Client and Server code, no such distinction in Vaadin. This will affect the architecture of your application.
In GWT client code, you must code in Java, and have a limited subset of language features available (that the GWT compiler can translate into Javascript). In Vaadin, you can code in any JVM language, since everything runs in the server (I'm using Vaadin with Scala). This may or may not be relevant to you.
GWT compilation is VERY slow, although in development mode you have the emulator. This makes production environment updates painful (a GWT application I developed has grown pretty big, and currently takes around 15 minutes to compile).
It's very simple to extend GWT with 3rd party widgets, or roll your own. Creating new Vaadin widgets is more complex.
Another Vaadin advantage: you don't have to design or implement the client-server communication, that's built-in.
With Vaadin you can also use built-in GWT when you want to do something on the client-side. This gives you both simplicity of server-side programming model (no communications, no browser programming needed) with being full control of what happens in the browser.
Differences between Vaadin and GWT:
A) Vaadin includes a server-side development model that:
Cuts number of code lines to half by reducing layers one has to
implement for user interface.
Allows you to use any JVM based language for user interface - Scala,
Groovy
Increases security by keeping user interface logic in the server
Allows synchronous calls to any backend API from the web server
Allows use of any standard Java libraries and tools for UI layer- in
server side architecture applications
Does not need Java to JavaScript compilation step that often takes
time or makes tooling complicated in GWT projects - instead you have
the Vaadin client engine
Provides server push out of the box with no extra code needed
B) Vaadin provides a large set of high level user interface components. For GWT one would need to use commercial Sencha GXT for comparable component set.
C) Vaadin includes SASS based Valo theme engine that makes it easy to build good looking custom themes from your application. Valo is the latest theming for Vaadin.
D) Data binding: Vaadin has incorporated the ability to associate any widget directly to a data source such as database, file or anything else in the server-side. This enables to define default behavior of the widgets to act on data sources.
Vaadin vs GWT
tl;dr
whether "GWT" or "Vaadin" are a better choice to design an application
It is not an “either-or” question.
With Vaadin, you get GWT (or its counterpart, Web Components) plus much more.
Vaadin is a framework for building desktop-style web apps by writing pure Java code on the server-side including declaring a user-interface. That user-interface is rendered in a web browser by Vaadin automatically generating on-the-fly the necessary browser code: HTML, CSS, JavaScript, etc. Business logic executes only on the server-side. User events (buttons clicked, data typed into fields, etc.) on the web client trigger Java code to run on the server side.
How that browser code is generated and executed, and how the client and server communicate, depends on 3rd party technology:
In Vaadin 8 and earlier, GWT
In Vaadin 10 and later, Web Components
Vaadin 8 and earlier uses GWT
Vaadin 8 and earlier was built on top of Google Web Toolkit (GWT). GWT has been spun-out of Google, as a fully open-sourced project: http://www.GWTProject.org/
GWT cross-compiles Java code into standalone JavaScript files. GWT provides other important features such as support of UI components and client-server communications.
The Vaadin Ltd company is a major supporter of GWT, including having hosted GWT developer conferences, and providing consulting expertise services.
Vaadin is only one of many products built on GWT.
Vaadin 10 and later uses Web Components
Vaadin 10 and later, known as Vaadin Flow, is a major rewrite of the framework. Instead of using GWT underneath, Vaadin Flow is built on top of Web Components technology.
Web Components is actually a suite of technologies including Custom Elements, Shadow DOM, and HTML Templates. These technologies are now built into most every modern web browser, and supported on many older browsers via polyfills.
Writing a new widget component for Vaadin is much easier with Web Components than with GWT. And most any existing Web Components based component can be wrapped to provide access via Java from the Vaadin server-side framework.
I don't have a source at hand to cite, but as I recall, Web Components based widgets may run faster and use less memory than their GWT-based equivalents.
By the way, both generations of Vaadin depend on some other technology, such as the Atmosphere library for help with WebSocket and HTTP.
I haven't tried Vaadin. I'm a GWT fan, but I CAN say that I've been a bit disappointed by the default widget set provided with GWT. You really need something like SmartGWT to fill the framework out.
I belive Vaadin is a much more advanced framework than GWT
BUT
When it comes to optimise performance on the client side there is nothing much you can do unless you build your own components (and that's where the beauty of Vaadin stops)
In a project i'm working right now 90% of the staff I've done worked as a charm
And then I had to use an event timeline next to a couple of tables. When I loaded more than 400events on the timeline my web page was almost unusable not to mention terrible slow on initialisation. I've been trying to optimise the code the last two months. At the end I used a GWT component.
As any application has to show display information coming from the server, a major requirement for simple coding is automated data binding to your forms and tables.
With Vaadin, this is as simple as a few lines of code.
In GWT, first you have no table mapping.
As for forms, you can map an object to a form, but to do so you have to implement a so called GWT Editor for your object (and one for every object inside of it). An Editor is nothing else than the definition of the form to use to show/modify the object. So all in all, there is no automation here.
GWT enables you to write web-clients with Java. The GWT cross-compiler creates JavaScript code for the client-side. You have to care for the server for your own as well as client-server communication. The generated client-code is already optimized for many browsers. My personal opinion is, GWT was very popular until Google focused on Angular. Today it is not much popular anymore.
Vaadin provides two different solutions:
1) a UI widget-set based implementing the web-component standard, and
2) the Vaadin serverside Java framework. It allows you to write web-clients with Java. However, Vaadin generates the web-client through runtime on the server dynamically. Vaadin cares for the entire client-server communication. For rendering the UI, Vaadin until version 8 used a pre-compiled UI widget-set. Vaadin from version 10 uses the Vaadin web-components.
Further benefits of Vaadin:
You do not get in contact with HTML and JavaScript and you need not bother for DOM manipulation, browser history and other low-level problems
The serverside architecture provides better security
Modern themes
Individual styling with CSS
RapidClipse provides a powerful UI builder for Vaadin based on Eclipse containing a Vaadin <> JPA databinding, internationalization, UI persistence, extended Hibernate tools, JPA-SQL query language and MicroStream integration for creating Java in-memory database apps and microservices