#portlet

ez-gridster

A responsive grid/portlet directive that does all kinds of fancy stuff.

This is a fork of the excellent Manifest Web Designs angular-gridster directive. I needed some features that required breaking some backwards compatibility.

Demo

See Live Demo

Installation

bower install ez-gridster

Then, import the following in your HTML alongside jQuery and angular:

Everyone loves the word Portal. In fact, just thinking of the word invokes hoverboard-levels of excitement for wanting a gravity gun. If only enterprise portals could be as interesting. Sometimes referred to as a "one stop shop", enterprise portals carry stigmas of cumbersome, over-budget and under-utilized projects. As an iPlanet/Vignette consultant (in a former life), I cannot disagree with the perception, but I feel these stigmas are in large part due to the “idea" of Portals outpacing supporting technologies.

HISTORY OF PORTALS

When portals were first introduced, the lack of standards and tools were abysmal at best. This was great for “portal developer” job security, but when it came to an industry … we were in bad shape. The first Java portlet spec was finalized in late 2003(JSR 168), and it primarily focused on interoperability and architecture of portlets. I mention this only to provide comparative context: the industry at large was more focused on standing up portal technology … than interested in people actually using it. It wasn’t until 2008 that we saw JSR 286 (discussing cross-portlet interaction models), which in my opinion was the earliest measurable acknowledgement that portals needed a better user experience to take flight. All that withstanding, portals are still here and still around. Why? It’s simple.

The value of centralized information management and dispersal is universally solid. It makes sense, and that common sense can outweigh practically anything, including ailing technology and user experience.

SOCIAL INTRANET - THE MODERN PORTAL

Nearly a decade later, social intranets and compelling user experiences are on the rise, but some organizations struggle with where they fit. If you look at the business proposition for social intranets, you see a lot in common with portals (and much more), such as:

- centralized location of information (The One Stop Shop principal)

- personalized web experiences (Dashboards, Activity Streams)

- collaboration between individuals and teams (Wikis, Blogs, Discussions, Status, Ideas, Calendars ...)

- integration with disparate systems (Gadgets, Widgets, APIs, Cloud Services, … )

So when I hear someone say that they have a portal, but don’t think a social intranet is right for their company, it baffles me.

Why would you continue to invest money in something that is dying? Why is it so much more unclear to see that a better portal solutions exists in the form of a social intranet? (Note:  A real social intranet built on collaboration, mobility and user experience, not some CRUD interfaces crammed into a portal framework). After-all, unless you’ve overly invested in your portal (and most people don’t), chances are your employees use the portal out of daily conditioning more so than actual desire. Imagine the amount of employee interaction and conversation that would take place if people actually liked using a collaborative social intranet.  On the flip-side, imagine how much information you could learn about your employees (implicit and explicit) to make smarter internal decisions that resonate best with those doing the actual work.  This type of top-down/bottom-up alignment has been sought after for decades to improve company efficiency, and now the technology and generational make-up is there to make it a reality!

GETTING STARTED WITH OR WITHOUT AN EXISTING PORTAL

If you happen to be in a position where you have a portal, and are looking for something better, you should really consider a social intranet. (Same story holds true for those without a portal)  It doesn’t have to be a lights on/off scenario. Both portals and social intranets should have aspects that mirror your companies top-down structure, and for the two to co-exist during a transition, simply have your portal bring in conversations/content from matching areas in the social intranet. (for example, show recent/featured HR conversations, blog posts or announcements in the HR Portal Dashboard)  This provides a clean way to bring the new social intranet into the light, and as adoption increases, the social intranet takes hold as the new de-facto “portal”.

Who knows? In 10 years social intranets may be replaced with something even more cool, but the difference will be that social intranets will enable people to rally opinions around that change and facilitate it when the time is right!

WHAT DO YOU THINK

To change things up in 2014, I’ve decided to take to Twitter and ask people to share their thoughts on these articles. If you have thoughts on a topic, or would like to hear me voice my opinion on another topic, simply tweet to @ryanrutan with your comments, and I’ll work it into the topic list.

Portlet. 서블릿과 유사하게 포틀릿은 포틀릿컨테이너에 배치되어 동적 컨텐츠를 새성하는 웹컴포넌트.

“포틀릿은 복합페이지의 컨텍스트내에 결집되기 위해 특별히 고안된 웹컴포넌트이다. 통상 많은 포틀릿들은 포탈페이지의 단일 요청(request)로 호출된다. 각 포틀릿은 마크업 조각을 생성한다. 그것은 다른 포틀릿의 마크업과 겹합되어 전체 포탈페이지 마크업이 된다.” (JSR 168 포틀릿 스펙중)

특징은 다음과 같다.

1. 포틀릿은 특정컨테이너에 의해 관리되어진다. 2. 포틀릿은 동적인 컨텐츠를 생성한다. 3. 포틀릿은 컨테이너에 의해 생명주기가 관리되어진다. 4. 포틀릿은 웹클라이언트와 요청/응답 패러다임을 통해 작동한다.

출처 : http://bit.ly/1gm0D0F

서블릿과의 차이점은 다음과 같다.

1. 포틀릿은 전체 문서가 아니라, 마크업 조각(fragment)만을 생성한다. 2. 포틀릿은 직접경로(URL)을 제공하지 않는다. URL에 의해 포틀릿만을 단독으로 호출하는것은 불가능하며 포틀릿을 포함하고 있는 페이지의 URL을 호출하여야 한다. 3. 포틀릿이 생성한 컨텐츠는 포탈페이지의 일부이기 때문에 포틀릿은 자의적인 컨텐츠를 생성할 수 없다. 만약, 포탈서버가 text/html형식을 제공한다면 모든 포틀릿은 text/html 컨텐츠만 생성하여야 한다. 반대로, 포탈서버가 WML형식을 제공한다면 각 포틀릿들 또한 WML컨텐츠를 생성해야 한다.

출처 : 상동

To understand the Spring 3.0 portlet framework, I wrote this sample portlet for demonstrating serveResource feature of JSR 286 using Spring Annotation. Resource URI are identified based on the id given at the time of generating it. This id become key to differentiate when resolving the request. If you use Spring 3.0 Annotation based approach, then this resolution is taken care by Spring and it delegates the call directly to respective method having matching annotation. Look at the code JSP code to generate Resource URL :

<portlet:resourceURL id="sampleAJAX"/>

The id you are providing while generating the key should match with value attribute of method annotation. Look at the code for Spring Controller :

packagesample.spring.controller;

importjavax.portlet.RenderRequest;

importjavax.portlet.RenderResponse;

importorg.springframework.stereotype.Controller;

importorg.springframework.ui.Model;

importorg.springframework.web.bind.annotation.RequestMapping;

importorg.springframework.web.portlet.bind.annotation.ResourceMapping;

@Controller

@RequestMapping("VIEW")

public classResourceRequestController {

      @RequestMapping

      public String defaultLanding(Model model, RenderRequest rRequest,

                  RenderResponse rResponse) {

            return "welcomescreen";

      }

            @ResourceMapping(value="sampleAJAX")

      public String demoAJAX(){

            return "ajaxdemo";

      }

      }