[PORTLETSPEC3-67] Add Multipart Support Created: 29/Jan/16  Updated: 30/May/16

Status: Reopened
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See PORTLETSPEC3-59 for method descriptions.

Multipart requests should be supported to allow file uploads, etc.

Add the following methods:

ClientDataRequest#getParts
ClientDataRequest#getPart

Configuration:

1) Add a Multipart annotation that can only be used within an @PortletConfiguration annotation
to provide the required configuration data.

@Multipart(location="/tmp", fileSizeThreshold=1024*1024, 
    maxFileSize=1024*1024*5, maxRequestSize=1024*1024*5*5)

2) Allow the same info to be specified through the portlet deployment descriptor
on a per-portlet basis.

<portlet>
   ...
   <multipart-config>
       <location>/tmp</location>
       <max-file-size>20848820</max-file-size>
       <max-request-size>418018841</max-request-size>
       <file-size-threshold>1048576</file-size-threshold>
   </multipart-config>
</portlet>

The alternative to adding a new annotation would be to just require use of
the javax.servlet.annotation.MultipartConfig annotation. However, I think
that might be a problem, since it is not specified how a servlet container
has to react when this annotation is applied to a non-Servlet class. Some servlet
containers might just ignore it, while others might reject the whole application
at deployment time. So I think it would be better to add our own annotation.



 Comments   
Comment by Neil Griffin [ 29/Feb/16 ]

+1 for this issue in general, but here are some additional items...

1) Adding a multipart-config element will require a change to the portlet-app_3_0.xsd schema document.

2) I think we should rely on javax.servlet.http.Part since there is no need to redefine a portlet analog and portlet.jar already has one dependency on the Servlet API with javax.servlet.http.Cookie.

3) Rather than add another annotation like @Multipart, I think it might be simpler to add attributes like location, max-file-size, etc. to the @PortletConfiguration annotation.

Comment by Neil Griffin [ 02/Mar/16 ]

During the EG call on 29 Feb 2016 I think we decided to pursue #1, #2, and #3 from my comments above and that we would not create a new @Multipart annotation.

Comment by msnicklous [ 20/May/16 ]

Please see the API documentation describing these methods here.

A reference implementation snapshot implementing the methods is located here.

A portlet specification snapshot describing the new methods is available here.

Comment by Neil Griffin [ 27/May/16 ]

@msnicklous: I'm temporarily re-opening this issue in order to ask a question:

As discussed in the comment above, during an EG call we decided against the @Multipart annotation, but I see that the latest version of the Portlet 3.0 JavaDoc includes the annotation. Should it have been removed? Thanks, Neil

Comment by msnicklous [ 30/May/16 ]

The portlet 3.0 javadoc does contain an @Multipart annotation, but it has @Target(value=ANNOTATION_TYPE) so it can only be used within another annotation, and not stand-alone. In particular, it is used in the @PortletConfiguration annotation. I thought of going with @MultipartPortlet instead, but to me it just seemed to make the the configuration more verbose without really adding clarity.

If there are other opinions, or a different idea for a short name, we can discuss.





[PORTLETSPEC3-71] Make Additional Portlet Artifacts Available for Injection Created: 23/May/16  Updated: 30/May/16

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Portlet Specification v3.0 Chapter 21 Managed Bean Support defines a number of portlet artifacts that must be made available for injection and as EL objects. Some of the EL names should be modified to make them less bulky. Also, the PortletContext should be made available for injection and the URLFactory should be deleted as the MimeResponse can be used instead.

Table showing modifications:

Arfifact EL Name Qualifier Phases Modification
RenderParameters renderParams - all change
MutableRenderParameters mutableRenderParams - action, event change
ActionParameters actionParams - action change
ResourceParameters resourceParams - resource change
PortletContext portletContext - all add
URLFactory urlFactory - render, resource delete


 Comments   
Comment by Neil Griffin [ 27/May/16 ]

The latest PortletSpec3-Draft1-20160527.pdf document has Chapter 20 as "Managed Bean Support" (not Chapter 21 as mentioned in the description above)

Also, the table in the description above still has URLFactory (which is deleted in the latest spec).

Comment by msnicklous [ 30/May/16 ]

The modifications suggested in the table above should now all be implemented in the latest spec: Portlet Specification 3.0 Draft 2 27 May 2016

(the 'modifications' column was intended to indicate the changes wrt the previous spec draft ... I was probably less clear than I should have been)

Also, I noticed that the the PDF document is misnamed. It should be ...'draft2'... rather than ...'draft1'... . I'm not going to go back and change that now - I'll just be more careful next time .





[PORTLETSPEC3-70] V3 Functionality for Portlet Tag Library Created: 23/May/16  Updated: 30/May/16

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The portlet tag library should be updated to reflect V3 functionality.

The define objects tag should be updated to provide the following additional objects in the scope of the current JSP page:

Class Object name Phases
PortletRequest portletRequest all
PortletResponse portletResponse all
RenderParameters renderParams all
ActionParameters actionParams action
ResourceParameters resourceParams resource

New tags should be introduced for use with the actionURL, renderURL, and resourceURL tags to reflect the more specific portlet 3.0 parameter typing. The current param tag will retain its present function.

Tag Name Parameter Type URL Type
renderParam render parameter render URL, action URL
actionParam action parameter action URL
resourceParam resource parameter resource URL


 Comments   
Comment by Neil Griffin [ 27/May/16 ]

Should <portlet:defineObjects/> also include things like renderState?

Also, Pluto V3 has DefineObjectsTag2168.java and DefineObjectsTag286.java but does not yet have DefineObjectsTag362.java?

Comment by msnicklous [ 30/May/16 ]

We could go ahead and make all injectable portlet objects available as page variables. That would be somewhat redundant when CDI is present, as those objects will be available through EL anyway, but it might be useful when CDI is not present.

As to DefineObjectsTag286.java - this is pretty much a Pluto implementation detail, so from the point of view of the spec, it sort of doesn't matter. But my current thought would be to expand the existing class, as there won't be terribly much to do, rather than implementing a new class.





[PORTLETSPEC3-69] Portlet Tag Library escapeXML attribute definition is too restrictive Created: 03/May/16  Updated: 31/May/16

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The portlet tag library provides the resourceURL, renderURL, and actionURL tags for generating the corresponding URL types in JSP markup. Each of these tags takes and optional escapeXML attribute, which is defined in the spec as follows:

escapeXml (Type: boolean, optional) – determines whether characters <,>,&,’," in the resulting output should be converted to their corresponding character entity codes (‘<’ gets converted to ‘<’, ‘>’ gets converted to ‘>’ ‘&’ gets converted to ‘&’, ‘‘’ gets converted to ‘'’, ‘"’ gets converted to ‘"’). Default value is true.

Also, the BaseURL#write(writer, boolean) method contains a similar description:

Writes the portlet URL to the output stream using the provided writer. If the parameter escapeXML is set to true the URL will be escaped to be valid XML characters, i.e. <, >, &, ', " will get converted into their corresponding character entity codes (< to &<, > to &>, & to &&, ' to &', " to &"). If escapeXML is set to false no escaping will be done.

These descriptions could be taken to imply that if the escapeXML value is set to true, the named characters will be converted to the entity codes, but if the escapeXML value is set to false, they will definitely not be, and the characters would be available as clear text in the resulting markup.

However this collides the URL format being vendor-specific. There are other valid ways to encode a URL besides using the entity codes.

I would suggest that this attribute on the tag library URL tags be deprecated and ignored. The description would be changed as follows:

escapeXml (Type: boolean, optional) – deprecated. The URL encoding will be determined by the portlet container implementation.

The description for the BaseURL#write method would be changes to the following:

void write(Writer out,
         boolean escapeXML)
           throws IOException

Writes the portlet URL to the output stream using the provided writer. If the parameter escapeXML is set to true the URL will be escaped to be valid XML characters. The URL encoding will be determined by the portlet container implementation.

Note that the URL written to the output stream may not be a valid URL, as it may be rewritten by the portal/portlet-container before returning the markup to the client.

Parameters:
    out - the writer to write the portlet URL to
    escapeXML - denotes if the URL should be XML escaped before written to the output stream or not
Throws:
    IOException - if an I/O error occurred while writing the URL
Since:
    2.0


 Comments   
Comment by Neil Griffin [ 03/May/16 ]

@msnicklous: Does this deprecation have an impact on the following methods in the Java API?
http://msnicklous.github.io/portletspec3/apidocs/javax/portlet/BaseURL.html#append(java.lang.Appendable,%20boolean)
http://msnicklous.github.io/portletspec3/apidocs/javax/portlet/BaseURL.html#write(java.io.Writer,%20boolean)

Comment by msnicklous [ 31/May/16 ]

It might be better to refrain from actual deprecation, but modify the documentation that addresses the escapeXML flag as follows.

For the write(Writer, boolean) and append(Appendable, boolean) methods:

If the parameter escapeXML is set to true, the URL will be escaped to be valid XML characters. The manner in which escaping is performed is implementation specific. If escapeXML is set to false, escaping the URL is left to the implementation.

Note that the appended URL may not be a valid URL, as it may be rewritten by the portal/portlet-container before returning the markup to the client.

For the actionURL, renderURL, and resourceURL JSP tags:

escapeXml (Type: boolean, optional) – determines whether the resulting output is to be XML escaped. The manner in which the output is escaped is implementation specific. If this option is set to false, whether or not the output is XML escaped is left to the implementation. Default value is true.




Generated at Mon Aug 29 21:53:48 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.