Portlet development features overview #

  service builder generated code is great for portlet developer’s productivity but since it generates all of that code right in your project it can sometimes be cumbersome to navigate, so some new features have been added to help with this.

• often a portlet developer wants to navigate between jsp page and a portlet action that is backing some user action using the actionURL tag, navigating these methods has been made easier.
• dealing with resources bundles is a common occurrence for portlet developers, so many features for handling liferay language properties files have beed added to make a portlet developer more productive
• a liferay 6.x project has many xml files related to portlet development, portlet.xml, liferay-portlet.xml, service.xml, liferay-display.xml,etc.  Dealing with these files, navigating from XML to Java and back is common for developers.  So a new xml searching capability has been added by integration and extending an xml search framework into Liferay IDE. 

• when in a liferay portlet project, and editing in a java file (portlet, etc), now there are new hyperlink definitions made available for the following
• hyperlinks to the real service builder impl method from the util API, so now when hyperlinking from a call to a service builder util API it will search and go to the “real” implementation method is one is available based on known service builder patterns.

• also when you try to hyperlink to a particular util method API, all of the classes in your project will be searched for service wrappers (based on service builder naming conventions) and a new hyperlink target will be presented to the user, to open the service wrapper.

• if you have multiple hyperlink wrappers declared in your project all of them will be displayed in information control when you select “open service wrapper” and then whichever service wrapper you select, that class will be opened.

• If you are developing liferay portlets using MVCPortlets then you have likely used the actionURL pattern of name=”methodName”
• now there is a hyperlink detector that will look for method names on portlet subclasses in your project and if you try to hyperlink from a portlet:actionURL tag, it will now offer that hyperlink, F3 goto declaration also works here.

• Both MVC portlets and JSR style portlets are supported
• so it doesn’t matter what the method name is but instead it looks for the @ProcessAction annotation name attribute

• not only hyperlink support but also validation and code completions are available.
• so when you are typing in the name=”” attribute you can invoke code completion and see a list of all portlet action methods on existing portlet classes in your project.

• ActionCommand portlets also supported

• Quick fix for missing action methods
• quick assist for missing action methods
• you can create both JSR and MVC style action methods

• many liferay jsp tags support this pattern by letting developers type in the property key that is located in the resource bundle.
• we have extended the jsp editor to offer several features related to resource bundles
• in these screenshots you can see that we display the actual message key value in the properties file.
• in the 1st screenshot the resource bundle is located in the developers project
• in the 2nd screenshot the message key is not in a local resource bundle but rather in the liferay language.properties file which are available as valid key values when using liferay taglibs.

• navigation is supported as well. hyperlinks are detected from the key attribute so you can open the resource bundle and it will jump directly to the corresponding message key
• all liferay taglibs are indexed with the correct attribute “key” for some and “message” for others to offer the hyperlink definition

• not only do we have hover and hyperlink support but also we have added validation and code assist.
• when a message key is added, all of the resource bundles in the current project and also in the keys in the portal are searched. if a match is not found then a warning validation message is added.
• when the developer is typing in the key, they can invoke code completion and see all of the keys from all the resource bundles in the developer’s project. the keys from the portal are not included in this list since that contains thousands of keys.

• For any warnings in markers view you can invoke quick fix to add the missing key

• quick assist can be invoked right from editor using Ctrl + 1 shortcut

• Liferay projects have lots logical references between XML descriptor files and resources and classes in those projects. While in the past there has been support for these logical references in various validation and editors, in upcoming release support for this relationship has been improve by integration an xml search framework plugin and then adding liferay specific extensions.
• So now eclipse’s search engine knows that if you search for global references to a Portlet class, it will find any <portlet-class> elements that reference that class.
• Also if you editing the XML directly and you are editing an element that has this relationship you can now invoke code assist and get completions for valid classes that match the requirements of a <portlet-class> element.
• The same thing applies for all other class elements in liferay descriptors, i.e. <filter-class> knows that the only valid classes to offer for completion would be classes that implement the right type, etc.

• not only Java <-> XML search links are indexed, but also between XML <-> XML files themselves.

×　So a liferay-portlet.xml or liferay-display.xml file that references the <portlet-name> of a portlet.xml, that relationship will be understood by Eclipse’s search engine ×　So if you open a portlet.xml and you do a global search for all references to <portlet-name>foo</portlet-name> then all other descriptor files that reference that portlet name, will be found as seen in the screenshot above. The search results should two other xml files and the particular elements/attrs that reference that portlet name.

• also when you are creating a new reference from one descriptor to another, like in an liferay-display.xml id=”” attribute, you must put in a valid <portlet-name> from the portlet.xml file. So now the possible values for portlet ids are searched and returned to the developer for code completions as seen in first screenshot
• hyperlink navigation works as expected in 2nd screenshot