It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
When I create a servlet application, I deploy the war file on the app server and hit the servlet url and provided there is a proper mapping, I will get to my page.
Now if it is a portlet application, just deploying the portlet on the portal server does not do the job. We also have to login to the portal, and basically 'add' the portlet by going to 'manage pages'. What exactly are we doing in this step? And why is this step necessary? We do not need to do this for a servlet application.
My other question is that in a portal server, there seems to be two kinds of admin consoles...one which resembles a standard WAS admin console. The other is where you Manage pages and do other kinds of stuff. Why do we have two kinds of consoles?
Is it just that the added functionality could not be designed into the standard WAS console because IBM wanted to reuse WAS console for Portal server?
The first thing you should probably understand is that portlets are not servlets. Even though, portlet containers may use servlets underneath portlets (which I'm not even explicitly sure about), the programming model is different and you will need to mindful of that when designing and implementing solutions with them.
Portlet applications can be directly referenced by the context root you defined when you installed it. However it's the portlet container that what will call your doView, processAction, etc methods and help maintain the state of the portlet and the navigation state of the user. Adding the portlet to a page let's Portal know where you want the portlet to be available in the page model.
You have two administration consoles because WebSphere Portal runs on top of WebSphere Application Server. That is the standard WAS admin console you're using there. You'll use it to administer your standard WAS stuff (servers, database connections, web services, etc). The Portal Admin console is there to administer portlet specific specific things, such as the page model, portlets, themes, etc.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am new in SAP.but i am confused b/w SAP UI5 and Webdynpro.I have some points of confusion.
(1) Is Webdynpro plays role like Servlets and JSP for middle ware programming.
(2) IS UI5 is replacement of Webdynpro.
(3) or UI5 is only a like front end programming like HTML,CSS,JAVASCRIPT etc.
Please find comments below for your questions:
(1) Is Webdynpro plays role like Servlets and JSP for middle ware programming?
Not Exactly, Web Dynpro ABAP is the SAP standard UI technology for developing Web applications in the ABAP environment. It consists of a runtime environment and a graphical development environment with special Web Dynpro tools that are integrated in the ABAP Workbench.It enables you to build business applications, which means that you can't change the look and feel with embedded HTML or Java Script.
(2) IS UI5 is replacement of Webdynpro.
No, UI5 is a JavaScript UI Library.
UI5 lets you build enterprise-ready web applications, responsive to all devices, running on almost any browser of your choice. It’s based on JavaScript, using JQuery as its foundation and follows web standards. It eases your development with a client-side HTML5 rendering library including a rich set of controls and supports data binding to different models (JSON, XML and OData)
With respect to END user you may quite true. But for a developer WebDynpro and UI5 are two different UI technologies.
(3) or UI5 is only a like front end programming like HTML,CSS,JAVASCRIPT etc.
Yes, Its a JavaScript UI framework/library along with that it supports data binding to your different data models as mentioned above.
Please find the comments below ( considering the differences between Web Dynpro and SAP UI5 ) :
Web Dynpro :ABAP framework to build web apps.
SAP UI5 : A Javascript application framework to build Web apps.
Web Dynpro does not play the role of a servlet/JSP as it is a complete UI technology for front-end development in ABAP. ( ABAP programming alongside plays a role of APIs ).
UI5 is a javascript framework makes efficient use of oData services(http rest API) to create template-based front-end applications as well.
Here, oData is mainly ABAP Gateway oData or HANA XS oData which serves as APIs residing only in the application layer.
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
we're developing kind of a social network.
We first focused on mobile applications and thus we developed our own API (REST) using jboss as application server and everything is fine.
Now we are beginning the development of a website. We decided to build such website on top on the API we already have, so we won't have to worry about the database management.
My question is: what approach should I follow?
client-side calls (using ajax)
server-side calls (using e.g. php, python) to dynamically generate the html page
Do you have any suggestion?
Thanks,
Andrea
I like a mixed approach.
Direct client side calls into your REST layer will have issues with Authentication & Authorization.
So you need to have a server-side Facade that validates application session and then allows the calls to pass through to your backend.
This layer can employ pagination kind of logic if the REST APIs have them missing.
Sometimes an UI action would require you to manipulate the data structure or multiple REST calls to create the resulting view. Direct one-to-one mapping of UI action to backend REST calls may not be possible. There also this facade helps make the APIs more UI friendly.
Finally - for some static / cachable HTML fragments your server can generate the view from REST layer and cache it for faster serving.
So in summary
Use node.js or playframework kind of AJAX based UI to build the UI layer.
But to use a Facade that orchestrates, aggregates, transforms, authenticate, authorize the UI calls before hitting the REST layer - to keep the UI experience simpler.
I am new to drools. How will i integrate my drool rules with front end jsp ? For example: i have created a front end page registration page through jsp. now how will I apply rules on that page. Please Suggest with through this example that how will it be done
This question seems rather broad in the sense that it's not clear whether it's asking how to write a web application or whether it has anything particular to do with Drools.
To put it as simply as possible.
Your JSP page should have a form which posts back to the server.
There should be a controller which handles requests from that form.
The controller invokes a service which uses the Drools API to invoke your rules.
The controller takes the result from that service and passes it to a new JSP for rendering as HTML.
Anything beyond that requires you to learn how to interact with Drools via its API. Assuming that you can write code to do that, there's nothing different that you really need to do to use it within your web application. The documentation is here:
http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html_single/
In case you're interested in code examples of Drools within a web application, you could take a look at this:
https://github.com/gratiartis/sctrcd-payment-validation-web
Full disclosure - I wrote it. It's a Spring web application providing REST web services which interact with Drools.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Reusability and abstraction is killing me; I've clearly been doing a lot of client-side development. CoffeeScript, Backbone, and Marionette have helped. Still, building completely reusable, modular "templates" - from the server-side and up - has not been possible. Let me describe a problem from the top down, and then maybe you can help describe the best stack.
I want to build a login widget that can be versioned and reused across multiple applications using the same framework (this is a basic whimsical example, take it with a few grains of salt). One large application is a bad idea, and they're hosted separately anyways. All the separate applications use the same API, hosted elsewhere, and no JSONP is acceptable.
Client-side
A login form would be comprised of a Marionette ItemView, some jQuery functions to handle all the fancy-dancy interaction, a Backbone "Account" model which handles various aspects of POST, GET, DELETE, and some basic html with the View is bound to. Normally, I'd have to explicity set the urlRoot for the AJAX interaction (see below), but I'd just like to be able to say '/' + #attributes.email, as it wouldn't matter what the ROUTE was, as everything is bundled together.
class Account extends Backbone.Model
# Normal
create: () ->
#urlRoot = () ->
'/account/' + #attributes.email
#save()
# Ideal
create: () ->
#urlRoot = () ->
'/' + #attributes.email
#save()
Server-side
This is built in accordance with the client-side (hopefully in Scala), and instead of explicitly defining a ROUTE somewhere:
POST /account/:email controllers.Account.create(password: String) # Play 2.0 syntax
I'd simply be able to say:
#POST(/:email?password=[String]) # Made up syntax
create(email, password) = {
# Hit external API
val json = WS.url('https://someapi/v1/account').withQueryParams('email=' + email + '&password=' + password).get()
# Return some response
Ok(json)
}
The application framework would know this module, or template, as #account() perhaps, and If I wanted to build a home page with login capability, I'd simply do something like:
<html>
Oh hey cool stuffz, sign up or login please
<right column>
#account()
<end right column>
#social() <!-- perhaps another template -->
<html>
What I envision is the application layer abstracting the client-to-server calls from the modules into GUIDs, perhaps, so making that `create account' call would really be doing something like:
POST /35395235/:email account.create(password: String)
While I understand this doesn't necessarily exist, I've stumbled upon Lift, and it seems relatively promising, but still not quite abstracted as I had hoped. Thoughts?
Why the url mapping for a portlet is not specified in portlet.xml? Unlike 'servlet-mapping' in web.xml?
What is the necessity of doing it through the portal console?
The principle behind portlets is that they can be dropped onto portal pages according to the wishes of the portal site designer, or sometimes according to the wishes of the portal user themselves. If a portlet was accessed via a mapping in the portlet.xml file, then you would have to redeploy the portlet application each time you wanted a new mapping. Using a portal console allows you to place the portlet on any one of the portal pages that you create.
Using a portlet-mapping and navigating to it would also suggest that you would only be able to see that single portlet. Some portlets cooperate on a page, and so these wouldn't function properly without being deployed together on a portal page.
If a portlet was accessed directly, then what would the look and feel of the response be? Portals are generally used with themes which control the overall look and feel of the site and allow the portlets in a site to look consistent with each other. Themes often provide you with a standard header and footer etc. A combination of the Portal and the theme often provide you with page navigation too, built up from the pages that are stored within the Portal.
Also, if portlets are allowed to be invoked directly, then you could be able to bypass the Portal Container's security mechanism.
As an 'and finally', some Portlet Containers actually do let you address a portlet directly for certain specific use cases. And some Portlet Containers internally convert the deployed portlets into servlets - and these do have a servlet-mapping that can be accessed directly (although they might break as they may have expectations that the portlet container has put certain attributes in the servlet request).
So it's not a black-and-white answer. Generally speaking, if you're developing a portlet then you're doing so because you do want your portlet to be invoked from a Portal page and you do want all of the value-added stuff that comes from running within a Portal.
If you don't want these things, then maybe the question is should my application be built using portlets?