Search: concept
Last modified by Vincent Massol on 2014/10/21
Refine your search
Select a category and activate filters on the current results
Result type
-
Document
2
Location
-
Documentation
1
-
Drafts
1
Creator
Last modification date
- Sort by:
- Relevance
Results 1 - 2 of 2
Page
1
Portlet Integration
Located in
- Rendered document content
The Java Portlet Specification allows coordination on the UI layer with different means, such as events, application sessions, and public render parameters, in order to provide a deep and seamless integration between the different services. Portlet Concepts a portal is a web based application that commonly provides personalization, authentication, content aggregation from different sources and hosts the presentation layer of information systems a portlet is an application that provides a specific piece of content (information or service) to be included as part of a portal page web clients interact with portlets via a request/response paradigm implemented by the portal a portlet container runs portlets and provides them with the required runtime environment manages the life cycle of portlets provides persistent storage for portlet preferences a portlet mode indicates the function a portlet is performing in the render method standard portlet modes are: view, edit and help view: generate markup reflecting the current state of the portlet edit: customize the behavior of the portlet help: provide help information about the portlet a portlet window is the visual component used to display the content generated by a portlet within portal pages a window state is an indicator of the amount of portal page space that will be assigned to the content generated by a portlet via the render method possible window states are: normal, maximized and minimized Portlet Life Cycle The life cycle of a portlet is expressed through the init, processAction, render and destroy methods of the Portlet interface.
- Raw document content
The Java Portlet Specification allows coordination on the UI layer with different means, such as events, application sessions, and public render parameters, in order to provide a deep and seamless integration between the different services. == Portlet Concepts == image:portalPageCreation.png * a **portal** is a web based application that commonly provides personalization, authentication, content aggregation from different sources and hosts the presentation layer of information systems * a **portlet** is an application that provides a specific piece of content (information or service) to be included as part of a portal page ** web clients interact with portlets via a request/response paradigm implemented by the portal * a **portlet container** runs portlets and provides them with the required runtime environment ** manages the life cycle of portlets ** provides persistent storage for portlet preferences image:elementsOfAPortalPage.png * a **portlet mode** indicates the function a portlet is performing in the render method ** standard portlet modes are: view, edit and help ** view: generate markup reflecting the current state of the portlet ** edit: customize the behavior of the portlet ** help: provide help information about the portlet * a **portlet window** is the visual component used to display the content generated by a portlet within portal pages * a **window state** is an indicator of the amount of portal page space that will be assigned to the content generated by a portlet via the render method ** possible window states are: normal, maximized and minimized == Portlet Life Cycle == The life cycle of a portlet is expressed through the ##init##, ##processAction##, ##render## and ##destroy## methods of the ##Portlet## interface.
REST API
Located in
- Rendered document content
Understanding resources and representations "An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., an URI in HTTP).
…/jobstatus/{jobId} Request parameters: Name Required Values Default Description Version request no true|false false Return also the job request 9.1RC1 progress no true|false true Return also the job progress 9.1RC1 log no true|false false Return also the job log 9.1RC1 log_fromLevel no error|warn|info|debug|trace Indicate the level from which to return logs 9.1RC1 HTTP Method: GET Media types: application/xml (JobStatus element) Description: status of a job Status codes: 200: If the request was successful. 404: If the job status has not been found /joblog/{jobId} Request parameters: Name Required Values Default Description Version level no error|warn|info|debug|trace Indicate the exact level for which to return logs 7.2M3 fromLevel no error|warn|info|debug|trace Indicate the level from which to return logs 7.2M3 HTTP Method: GET Media types: application/xml (JobLog element) Description: log of a job Status codes: 200: If the request was successful. 404: If the job status has not been found /jobs Request parameters: Name Required Values Default Description Version jobType yes The type of the job to pass to the Job Executor 9.1RC1 async no true|false true If false, return the response only when the job is done 9.1RC1 This API is designed to be a REST clone of the JobExecutor Java API (the only real difference right now being way to deal with asynchronous jobs) documented on http://extensions.xwiki.org/xwiki/bin/view/Extension/Job+Module#HUseanexistingjob so the concepts (job type, job request) are the same and the exact information to put in the job request depends on the job you want to run and are usually documented in the extension this job is coming from (extension module, refactoring, etc.).
- Raw document content
= Understanding resources and representations = "An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., an URI in HTTP).
…(eg: ##refactoring/delete/11451##). === /jobstatus/{jobId} {{info}}Since 7.2M3{{/info}} === Request parameters: |=Name|=Required|=Values|=Default|=Description|=Version |##request##|no|##true~|false##|##false##|Return also the job request|9.1RC1 |##progress##|no|##true~|false##|##true##|Return also the job progress|9.1RC1 |##log##|no|##true~|false##|##false##|Return also the job log|9.1RC1 |##log_fromLevel##|no|##error~|warn~|info~|debug~|trace##| |Indicate the level from which to return logs|9.1RC1 * **HTTP Method:** GET ** **Media types:** *** application/xml (JobStatus element) ** **Description:** status of a job ** **Status codes:** *** 200: If the request was successful. *** 404: If the job status has not been found === /joblog/{jobId} {{info}}Since 7.2M3{{/info}} === Request parameters: |=Name|=Required|=Values|=Default|=Description|=Version |##level##|no|##error~|warn~|info~|debug~|trace##| |Indicate the exact level for which to return logs|7.2M3 |##fromLevel##|no|##error~|warn~|info~|debug~|trace##| |Indicate the level from which to return logs|7.2M3 * **HTTP Method:** GET ** **Media types:** *** application/xml (JobLog element) ** **Description:** log of a job ** **Status codes:** *** 200: If the request was successful. *** 404: If the job status has not been found === /jobs {{info}}Since 9.1RC1{{/info}} === Request parameters: |=Name|=Required|=Values|=Default|=Description|=Version |##jobType##|yes| | |The type of the job to pass to the Job Executor|9.1RC1 |##async##|no|##true~|false##|##true##|If false, return the response only when the job is done|9.1RC1 This API is designed to be a REST clone of the JobExecutor Java API (the only real difference right now being way to deal with asynchronous jobs) documented on http://extensions.xwiki.org/xwiki/bin/view/Extension/Job+Module#HUseanexistingjob so the concepts (job type, job request) are the same and the exact information to put in the job request depends on the job you want to run and are usually documented in the extension this job is coming from (extension module, refactoring, etc
Page
1
RSS feed for search on [concept]