Recent Posts

RSS Feeds

Portlets JSR 168


Just finished with the talk on JSR 168. Cool stuff.

my notes

Portlets are a part of Portal and assembled into a full fledged portal.

There is no Portal spec, they are vendor specific but the portlets are standardized so you should be able to run your portlets in any Portal.


Portal Page Elements

1)    Portlets

a.     title bar, and controls

b.     Portlet window

2)    Portal page (built up from portlets and static HTML)

The Portlets do not have to have title bar and controls like you see in Yahoo.

 

Portal app is part of a web app, webapp can have ‘normal’ Servlets and JSPs

Portlets deployed like Servlets

Web-inf/portlet.xml is the deployment descriptor.

Portlet can user Servlets and JSP’s to generate markup fragments or perform tasks

Portlets have access to other Servlet stuff.

 

Basics – Window States

1)    Normal

2)    Minimized

3)    Maximized

4)    Custom states

a.     Declared by portlet, only used if supported by Portal

b.     Example: HALF_PAGE, NARROW, FLOATING, WIDE… The portlet specifies these in the portlet.xml. If the Portal supports the custom stuff then they can be used, otherwise they are ignored.

Some/many of the state changes are triggered by the buttons in the top right of the portlet.

Portlet Mode

1)    view

2)    edit

3)    help

4)    custom modes

a.     declared by portelt, only usedif supported by Portal

b.     ‘standard’ custom modes suggested by spec: about, config, edit_defaults, preview, print

Portlet api has request and response things that are passed into the processAction (respond to action events) and render (generate markup) methods.

GenericPortlet overrides render and forwards to mode-sepcific methods (doView, doEdit, doHelp).

 

Lifecycle – each HTTP request only one Portlet can get ‘processAction’ only if the request is an Action URL and ‘trageted’ to the portlet. Render for each portlets, no guaranty of order, might do concurrently in threads, protlet returns content fragment. Portal assembles fragements into a web page.

 

Change things only happen in processAction method.  Portal decides when render happens, if one portlet is max’ed then none of the others will be shown.

 

Other API – mostly mirrors Servlet api’s. Except for the PortletPreferences which manages preferences for the portlet.

 

Example – hello world the portlet.xml has the title. Portal knows how to render the title bar from the descriptor, which buttons show up in the top right hand side.

 

 

More stuff.

 

URL’s to external stuff are fine and leave the Portal window to a new window.

URL’s to the portlets are different either action or render type.  The URL can have parameters and the parameters only go to the targeted Portlet.

 

Namespace Encoding

Portlets generate HTML that lives on a bigger page.

Requires name and identifiers to be named-spaced – unique to the portlet, avoid collisions, HTML id’s, JavaScript variables and functions

The render response class can tell you what your namespace is. You are expect to generate your JavaScript on the fly while rendering your Portlet.

 

Forms in a portlet

 

Forms should use POST, don’t use GET, use POST with the ActionURL and its parameters. The container generates the action URL and add ‘private’ parameters for these URL’s. These URLs go into the ‘action’ attribute for the FORM.

 

Preferences

 

Declared and defined in the deployment descriptor. Provides persistent customization of the portlets view or behavior. It is container specific how they persist. All the preferences are multi-valued and Strings. You have to take care of getting the types changed. You can only modify from the processAction method.  Store is an atomic method. May throw and exception if store is not possible (no user, no way to determine chance of success, no way to determine reason for failure).

 

HTTP Session Attributes – scoped to ‘PORTLET_SCOPE’ or ‘APPLICATION_SCOPE’

 

Any url you build needs to go through ‘encodeURL’.

 

Preferences are stored in a db but its vendor specific as to how they go to the db. I’m assuming there are places you can get in there and get the preferences and put them where you want them. The preferences are described in the deployment descriptor.

 

JSPs and Servlets

Allows protlet to externalize its rendering with the PortletRequestDispatcher. The JSP’s must render ‘fragments’. The JSP’s or Servlets can get at javax.portlet.config – the PortletConfig, javax.portlet… other stuff. There is a tag-lib for doing Portlet stuff in JSP’s. They allow you to get at the defined objects, build action and rnder url’s and get into the namespace.

 

JSP Portlet Pattern – portlet class contains performAction to (process forms, modify preference and session data, maintain state fo rmulti-page forms). Render method dispatch to JSPs (presentation markup, but JSP probably not generally reusable, must generate only fragements, jsp probably strongly tied to the portlet). JSP is hosted by WebApp, accessible from outside (rely on unpublished URL to hide it).

 

The example was krufty because of all the code in the JSP. I hope there is a better way to get the stuff into the JSP. Presenter asserts that the EL will make things better for JSP 2.0.  I need to play with it to form a better opinion.

 

Other Stuff

Your portlet does not get to decide what its type is going to be. In the render method you are told what the Portal wants.

 

There is no ‘declarative security’ for the Portlet and the security is weak. There is no Portal specification to say how things work. I.e. a banking portlet that needs ssl and a weather portlet that does not. It’s up to the Portal to determine what happens.

 

Portlets can be cached. The Portlet can specify how its cached.

 

WSRP – allows you to aggregate Portlets from other servers via a web-services interface. The two specs cooperated with each other.

Permalink     No Comments

Not your mothers XSLT (2.0 that is)


Just finished up the XSLT 2.0 talk it was really cool. Learned alot about what is going to be there. I wanted to hear more about the standardization of the extension stuff (i.e alt way to turn XML into Java instead of JAXB). But I'll have to ask aobut that later.
here are my notes

XPath and XSLT 2.0 are coming out together. XQuery is a new query language for XML and its based on XPath.

 

XPath was originally designed to be used with XSLT.

 

Each location is made up of a node test. @ sign moves to the attribute axis. Each element can evaluate to one or more elements. The return value is called a node set.

 

// means anywhere.

[] means predicate that is used to filter the node set its applied to. The predicate can evaluate Boolean expressions. There are also lots of functions available for use anywhere (including predicates). The function used in the example was count(node set).

 

XSLT defines how to reorganize data, to XML, HTML, plain text etc.

 

XSLT is divided into different templates

 

XSLT is a functional language, there are no local variables, all variables are global.

 

The templates are functions.

apply-templates means to go and find all the children of the current node and find templates that match and apply them.

apply-templates with an select attribute is like ‘find all the sub elements that match and apply any functions that are available for them.’

 

XSLT 2.0 goals

1)    increase usability and readability

2)    expand data-typing

3)    simplify string manipulation – much simpler, reg-ex

4)    add grouping functionality

5)    allow multiple output docs

6)    maintain backward compatibility – biggest goal, old style sheets should not break

 

XSLT 2.0 uses XML-Schema types – XSLT processors are not required to be ‘schema-aware’. 19 primitive built-in types 25 derived types.

Sequence – new collection type replaces node-set and result tree fragment.

Tons of cool date manipulation stuff, 10 types for date/time, 3 formatting functions, 21 extraction functions, 3 time-zone adjustment functions.

 

Saxon 7 is a preliminary impl of XSLT 2.0 does not yet support custom data types.

 

Sequences – an ordered list that can hold zero or more items, any of the data types that fit with XSLT. This will be the new result of and expression.

Every expression returns an expression.

<xsl:for-each select=”(1 to 100)[. Mod 5 = 0]”> outputs all the integers between 1 and 100 that are mod 5 = 0.

Dev-X Transform XML Document tool to show you the output.

Ordered with duplicates, the sequence will go in the order you specify instead of document order. I.e.. <xsl:for-each select=”(following-sibling::*[1], …./>

Since you put commas into the select attribute it will do the order you specify instead of document order.

Sequences are flattened, instead of nested sequences, the processor will flatten the nested elements into one long sequence.

The value of a sequence is the first element (so you can use a sequence with one value it will default to the simple thing of the only element.) If you specify a separator attribute in your xsl:value-of you will get the whole sequence. I.e. <xsl:value-of select=”(1 to 4)” separator=” + “/> will evaluate to “1 + 2 + 3 + 4”.

A sequence with one item is equivalent to the one item.

 

Expressions – iterative expressions ‘for $var in expression(, $var2 in expression) return expression’. There was some cool example stuff with subtotals and totals for a table of prices.

Conditional expressions inside XPath.

Comparitive Expressions

Permalink     No Comments