Re: [vote] Portlet API - Compromise (Refinement)
Santiago Gala wrote: ingo schuster wrote: At 20:04 02/16/01, Raphal Luta wrote: What would be the ideal time for an IRC chat ? Personnally I'd prefer either between 12:00 and 130:00 GMT (but I guess it's a bit early for the PST people out there) or near 19:00 - 20:00 GMT. Both times are ok with me. Did we already fix the day (Mo or Tue)? Again, I don't have any preferences. I strongly prefer tomorrow. Today I have a social compromise at 19h30m CET -- 18h30m GMT, so it would be difficult for me to be available at 19h30m GMT, and I have no IRC client for my GPRS phone... :) I'm stuck with a new system installation tomorrow evening :( Let's say Wednesday, February 21, 19h30 GMT IRC: cvs.working-dogs.com Channel: jetspeed Ok for everybody ? Jon, do you mind if we use your IRC server for this ? -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Steve, Suggestion: Add a configuration tag to the portlet definition which specifies whether or not the portlet will produce partial or full content. You probably mean the deployment descriptor, not the portlet definition... Suggestion: Create portlet wrappers for full content stripping so the containers won't have to deal with this stuff. That's exactly what the abstract classes (among other things) do in our latest proposal. Cheers, Thoma B. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Steve, Can you give an example of how such a stub should look like? You may indeed have good ideas here... Cheers, Thomas B. - Original Message - From: "Steve Freeman" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Sunday, February 18, 2001 21:32 Subject: Re: [vote] Portlet API - Summary and IBM Position (long) At 07:36 PM 2/18/2001 +0100, you wrote: 1.Primary output mode (This affects the programmatic Portlet API) Alternatives: a) output stream as base mode in portlet package sax as special mode in portlet.sax package b) neutral base interfaces in portlet package sax as special mode in portlet.sax package output stream as special mode in portlet.stream package c) sax as base mode in portlet package output stream as special mode in portlet.stream package Note: Whether or not portlets will run on all portlet containers does not depend on the primary output mode or the package structure of the API, but only on whether the specification defines all output modes as mandatory or not. When offering multiple output modes, the specification must mandate implementation of all of them by all portlet containers to assure portlet portability. Another alternative: Output in base portlet package as abstract stubs or an interface. Both SAX and Stream as child packages portlet.sax and portlet.stream, respectively. Set up the default mode using a properties file. This will allow a more natural subclassing of output functions which don't necessarily need to be based upon streams. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Compromise (Refinement)
At 20:04 02/16/01, Raphal Luta wrote: What would be the ideal time for an IRC chat ? Personnally I'd prefer either between 12:00 and 130:00 GMT (but I guess it's a bit early for the PST people out there) or near 19:00 - 20:00 GMT. Both times are ok with me. Did we already fix the day (Mo or Tue)? Again, I don't have any preferences. ingo. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Compromise (Refinement)
ingo schuster wrote: At 20:04 02/16/01, Raphal Luta wrote: What would be the ideal time for an IRC chat ? Personnally I'd prefer either between 12:00 and 130:00 GMT (but I guess it's a bit early for the PST people out there) or near 19:00 - 20:00 GMT. Both times are ok with me. Did we already fix the day (Mo or Tue)? Again, I don't have any preferences. I strongly prefer tomorrow. Today I have a social compromise at 19h30m CET -- 18h30m GMT, so it would be difficult for me to be available at 19h30m GMT, and I have no IRC client for my GPRS phone... :) Even if I had it, WAP phones are pretty unusable... -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Thomas, Excuse me for not being fully up to snuff... At 10:25 AM 2/19/2001 +0100, you wrote: Steve, Suggestion: Add a configuration tag to the portlet definition which specifies whether or not the portlet will produce partial or full content. You probably mean the deployment descriptor, not the portlet definition... Yes. Suggestion: Create portlet wrappers for full content stripping so the containers won't have to deal with this stuff. That's exactly what the abstract classes (among other things) do in our latest proposal. Great! I suppose I should go read the proposal, eh? ;) This should speed up the parallel processing on an SMP machine, provided that portlets on a page are processed on separate threads. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Thomas, I'll try to do this without having all of the details clear in my head. First, there's the package hierarchy: portlet portlet.stream portlet.sax In the portlet package, there should be an interface to define the contractual requirements of the child package methods. We could call this PortletOutputInterface, or some such. It would need to define a method for setting up the output stream to be used by the child package: setupOutput(stream) The portlet package would define the default implementation, implementing the interface. This should be an abstract class. The classes in the child packages need to subclass the abstract class or the interface. The abstract class might then have a method called setupOutput() which would look up the name of the method to invoke in order to dump the output to the actual output stream (which is really the end result, no?). The method name would be placed into a property somewhere (details tbd). setupOutput() would then call the named method with a parameter of the actual output stream. The method would be responsible for connecting the back-end data source to the output stream. portlet.stream would then write directly to the output stream. This would be called directly from the portlet. portlet.sax would have to complete the parsing of the DOM tree before walking the tree, possibly transcoding it into another format, and finally sending it to the output stream. This class would implement the necessary callback hooks between it and the portlet to enable the parsing and event handling required to convert the input source into a valid output stream. That's my thinking, anyway, which is subject to change at this point. I've got to do some digging into the existing packages to see what's being done for the portlets before I can go any deeper on a possible implemenation. Give me a day or two. BTW, I'm working on the IBM Portal too.. with the Raleigh folks. I'll send you an internal note so you'll have my address. Steve At 10:21 AM 2/19/2001 +0100, you wrote: Steve, Can you give an example of how such a stub should look like? You may indeed have good ideas here... Cheers, Thomas B. - Original Message - From: "Steve Freeman" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Sunday, February 18, 2001 21:32 Subject: Re: [vote] Portlet API - Summary and IBM Position (long) At 07:36 PM 2/18/2001 +0100, you wrote: 1.Primary output mode (This affects the programmatic Portlet API) Alternatives: a) output stream as base mode in portlet package sax as special mode in portlet.sax package b) neutral base interfaces in portlet package sax as special mode in portlet.sax package output stream as special mode in portlet.stream package c) sax as base mode in portlet package output stream as special mode in portlet.stream package Note: Whether or not portlets will run on all portlet containers does not depend on the primary output mode or the package structure of the API, but only on whether the specification defines all output modes as mandatory or not. When offering multiple output modes, the specification must mandate implementation of all of them by all portlet containers to assure portlet portability. Another alternative: Output in base portlet package as abstract stubs or an interface. Both SAX and Stream as child packages portlet.sax and portlet.stream, respectively. Set up the default mode using a properties file. This will allow a more natural subclassing of output functions which don't necessarily need to be based upon streams. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Styling by portlet container ?
Santiago Gala wrote: - we can first aggregate content, and then the container will lay it out and style it. (This is my view) This is an interesting thought, but how would the container know how to "style" content provided by a particular portlet ? There are simple special cases like XML feeds for which a container potentially could provide a set of straightforward default tranformations for different media types, but how would this work for a Stock Quote Portlet, e-Mail Portlet, Collaboration Portlet, Weather Portlet, or a B2B Buyer Portlet for example ? I'd assume that a portlet is the only entity in the portal that can know how exactly it has to be rendered/styled. Or do you mean the portlet container would apply portlet specific stylesheets to style portlet content ? My feeling currently is that aggregating content first and styling it in the second step will only work in the very special case where similar content is beeing aggregated for which the container knows the styling. It probably would not work if you think of a remote banking portlet that runs on a bank's server in the internet and must have the banks look and feel, corporate identity etc. This certainly requires to include styled content from a remote source into the portal pages as is. - we can style content, then have laid out and aggregated by the container. (This seem to be your view) Basically yes, except that for the HTML case, where the container defines the global CSS stylesheet that defines default fonts and colors for portlets. Also, is is the container's responsibility to layout the rendered content provided by the portlets in one or more portal pages. The special stuff like e.g. images, colors of stock quotes, unread mail, etc. are styled by the portlet itself. The first view can be implemented by having the portlet writing to a "content event stream", and then having the container transform this event stream (on the fly) to the needed media document. Do you mean by just filtering events and adding events for layouting and styling inetween or by or by really converting the content from XML into particular markups like WML, HTML, cHTML, VoiceXML, ... ? The latter would require something like portlet specific stylesheets, right ? Using an event approach like SAX will make this process quite efficient, as the whole process will take place synchronously. There is no post-processing here (except in the conceptual view). If I cannot use a event stream to handle output, then I will need to have postprocessing, and most of your concerns will apply. This is why I NEED event streams. Well there still is a very simple form of post-processing to receive sax events and write them to the output stream as opposed to portlets writing directly to the output stream at the appropriate time when they are called by the portlet engine. However, there is no problem with that as long as it is just one alternative and there is the other alternative to efficiently use template mechanisms to let portlets write to the output stream directly. That lets you do the sax based approach and we can use the stream based approach. I agree that current implementations (specially if they are not concerned about multidevice rendering) will go the second way. We have implemented a multi-device portal that supports HTML, cHTML, WML, and VoiceXML using the second way. The portlets we run include stocks,weather and news. The first way works well for the multi-device case and it performs and scales very well up to hundrets of concurrent users sending requests in a high frequency. (Of course we want to scale up much higher in the future.) But I feel that THE WAY is the first way. This idea will gradually open in the minds of managers as they have to manage 4 content types, navigator versions, personalisation, etc. Also, there is different people doing content production and styling. We should separate the content and style processes as much as possible. It is true that content production and styling have to be separated, but this separation can also happen in the portlet: - Content is provided in XML documents or through beans - The portlet applies portlet-specific styling to the content for markup generation by using stylesheets, JSPs, or other mechanisms - Global styling can be applied by using CCS stylesheets I think styling can not be done by the portlet container for all portlets in a general way as portlet styling is very often portlet specific (e.g. in a stock portlet, stock prices of stocks that went up should be green while prices of stocks that went down should be read. Or think of different symbols for weather conditons in a weather portlet - GIFs for HTML, specifically designed images for iMode and WAP, maybe a digitized sound for VoiceXML. I don't believe the container can handle these things in a generic portlet-independent way. My concerns is that the portlet API should have a way to allow for aggregation
Re: [vote] Portlet API - Summary and IBM Position (long)
After the discussions we had during the last few days and before the upcoming decision, I'd like to provide a new summary of the current state of the discussion and explain IBM's position in a separate section at the end, after the dotted line. We are all in agreement about our common goal :) - Raphael has provided an excellent description of this goal: "The Jetspeed community has decided to start specifying a Portlet API that could be proposed as a standard for all portal implementations. Offering a standard API between portals only makes sense if the portals implementing the API can guarantee to the portlet writers complying to this API that their portlet will always run correctly whatever the implementation they are deployed upon: 'write once, deploy anywhere' This is the reason why the Portlet API should define both the programmatic API as such, but also the content guidelines that portlet writers should follow to achieve portability and possibly the deployment process." There are open questions on how to realize this goal. I'd like to ask everybody to spend an appropriate amount of time to think through all the implications of all different alternatives before we decide, including relation to the Servlet API and XML APIs, acceptance of the Portlet API by portal product vendors, induced development costs for portal vendors, system complexity, performance and scalability, etc. Three orthogonal issues (1-3) need a decision, after that, we have to choose from several implementation options (4). 1.Primary output mode (This affects the programmatic Portlet API) Alternatives: a) output stream as base mode in portlet package sax as special mode in portlet.sax package b) neutral base interfaces in portlet package sax as special mode in portlet.sax package output stream as special mode in portlet.stream package c) sax as base mode in portlet package output stream as special mode in portlet.stream package Note: Whether or not portlets will run on all portlet containers does not depend on the primary output mode or the package structure of the API, but only on whether the specification defines all output modes as mandatory or not. When offering multiple output modes, the specification must mandate implementation of all of them by all portlet containers to assure portlet portability. 2.Fragments and/or Full Documents (This affects portlet container performance and ease of implementation - and thus development costs) Alternatives: a) only document fragments concatenatable without post-processing - high-performance - low effort implementation of portlet container - requires to strip off tags from tool-generated document templates once in advance - container can easily concatenate portlet output - container can be agnostic to fragments' internal structures b) document fragments and full documents - high performance possible if programmers use fragments - higher effort for implementation of portlet containers - container must strip off tags from full documents generated by some portlets at run-time and be able to handle framents. - container must be aware of document structure and know what parts have to be stripped off for each particular markup type c) only full documents that require post processing - lower performance - higher effort for implementation of portlet containers - container must strip off tags from documents generated by portlets at run-time - container must be aware of document structure and know what parts have to be stripped off for each particular markup type 3.Internal structure of documents of fragments a) only potential contents of tables, cards, etc., i.e. fragments could not contain multiple cards or pages - simple aggregation b) potential content of tables, multiple cards, etc., i.e. fragments could contain multiple cards or pages or card content - aggregation must be able to handle multiple cards/pages returned by portlets 4. Implementation options a) Streams/Fragments only Simple, high-performance, highly scalable implementation In advance Runtime Runtimeor on-the-fly ++ --- +-+ ++ || | Portlet |-Fragent--||-Doc || --- +-+ Template || Template || --- +-+ || || | Portlet |-Fragent--||-Doc | Portal | --- +-+ Template |Frag| Template | Aggre | --- +-+ |Tool| | gation | | Portlet |-Fragent--||-Doc || --- +-+ Template || Template || --- +-+ || || | Portlet |-Fragent--||-Doc ++ ---
Re: [vote] Portlet API - Summary and IBM Position (long)
Thomas Schaeck wrote: Unlike the Servlet API, the Portlet API would additionaly provide explicit SAX support in the sax package and introduce a dependency on org.xml.sax, i.e. a separate package. Such a dependency of an API package to another API package that is not part of the core Java classes is rather uncommon. FYI - SAX is provided by JSR 5 (aka, JAXP). Sources tell me that JAXP will be included in JDK 1.4. - Sam Ruby -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Compromise (Refinement)
At 20:04 02/16/01, Raphal Luta wrote: I updated the java docs in the proposals directory so that everybody can have a look at them. They are more detailed, but I hope that this mail did also make the idea clear. I still owe you a proposal that defines which rules document fragments will have to comply to in order to by a "well-defined fragments". Didn't get to it yet, but it'll follow. I'm mostly interested in the WML fragments you'd like to propose because it's a really tough issue... Ok, here is a try: * Use standard WML. The official WML specification is available on the www.wapforum.org. * Watch out for unterminated and extraneous tags. The behavior of pages with improperly terminated tags is undefined. * Use only elements that can be included into a card (probably together with other portlets/elements). Do not create separate cards. * Make no assumptions on whether the portlet will be displayed alone or together with other other portlets. * Do not use templates. * Do not try to set the card title. * Avoid lengthy, complex WML. The buffer length can be restricted by the user agent Portlets may share a page with others. * Avoid using images too often. When using images, define a meaningful alt name ( this is necessary for the devices that don't support images or if the image can't be fetched). Define localsrc if possible. * Do not use intrinsic events. These events (oneventforward, oneventbackward, etc.) should be only added by the aggregation level. * Avoid using timers. * Use user-tiggered events only if necessary. For user-triggered events always define label and name parameters explicitely. Prefix the name with the portlet unique id, otherwise conflict between diffent portlets on one page is possible. Use meaningful names for labels. * Do not create fixed-width WML tables or images in portlets. * Avoid long, unbroken lines of unwrap text. This helps avoiding unnecessary scrolling. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Sam Ruby wrote: Thomas Schaeck wrote: Unlike the Servlet API, the Portlet API would additionaly provide explicit SAX support in the sax package and introduce a dependency on org.xml.sax, i.e. a separate package. Such a dependency of an API package to another API package that is not part of the core Java classes is rather uncommon. FYI - SAX is provided by JSR 5 (aka, JAXP). Sources tell me that JAXP will be included in JDK 1.4. - Sam Ruby Cool! I knew about JAXP, but so far I only heard statements that the XML APIs *may* be included in JDK 1.4. The *will* sounds much better. That should resolve the issue. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
At 07:36 PM 2/18/2001 +0100, you wrote: 2.Fragments and/or Full Documents (This affects portlet container performance and ease of implementation - and thus development costs) Alternatives: a) only document fragments concatenatable without post-processing - high-performance - low effort implementation of portlet container - requires to strip off tags from tool-generated document templates once in advance - container can easily concatenate portlet output - container can be agnostic to fragments' internal structures b) document fragments and full documents - high performance possible if programmers use fragments - higher effort for implementation of portlet containers - container must strip off tags from full documents generated by some portlets at run-time and be able to handle framents. - container must be aware of document structure and know what parts have to be stripped off for each particular markup type c) only full documents that require post processing - lower performance - higher effort for implementation of portlet containers - container must strip off tags from documents generated by portlets at run-time - container must be aware of document structure and know what parts have to be stripped off for each particular markup type Suggestion: Add a configuration tag to the portlet definition which specifies whether or not the portlet will produce partial or full content. Suggestion: Create portlet wrappers for full content stripping so the containers won't have to deal with this stuff. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Compromise (Refinement)
I haven't had much feedback on the proposed compromise but after a private discussion with Raphal I think that some more detailed description will be helpful. Furthermore, even though my proposal allowed to use both approaches (portlets delivering output streams to the container as well as portlets delivering sax events to the container) it still stressed in some way, that the stream based approach would be the basic, standard way, whereas the sax event way was only an extension. (And meanwhile, since I didn't finish this mail yesterday, Raphael send an proposal that exactly inverts this emphasis :) ) I try to refine my proposal so that both alternatives (and even additional ones) are all totally equal. -- I All portlet types are equal! ;-) Ok, the idea is now following: In order to not induce an emphasis on either Portlet type, * for each portlet type, there is a extra package, containing at least one abstract class that implements the portlet interface. * for each portlet type, there is a subinterface of PortletResponse that is specialized for the needs of the respective portlet type. E.g.: - SaxPortletResponse has methods getLexicalHandler(), getContentHandler() - StreamPortletResponse has the method getWriter() The abstract classes cast the PortletResponst object in their service method to the respective PortletResponse objects. * The interface PortletResponse itself doesn't provide _any_ methods for returning content. * Theoretically, there could be other portlet types besides SaxPortlet and SteamPortlet, e.g. "DomPortlet, EcsPortlet, HtmlPortlet" (Again: The following picture is best viewed with a fixed width font, e.g. "Courier New") Portlet ContainerAPI Portlets _ | | A---. | |A---. PortletRequest | I |---|-|| | '---' | | | | | | | I | Portlet A---. | | | | PortletResponse | I |--|-|-| | '---' | | '---' | | | | | | | | | | ^ | | | | | A---. | | ^ ^ ^ StreamP.Response A---.| | | AC--.AC--.AC--. SaxP.Response A---.|' | | |AC ||AC | |AC | XYP.Response| I |' | | '---''---' '---' '---' | | | | | SaxPortlet StreamPortlet XYPortlet ^ | | | | | C---. | | | | | ResponseC---.| | | ^ ^ ^ Impl.s C---.|' | | U---.U---.U---. | C |' | || C | | C | | C | '---'| |'---' '---' '---' |_| aSaxPortlet aStreamPortlet aXYPortlet I checked the boxes: (A) provided by the Portlet API (C) provided by the Portlet Container (AC) provided by the API but can be replaced by the container (U) classes implemented by the potlet developer The above approach has following advantages: * There is really no "default, standard" way, we won't have to decide whether the sreaming way or the sax way is reflected already in the root PortletResponse. * We can specify different constraints for different portlet types: SaxPortlets return full documents, StreamPortlets only fragments. This makes allowence for different goals per portlet: - A SaxPortlet tries to achieve a maximum of safty and as its output will usually be post-processed anyway there is no big additional impact on performance. - A StreamPortlet aims to achieve a maximum of performance and as this forbits post-processing, it has to return only document fragments. (They have to comply to certain rules). [Well, in the java docs that I've committed, there is actually no "StreamPortlet" class, instead there are two abstract classes "FragmentStreamPortlet" and "FullStreamPortlet". The only difference is the "full document" vs. "fragment" requirement.] * A portlet container that supports only certain types of portlets can check already at the deployment time whether it is able to support a certain portlet or not. * Portlet containers could specialize on certain design goals, e.g. safty, universality, performance... The main disadvantages: * The base PortletResponse interface is "naked". A PortletResponse object doesn't help anything, you always have to cast it. I.e. that there is no "default way" that the portlet API gurantees to work always and in every container. * There can be portlet containers that support only some portlet types. Portlets do not necessarily run on _every_ portlet container, but only on those
Re: [vote] Portlet API - Compromise (Refinement)
At 14:33 16/02/2001 +0100, you wrote: I haven't had much feedback on the proposed compromise but after a private discussion with Raphal I think that some more detailed description will be helpful. Furthermore, even though my proposal allowed to use both approaches (portlets delivering output streams to the container as well as portlets delivering sax events to the container) it still stressed in some way, that the stream based approach would be the basic, standard way, whereas the sax event way was only an extension. (And meanwhile, since I didn't finish this mail yesterday, Raphael send an proposal that exactly inverts this emphasis :) ) That was its goal ;) snip proposal description The main disadvantages: * The base PortletResponse interface is "naked". A PortletResponse object doesn't help anything, you always have to cast it. I.e. that there is no "default way" that the portlet API gurantees to work always and in every container. * There can be portlet containers that support only some portlet types. Portlets do not necessarily run on _every_ portlet container, but only on those that support their type. (This is compareable to the beginning of EJBs when not all containers supported entity beans for example). * A developer can't write a portlet that implements the portlet interface and extends some other class at the same time. As there is no multi-inheritence in java, portlets are forced to extend only the abstract portlet classes. That's a pretty big characteristic as it basically means the API naturally segments the "portlet space" in disjonctive sets, in particular a portlet can't easily mix its output mode depending on the markup generated (but then this is a compromise...). Actually, I was thinking about the possible use of an implementation of the base portlet API (which would be supported by any container) and it actually may be useful for building action-like portlet which never output directly any data but do some processing, maybe update the portlet context and then redirect to another portlet for generating output. Maybe this is worth considering if we chose this compromise path... Another note on the proposed API is that I think my proposed solution for handling content models (through the descriptors) is way better than using different sub-interfaces per content model because it will lead to an explosion of sub-interfaces (for example how do you define an interface for a SAX based portlet which wants to output XHTML fragments but full WML ? SaxWithXHTMLFragmentButFullDocumentInOtherMarkupsPortlet ;-P ) I updated the java docs in the proposals directory so that everybody can have a look at them. They are more detailed, but I hope that this mail did also make the idea clear. I still owe you a proposal that defines which rules document fragments will have to comply to in order to by a "well-defined fragments". Didn't get to it yet, but it'll follow. I'm mostly interested in the WML fragments you'd like to propose because it's a really tough issue... I hope that the above is a fair compromise in which all of us should find their requirements and design goals taken into account. However, for none of us it will be as neat as we whished it'd be - but that's the nature of compromises... Ok, then: comments? I think the proposed API in definitely fair but if we can't find a reasonable use for the empty PortletResponse looks a bit strange. I alos think we should treat all the implementations in the same way so either define only SaxPortlet and StreamPortlet and leave the content model in the descriptor (my preferred approach) or have a SaxFragment/SaxFull/StreamFragment/StreamFull implementations. ingo. P.S.: Raphael suggested to have an IRC chat on Monday or Tuesday evening (european time). That'll give us the possibility to speed up the discussion and bring it to an end. I think this is a good idea. Yes, I still think this woud be a good idea in order to settle this question definitely and move forward... Based on the last 2 compromise proposals, I think the decisions we need to make now are: Q1. Do we want an API that offer a stream/content model (s/cm) for portlets that "guarantee" portability at the cost of ease of portal implementation ? Yes - my SAX based proposal - END No - Depending on the s/cm, some portlets will not run on some portals Q2. Do we want a symmetric API between SAX and Stream and the cost defining an unnatural base PortletResponse interface ? Yes - Ingo's latest proposal No - Byte streams must be chosen as the stream - either Ingo's previous proposal or my "reversed" SAX proposal (they are the same anyway) Q3. Do we want to bind the API with some cm ? Yes - Ingo's content model sub-interfaces No - Use deployment time/runtime time content model descriptors Q4. Which content models do we want to define and which do we want to make mandatory ? (Easy for some
RE: [vote] Portlet API - Compromise
I'd like to applaud Ingo for stepping up and trying to find a middle ground.
Impressive ascii-diagram too :)
SaxPortlet has specific knowledge about the portlet container's
implementation of the response. Now the portlet container's
ResponseImpl
can provide additional methods such as "getContentHandler()" and the
specific implementation of SaxPortlet can savely cast the
PortletResponse
to ResponseImpl and make use of these additional methods
(""). We
consider this a safe break of the Portlet API contract.
Am I right to say that the PortletResponse interface still does not have a
getContentHandler() method.
Will the abstract class SAXPortlet have any dependencies on XML?
What will the SAXPortlet interface (abstract class) look like?
Let me ask clearly: are you proposing any dependencies on the XML classes?
I could be wrong, but it doesn't appear to me that the API is embracing the
SAX approach.
The part about casting and breaking the Portlet API contract doesn't seem
right. I guess that's the nature of compromises...
I do like the abstract SaxPortlet adapting SAX events and then writing to
the servlet stream. This makes sense.
After reading Thomas's comments, I understand that standardized Java APIs do
not depend on other Java APIs.
Ive searched through quite a few java apis looking for a precedence, but I
couldn't find one such dependency.
I also found something in the Servlet 2.3 spec, but I don't know what to
make of it yet.
The spec. suggests servlet 'filters' for XSL transformations.
- david
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
At 23:04 14/02/2001 +0100, you wrote: Raphael Luta wrote: At 23:56 13/02/2001 +0100, you wrote: I think it is useful to provide a little summary of the current state of the discussion. I tried to give a neutral summary on each item, followed by my opinion. Thomas, I think it's a very good summary of the issues. Wer're not discussing (yet) the Jetspeed implementation, which may support both full documents and document fragments through configuration elements external to the proposed standard Portlet API (for example the portlet deployment descriptors that were proposed in the first Portlet API discussion 3 months ago) The document fragments need to be in the standard and the full documents need to be prohibited by the standard (see below). This not only my opinion, but also what our customers and other portal vendors I already talked to about Portlet API standardization are saying. If you look at the web sites of Oracle, BEA, and other portal vendors, you will see that they are also using document fragments (see also Ingo Rammer's note listing Oracle's guidelines). We'd hardly find a single major portal vendor who would be in favour of requiring full documents in the standard that require mandatory post-processing that will slow down his implementation and lead to bad benchmark results. What you're saying is just that no vendor has yet tried to create a portable portlet specification but only an optimized implementation specific API :) Just today I visited a very large portal customer at their headquarters and talked to their technical experts and technical decision makers the whole day. One topic was of course aggregation and they were very happy with the approach to use portlets that write document fragments directly to the output stream one after the other. They asked whether we would create temporary objects/strings or do any post-processing and were only satisfied after I assured them that everything is written directly to the output stream without any performance or memory overhead. We cannot change this. Ok, I guess now I've stressed this point more than enough ;) I agree that, for performance reason, there should be a way for portlet writer to state that their portlet does not require post-processing, provided the portal implementation allows it. - I think we should add to this summary the following notice: The Jetspeed community has decided to start specifying a portlet API that could be proposed as a standard for all portal implementations. Offering a standard API between portals only makes sense if the portals implementing the API can guarantee to the portlet writers complying to implementation they are deployed upon: "write once, deploy anywhere" This is the reason why the Portlet API should define both the programmatic API as such, but also the content guidelines that portlet writers should follow to achieve portability and possibly the deployment process. I absolutely agree that content guidelines (or better rules) that portlet programmers/designers must follow should be defined in addition to the programmatic Portlet API. I think these rules need to contain the following items: Gee, Thomas, I was just trying to describe the issues, not giving my opinion. Now, I *have* to restate my POV on this issue. ;) * A general statement saying that portlets must return document fragments suitable for aggregation in the client's expected mark-up language and may not return full documents. * Detailed Specs of Fragments for particular mark-up languages: - A HTML Fragment Specification for Portlets - A WML Fragment Specification for Portlets - A cHTML Fragment Specification for Portlets - A VoiceXML Fragment Specification for Portlets - Fragment Specifications for other mark-up languages We can provide the fragment specs for HTML, WML, cHTML and VoiceXML. These specs along with the specification of the programmatic Portlet API and the Portlet Archive format will enable "write-once, deploy everywhere" for portlets. Once these specifications are available, tools can be written that take templates created by visual tools and strip off the tags before deployment of portlets, rather than stripping off the tags at run-time in a post-processing step for each request. By the way, the rules we use for HTML fragments in our projects at IBM are basically identical to Oracle's that Ingo Rammer has posted, I guess it is just common sense that leads to these guidelines. The guidelines for the other mark-up languages may be a little bit trickier, but certainly doable. I would agree to this only if you can show me workable fragment guidelines for non nestable markups like WML or SMIL. (I don't know VoiceXML but I gather it's also non nestable). What I mean by "non nestable" is that the markup does not provide a general element that can be recursively included and that naturally define a segment of the aggregation
Re: [vote] Portlet API
[EMAIL PROTECTED] wrote: Santiago Gala wrote: Do you mean that javax.servlet.* is more standard than javax.xml.* (Trax and Jaxp)? What I am trying to point out is that it is not good for a standard Java API depend on other Java APIs that are not part of the JDK classes. If you look at javax.servlet for example, it has no dependencies on any other Java extension, only on classes and interfaces in the JDK classes. Whenever possible, dependencies of Java APIs to classes/interfaces that are not JDK classes should be avoided. Yes. I would also like to minimize dependencies. But I look also for a way to integrate other frameworks. This is where the clash comes, I think. Maybe it is true, but I can't see it. The servlet API contains a specific method of creating output, namely writing to a response stream. Writing to the response stream just seems like the natural way of outputting content to me - and probably to many people used to write servlets. I think this is different than using SAX, DOM, or ECS. For servlet, and CGI, programmers, this is true. But, for instance, jsp, ASP, coldfusion, php, ... programmers will think in terms of filling a template. They don't understand the issues of the response stream. For static HTML designers, it will look like "putting a document somewhere". For XML people, it again looks similar to those templating environment. They think in terms of a document that is transformed and "magically" sent to the client. Under the hood, we should try to do clever things to avoid object allocation and garbage. But, to the user, our API should be friendlier than "just servlet". My view here is that having a event stream instead of a byte stream allows for nice shortcuts in the implementation in the case where you are handling well-formed XML languages (fragments or elsewhere). In the case of XSLT transformations, it avoids paying high tolls for reparsing. The problem here is that we are aggregating content. So, there are recursive concepts going on (a window composed of windows,...). I'll try to explain: Some definitions (informal): - content is layout, media and lf independent. - layout is putting together several content sources (content+positioning information). - styling is rendering in a media/lf/user-agent dependent way positioned content. The processes I try to describe here are similar to the publishing industry processes: first you have a content item, written by an author, then you select content items and put them in pages. Styling is more complex, since there is "inline style", like font,emphasis info, and "block style", like column width and decorations. There seem to be two views on content aggregation as a whole in the list: - we can first aggregate content, and then the container will lay it out and style it. (This is my view) - we can style content, then have laid out and aggregated by the container. (This seem to be your view) The first view can be implemented by having the portlet writing to a "content event stream", and then having the container transform this event stream (on the fly) to the needed media document. Using an event approach like SAX will make this process quite efficient, as the whole process will take place synchronously. There is no post-processing here (except in the conceptual view). If I cannot use a event stream to handle output, then I will need to have postprocessing, and most of your concerns will apply. This is why I NEED event streams. I agree that current implementations (specially if they are not concerned about multidevice rendering) will go the second way. But I feel that THE WAY is the first way. This idea will gradually open in the minds of managers as they have to manage 4 content types, navigator versions, personalisation, etc. Also, there is different people doing content production and styling. We should separate the content and style processes as much as possible. My concerns is that the portlet API should have a way to allow for aggregation of content before styling as I feel it will be the way to go in a short amount of time. I think I am getting constructive here. :) BTW, Sorry if some of my posts were stressing. I think my feelings betray me sometimes. Please feel free to correct me and continue the discussion, without thinking in "urgent" votes, or winning or losing, just for the sake of building common understanding :) -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: [vote] Portlet API - Compromise
At 08:11 02/15/01, David Sean Taylor wrote:
I'd like to applaud Ingo for stepping up and trying to find a middle ground.
Impressive ascii-diagram too :)
SaxPortlet has specific knowledge about the portlet container's
implementation of the response. Now the portlet container's
ResponseImpl
can provide additional methods such as "getContentHandler()" and the
specific implementation of SaxPortlet can savely cast the
PortletResponse
to ResponseImpl and make use of these additional methods
(""). We
consider this a safe break of the Portlet API contract.
I will send a refinement of my proposal today or tomorrow that'll change
some details slightly.
Still I answer your questions in regard to how I meant the proposal already
posted:
Am I right to say that the PortletResponse interface still does not have a
getContentHandler() method.
Yes, it doesn't.
Will the abstract class SAXPortlet have any dependencies on XML?
Yes, it has to handle Sax events...
What will the SAXPortlet interface (abstract class) look like?
Please wait for the refinement, I'll post java docs - that should make it
clear.
Let me ask clearly: are you proposing any dependencies on the XML classes?
I could be wrong, but it doesn't appear to me that the API is embracing the
SAX approach.
The part about casting and breaking the Portlet API contract doesn't seem
right. I guess that's the nature of compromises...
I do like the abstract SaxPortlet adapting SAX events and then writing to
the servlet stream. This makes sense.
Not really. If you want to process sax events in the portal engine, then it
doesn't make sense to convert it into a stream in the SaxPortlet and
reparse it on the other side of the portlet in order to convert it back
into sax events.
After reading Thomas's comments, I understand that standardized Java APIs do
not depend on other Java APIs.
Ive searched through quite a few java apis looking for a precedence, but I
couldn't find one such dependency.
I also found something in the Servlet 2.3 spec, but I don't know what to
make of it yet.
The spec. suggests servlet 'filters' for XSL transformations.
- david
Again, please wait for my refinement, Raphael will post a second proposal
as well. This should give the basis for a following discussion.
ingo.
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
Raphal Luta wrote: (...) I would agree to this only if you can show me workable fragment guidelines for non nestable markups like WML or SMIL. (I don't know VoiceXML but I gather it's also non nestable). What I mean by "non nestable" is that the markup does not provide a general element that can be recursively included and that naturally define a segment of the aggregation space (HTML has table, XSL:FO has block, etc...). For me your current proposition is a workable standard (but inelegant) for defining portlets that output content in a nestable content but can't be used as a standard for non-nestable markup. To stress the point I'll give an example. I played with WML to find that: - a top navigation is mandatory to define the wml element, head and template - a portlet can only output full cards (one or more). - when I wanted to have the login card output by the logic in the top navigation, I found that then the first card output by the first portlet(set) laid out should be called "init" --- inelegant and difficult to enforce, since a portlet should not know if it is first or only one to be output in a deck. - then I had to duplicate logic in a bottom navigation, to show auxiliary cards (login, ...) - I didn't like the hacks (even if I find it more structured than current code in Jetspeed). If the portlet can specify abstract actions and events (via some markup or API) then the container could take care of building templates and auxiliary cards. Else, the container has to limit portlets a lot. I think WML event/action model is much more abstract than HTML, and thus a good starting point for specifying how the portlet API will deal with action/event specification. BTW, I can commit this if you want. Goes into taking out code from ECS and controls ... and into configurable templates. I had to use direct java in jsp to test for login. This code should go into the taglib eventually. (...) -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: [vote] Portlet API - Compromise
Not really. If you want to process sax events in the portal engine, then it doesn't make sense to convert it into a stream in the SaxPortlet and reparse it on the other side of the portlet in order to convert it back into sax events. I wasn't suggesting that! Guess I misunderstood the purpose of the SaxPortlet. It will become clearer when i see the javadocs, thanks -- david -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
[EMAIL PROTECTED] wrote: I think it is useful to provide a little summary of the current state of the discussion. I tried to give a neutral summary on each item, followed by my opinion. Point 1: Should JetSpeed require portlets to produce full documents ? Producing full documents means that the portal implementations would need to decide which parts of complete documents returned by portlets should actually be embedded in the overall page created by the portal. The motivation behind this - as Raphael described it - is that there are no guidelines defined for fragments that should be returned by portlets for markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline for portlet developers should be "Portlets must output well-formed (complete) documents conforming to the DTDs required by the client devices" instead of "Portlets should return well-formed document fragments suitable for aggregation in well formed documents conforming to the DTDs required by the client devices". The result of JetSpeed requiring portlets to produce full documents would be that all content generated by portlets would need to be post-processed by the portal implementation. There seems to be agreement that this introduces significant performance and memory overhead compared to portlets directly writing fragments to the portlet output stream without post-processing. There is disagreement on whether the resulting performance and memory overhead is acceptable or not. That depends on the use. I agree that imposing this requirement is not right. The decision to postprocess should be up to the implementor. (My Opinion (TS): We have implemented a portal that serves HTML, WML, VoiceXML and cHTML. The portlets directly write mark-up fragments to the output stream using JSPs or Stylesheets without post-processing, which is very fast. Forcing all content to be post processed through a SAX parser would impose an unacceptable performance degradation on our portal. We can make guidelines for content fragments that should be created by portlets available to resolve the issue of missing guidelines. My opinion is that we should under no circumstances require complete documents to be returned by portlets, as this woud introduce an inherent limitation of JetSpeed's performance.) I agree that postprocessing should not be mandatory. But if we don't have event processing in the API it is not optional, but nearly impossible. There is an activity for the specification of XML fragments (XHTML, WML, VoiceML, ...). http://www.xmlhack.com/read.php?item=1067 describes it. (Taken from Jetspeed xmlhack channel). To me, the requirement of outputting documents looks too strong, and short term sighted. There is ongoing effort to specify how to describe valid XML fragments, and the trend is to have markup languages that follow a schema/DTD (XML). Point 2: Should the Portlet API provide dedicated methods for SAX output ? This means that the methods getContentHandler() and getLexicalHandler() would be added to the PortletResponse interface. It could be done with other methods, possibly using only javax.xml.transform.* classes. The motivation behind this is that it should be possible for portlets to output SAX events rather than writing to the output stream so that portal implementations that internally process SAX events can provide document handlers that would directly be invoked by portlets rather than parsing the portlet response's output stream to create SAX events. It will allow the following things: - More modular design of a portal, as portlets can output abstract markup, that is transformed to the target device. So one portlet implementation gives output for several devices. - Integration (both of portlets and of the portal container as a whole) with XML tools, that accept already this input, or output, without performance penalties. - If portlets are written to a given DTD, the portal can serve different Content Types from the same content. Now we are doing this with RSS content, for instance. The result of the JetSpeed Portlet API defining the SAX specific methods as part of the core API would be that the Portlet API depends on the org.xml.sax package (JAXP). The SAX specific methods are unlikely to be accepted as part of a prospective Portlet API standard. Adding the SAX ??? why not? javax.xml.* is already part of the J2EE. Who will not accept them? methods would de-facto separate portlets into two kinds - portlets writing This is precisely what I'm trying to avoid. If the Portlet API does not accept XML events, someone will write a Content Aggregation API for XML. I am trying to get OUR API good enough for every use, or at least interoperable with XML code. to the output stream and portlets sending SAX events. Portal implementations would have to be able to run both kinds of portlets, a stream based portal implementation would need to provide
Re: [vote] Portlet API
At 23:56 13/02/2001 +0100, you wrote: I think it is useful to provide a little summary of the current state of the discussion. I tried to give a neutral summary on each item, followed by my opinion. Thomas, I think it's a very good summary of the issues. I have just 2 things to add/modify to this. - Point 1 should be titled: "Should the Portlet API require portlets to produce full documents ?" Wer're not discussing (yet) the Jetspeed implementation, which may support both full documents and document fragments through configuration elements external to the proposed standard Portlet API (for example the portlet deployment descriptors that were proposed in the first Portlet API discussion 3 months ago) - I think we should add to this summary the following notice: The Jetspeed community has decided to start specifying a portlet API that could be proposed as a standard for all portal implementations. Offering a standard API between portals only makes sense if the portals implementing the API can guarantee to the portlet writers complying to this API that their portlet will always run correctly whatever the implementation they are deployed upon: "write once, deploy anywhere" This is the reason why the Portlet API should define both the programmatic API as such, but also the content guidelines that portlet writers should follow to achieve portability and possibly the deployment process. Point 1: Should JetSpeed require portlets to produce full documents ? Producing full documents means that the portal implementations would need to decide which parts of complete documents returned by portlets should actually be embedded in the overall page created by the portal. The motivation behind this - as Raphael described it - is that there are no guidelines defined for fragments that should be returned by portlets for markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline for portlet developers should be "Portlets must output well-formed (complete) documents conforming to the DTDs required by the client devices" instead of "Portlets should return well-formed document fragments suitable for aggregation in well formed documents conforming to the DTDs required by the client devices". The result of JetSpeed requiring portlets to produce full documents would be that all content generated by portlets would need to be post-processed by the portal implementation. There seems to be agreement that this introduces significant performance and memory overhead compared to portlets directly writing fragments to the portlet output stream without post-processing. There is disagreement on whether the resulting performance and memory overhead is acceptable or not. (My Opinion (TS): We have implemented a portal that serves HTML, WML, VoiceXML and cHTML. The portlets directly write mark-up fragments to the output stream using JSPs or Stylesheets without post-processing, which is very fast. Forcing all content to be post processed through a SAX parser would impose an unacceptable performance degradation on our portal. We can make guidelines for content fragments that should be created by portlets available to resolve the issue of missing guidelines. My opinion is that we should under no circumstances require complete documents to be returned by portlets, as this woud introduce an inherent limitation of JetSpeed's performance.) Point 2: Should the Portlet API provide dedicated methods for SAX output ? This means that the methods getContentHandler() and getLexicalHandler() would be added to the PortletResponse interface. The motivation behind this is that it should be possible for portlets to output SAX events rather than writing to the output stream so that portal implementations that internally process SAX events can provide document handlers that would directly be invoked by portlets rather than parsing the portlet response's output stream to create SAX events. The result of the JetSpeed Portlet API defining the SAX specific methods as part of the core API would be that the Portlet API depends on the org.xml.sax package (JAXP). The SAX specific methods are unlikely to be accepted as part of a prospective Portlet API standard. Adding the SAX methods would de-facto separate portlets into two kinds - portlets writing to the output stream and portlets sending SAX events. Portal implementations would have to be able to run both kinds of portlets, a stream based portal implementation would need to provide an impementation of PortletResponse that receives the SAX events from "SAX Portlets" and writes the content to the output stream, a SAX based portal implementation would need to parse the content written to the portlet's output stream by "Stream Portlets" to create appropriate SAX events. This seems technically feasible, but there is disagreement on whether the SAX methods are appropriate for a standard Portlet API or not. (My Opinion (TS): Although it seems technically feasible, we should
Re: [vote] Portlet API - Compromise
Hi,
I'm meanwhile convinced, that this discussion won't lead to a consensus, if
each of us keeps defending his view on a technical level. However, I really
like to find a compromise that everybody can agree on. On a meta level of
this discussion, I can see the point that it would hurt the "SAX advocates"
more, if there is no way of producing direct SAX output, than it'd be the
other way round. That's why we where trying to find a way of integrating
the SAX requirements, without integrating the additional methods. I think
we have found a good way that might be acceptable for all of us. :-)
The basic idea is that the Portlet API defines the interfaces and default
implementations of abstract portlet classes (that are subclassed by the
actual portlets). A certain portlet container implementation could replace
these default implementations and make use of extensions that are specific
to this portlet container implementation:
(Note: The following picture is best viewed with a fixed width font, e.g.
"Courier New")
Portlet Container API Portlets
_
| |
v---. | | v---.
PortletRequest | I |-|-|--| |
'---' | | | |
| | | I | Portlet ( 1 )
v---. | | | |
PortletResponse | I ||-|---| |
'---' | | '---'
| | | __|__
| | | | |
| | | | |
^ | | ^ ^
,---. | |v---. v---.
ResponseImpl| C ||~|~~~ |AC | |AC |( 2 )
'---' | |'---' '---'
| | SaxPortlet StreamPortlet
| | | |
| | | |
| | ^ ^
| |,---. ,---.
| || C | | C |( 3 )
| |'---' '---'
|_|aSaxPortlet aStreamPortlet
Level (1) contains interfaces defined by the API.
Level (2) are classes and abstract classes that implement these interfaces.
On the portlet side, these implementations are part of the Portal API,
however, it is the portlet container's choice whether to use these
implementations or to replace them. (All classes and interfaces checked
with "v" are part of the portlet_api.jar, so to speak).
If a portlet container does replace the abstract class SaxPortlet, then
SaxPortlet has specific knowledge about the portlet container's
implementation of the response. Now the portlet container's ResponseImpl
can provide additional methods such as "getContentHandler()" and the
specific implementation of SaxPortlet can savely cast the PortletResponse
to ResponseImpl and make use of these additional methods (""). We
consider this a safe break of the Portlet API contract.
Level (3) are actual portlet instances. They extend the abstract portlet
classes of level (2). They will run properly no matter whether the derived
abstract classes are the default implementations or the portlet container's
replacements.
There can be different requirements for the different portlet types, e.g:
A portlet that derives from SaxPortlet would be required to return full
documents, whereas the StreamPortlet is required to return specified markup
fragments. The default implementation of SaxPortlet (and others that may
follow) is to do portlet-level "post-processing" and map the full document
to the fragment as required by the portlet container. We can decide whether
to do so with supplied stylesheets or by wiring the content handler(s)
accordingly.
Does this sound like a reasonable approach?
ingo.
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
Santiago Gala wrote: Do you mean that javax.servlet.* is more standard than javax.xml.* (Trax and Jaxp)? What I am trying to point out is that it is not good for a standard Java API depend on other Java APIs that are not part of the JDK classes. If you look at javax.servlet for example, it has no dependencies on any other Java extension, only on classes and interfaces in the JDK classes. Whenever possible, dependencies of Java APIs to classes/interfaces that are not JDK classes should be avoided. Maybe it is true, but I can't see it. The servlet API contains a specific method of creating output, namely writing to a response stream. Writing to the response stream just seems like the natural way of outputting content to me - and probably to many people used to write servlets. I think this is different than using SAX, DOM, or ECS. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Santiago Gala [EMAIL PROTECTED] on 02/14/2001 03:56:45 AM Please respond to "JetSpeed" [EMAIL PROTECTED] To: JetSpeed [EMAIL PROTECTED] cc: Subject: Re: [vote] Portlet API [EMAIL PROTECTED] wrote: I think it is useful to provide a little summary of the current state of the discussion. I tried to give a neutral summary on each item, followed by my opinion. Point 1: Should JetSpeed require portlets to produce full documents ? Producing full documents means that the portal implementations would need to decide which parts of complete documents returned by portlets should actually be embedded in the overall page created by the portal. The motivation behind this - as Raphael described it - is that there are no guidelines defined for fragments that should be returned by portlets for markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline for portlet developers should be "Portlets must output well-formed (complete) documents conforming to the DTDs required by the client devices" instead of "Portlets should return well-formed document fragments suitable for aggregation in well formed documents conforming to the DTDs required by the client devices". The result of JetSpeed requiring portlets to produce full documents would be that all content generated by portlets would need to be post-processed by the portal implementation. There seems to be agreement that this introduces significant performance and memory overhead compared to portlets directly writing fragments to the portlet output stream without post-processing. There is disagreement on whether the resulting performance and memory overhead is acceptable or not. That depends on the use. I agree that imposing this requirement is not right. The decision to postprocess should be up to the implementor. (My Opinion (TS): We have implemented a portal that serves HTML, WML, VoiceXML and cHTML. The portlets directly write mark-up fragments to the output stream using JSPs or Stylesheets without post-processing, which is very fast. Forcing all content to be post processed through a SAX parser would impose an unacceptable performance degradation on our portal. We can make guidelines for content fragments that should be created by portlets available to resolve the issue of missing guidelines. My opinion is that we should under no circumstances require complete documents to be returned by portlets, as this woud introduce an inherent limitation of JetSpeed's performance.) I agree that postprocessing should not be mandatory. But if we don't have event processing in the API it is not optional, but nearly impossible. There is an activity for the specification of XML fragments (XHTML, WML, VoiceML, ...). http://www.xmlhack.com/read.php?item=1067 describes it. (Taken from Jetspeed xmlhack channel). To me, the requirement of outputting documents looks too strong, and short term sighted. There is ongoing effort to specify how to describe valid XML fragments, and the trend is to have markup languages that follow a schema/DTD (XML). Point 2: Should the Portlet API provide dedicated methods for SAX output ? This means that the methods getContentHandler() and getLexicalHandler() would be added to the PortletResponse interface. It could be done with other methods, possibly using only javax.xml.transform.* classes. The motivation behind this is that it should be possible for portlets to output SAX events rather than writing to the output stream so that portal implementations that internally process SAX events can provide document handlers that would directly be invoked by portlets rather than parsing the portlet response's output stream to create SAX events. It will allow the following things: - More modular design of a portal, as portl
Re: [vote] Portlet API
Raphael Luta wrote: At 23:56 13/02/2001 +0100, you wrote: I think it is useful to provide a little summary of the current state of the discussion. I tried to give a neutral summary on each item, followed by my opinion. Thomas, I think it's a very good summary of the issues. I have just 2 things to add/modify to this. - Point 1 should be titled: "Should the Portlet API require portlets to produce full documents ?" Yes, that's a better title, we are actually talking about the Portlet API here. Wer're not discussing (yet) the Jetspeed implementation, which may support both full documents and document fragments through configuration elements external to the proposed standard Portlet API (for example the portlet deployment descriptors that were proposed in the first Portlet API discussion 3 months ago) The document fragments need to be in the standard and the full documents need to be prohibited by the standard (see below). This not only my opinion, but also what our customers and other portal vendors I already talked to about Portlet API standardization are saying. If you look at the web sites of Oracle, BEA, and other portal vendors, you will see that they are also using document fragments (see also Ingo Rammer's note listing Oracle's guidelines). We'd hardly find a single major portal vendor who would be in favour of requiring full documents in the standard that require mandatory post-processing that will slow down his implementation and lead to bad benchmark results. Just today I visited a very large portal customer at their headquarters and talked to their technical experts and technical decision makers the whole day. One topic was of course aggregation and they were very happy with the approach to use portlets that write document fragments directly to the output stream one after the other. They asked whether we would create temporary objects/strings or do any post-processing and were only satisfied after I assured them that everything is written directly to the output stream without any performance or memory overhead. We cannot change this. Ok, I guess now I've stressed this point more than enough ;) - I think we should add to this summary the following notice: The Jetspeed community has decided to start specifying a portlet API that could be proposed as a standard for all portal implementations. Offering a standard API between portals only makes sense if the portals implementing the API can guarantee to the portlet writers complying to implementation they are deployed upon: "write once, deploy anywhere" This is the reason why the Portlet API should define both the programmatic API as such, but also the content guidelines that portlet writers should follow to achieve portability and possibly the deployment process. I absolutely agree that content guidelines (or better rules) that portlet programmers/designers must follow should be defined in addition to the programmatic Portlet API. I think these rules need to contain the following items: * A general statement saying that portlets must return document fragments suitable for aggregation in the client's expected mark-up language and may not return full documents. * Detailed Specs of Fragments for particular mark-up languages: - A HTML Fragment Specification for Portlets - A WML Fragment Specification for Portlets - A cHTML Fragment Specification for Portlets - A VoiceXML Fragment Specification for Portlets - Fragment Specifications for other mark-up languages We can provide the fragment specs for HTML, WML, cHTML and VoiceXML. These specs along with the specification of the programmatic Portlet API and the Portlet Archive format will enable "write-once, deploy everywhere" for portlets. Once these specifications are available, tools can be written that take templates created by visual tools and strip off the tags before deployment of portlets, rather than stripping off the tags at run-time in a post-processing step for each request. By the way, the rules we use for HTML fragments in our projects at IBM are basically identical to Oracle's that Ingo Rammer has posted, I guess it is just common sense that leads to these guidelines. The guidelines for the other mark-up languages may be a little bit trickier, but certainly doable. Point 1: Should JetSpeed require portlets to produce full documents ? Producing full documents means that the portal implementations would need to decide which parts of complete documents returned by portlets should actually be embedded in the overall page created by the portal. The motivation behind this - as Raphael described it - is that there are no guidelines defined for fragments that should be returned by portlets for markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline for portlet developers should be "Portlets must output well-formed (complete) documents conforming to the DTDs required by the client devices"
Re: [vote] Portlet API
At 22:24 12/02/2001 +0100, you wrote: Raphal Luta wrote: snip templating system description Point 1: Should the Portlet API mandate that portlet only output full documents rather than document fragments ? You mean here "proper" markup? This is more radical thant point 2. And impossible to enforce unless getWriter() disappears or expensive parsing is done with each portlet output. Even for our current SAX model, portlets otput documents that are acceptable as parts of the "global" page DTD. For instance portlet.../portlet This is a document on its own, but is also part of the document that composes the page as a whole. Thus, for us this will be true. But I wonder if it can be true for everybody. Even for us, in some cases HTML fragments are bundled as CDATA (this will not work with WML) and passed through. We are trying to get rid of this, but it will not be easy until when most sites generate XHTML. Yes this has a lot more consequences that Point 2, that's why I put it first :) I know that requiring full document output will necessarily add a post-processing step after the portlet output so this will cost some performance. But let's consider I'm a portlet writer writing a portlet that will generate WML output (WML is not as easily nestable as HTML). I will use the Portlet API and plan that my portlet will be run in several different portal implementations: - one based on Turbine/Velocity - one based on Cocoon 2 - one based on JSP/Struts If I can't output full wml decks, what guidelines should I follow that make sense for all these portals ? Personnally I can't find any, that's why I'm promoting the use of complete documents generation by the portlets. -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: [vote] Portlet API
At 22:35 12/02/2001 -0800, you wrote: Ive been reading this thread with interest. I have some comments, questions and suggestions: Point #1 - Portlet API mandate that portlets only output full documents rather than document fragments: - There is some confusion WRT portlets producing document fragments vs full documents. AFAIK, this is a new concept to Jetspeed, with the exception of Ingo Rammer's WebPagePortlet. This seems to be a complicated process. How would one go about defining the translation of, for ex., a BODY tag to a DIV tag. How do you go about specifying which tags are discarded? Saying that, after some consideration, it does makes sense. When creating portlets, Im often stripping away the headers of HTML. Then there is the issue of merging JavaScript and CSS, namespace conflicts. Do you plan on addressing these issues? As for performance, yes it will be slower, but would we be applying this post-processing with every request? The implementations would be smart enough to do some kind of caching of documents. I hope Raphael can give us some details of the motivation... The motivation is that I can't think of good output guidelines for the main target markups ((X)HTML, WML, SMIL, VoxML, FO) that will be the obvious choices for all portal implementations. Also I'd rather write an API that specifies: "Portlets output must be well-formed document. The must be valid for the DTDs supported by the portal implementation" rather than: "If your portlet produces HTML, should wrap all your markup in a table element, if your portlet produces WML, you should produce a sequence of card elements but can't use templates, etc." See what I mean ? ;/ Is it possible to support both fragments and full documents? Isn't this something that could be configured in the Portlet Configuration - PostProcessing=false That would not answer the main issue (delievring fragments working for all implementations) but could allow portlet writers to write "dirty" portlets taylored for one implementation and thus achieve maximal performance for this implementation. Definitely something to consider. Point #2 - add getContentHandler(), getLexicalHandler() to PortletResponse interface: Implementors who do not use SAX will be required to implement these methods (in a abstract base class that does nothing). The implementation is trivial, just serialize all the events to a byte stream. What is the problem with having a dependency on SAX (JAXP)? None that I'm aware of. -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
David, Implementors who do not use SAX will be required to implement these methods (in a abstract base class that does nothing). It's worse than that. A portlet relying on SAX will not work in that case. That means we have to introduce something that says "I require SAX and if you don't implement, I am not going to run". Portlet portability adios! Cheers, Thomas - Original Message - From: "David Sean Taylor" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Tuesday, February 13, 2001 7:35 Subject: RE: [vote] Portlet API Ive been reading this thread with interest. I have some comments, questions and suggestions: Point #1 - Portlet API mandate that portlets only output full documents rather than document fragments: - There is some confusion WRT portlets producing document fragments vs full documents. AFAIK, this is a new concept to Jetspeed, with the exception of Ingo Rammer's WebPagePortlet. This seems to be a complicated process. How would one go about defining the translation of, for ex., a BODY tag to a DIV tag. How do you go about specifying which tags are discarded? Saying that, after some consideration, it does makes sense. When creating portlets, Im often stripping away the headers of HTML. Then there is the issue of merging JavaScript and CSS, namespace conflicts. Do you plan on addressing these issues? As for performance, yes it will be slower, but would we be applying this post-processing with every request? The implementations would be smart enough to do some kind of caching of documents. I hope Raphael can give us some details of the motivation... Is it possible to support both fragments and full documents? Isn't this something that could be configured in the Portlet Configuration - PostProcessing=false Point #2 - add getContentHandler(), getLexicalHandler() to PortletResponse interface: Implementors who do not use SAX will be required to implement these methods (in a abstract base class that does nothing). What is the problem with having a dependency on SAX (JAXP)? Im trying to find some parallels here, how this kind of duality of interfaces has been handled in other designs. Im thinking of some kind of adapter for SAX, assuming that streams are the standard. -- david -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
At 18:44 12/02/2001 +0100, you wrote: At 14:12 02/12/01, Raphal Luta wrote: Following the discussions on the Portlet API, there's no strong consensus on the following points of the Portlet API and so they should be voted upon. For those who did not follow the arguments, pleae read the "Secure Portlets" thread in the mail archive before voting. Point 1: Should the Portlet API mandate that portlet only output full documents rather than document fragments ? I don't really get this point. How could portlets output full documents, doesn't it always have to be a fragment? Or are you thinking in XML documents that are stripped don to fragments later? Sorry, I really don't undersand this point. See my response to Santiago and David. I think it's very important to conciously decide on this point and not rely a what is done currently. Point 2: Should we add a getContentHandler() and getLexicalHandler() in the PortletResponse interface ? A portlet will not be able to use both getWriter() and getContentHandler() in the same request response. I share the demurs of Thomas: Sax and XML is very popular at the moment, but most general are still streams. I'm not sure if it's wise to open the door for specialized ways of content passing: What if other "standards" want their own interface too, what if the Sax interface changes (it did change often in the past!). I think the SAX API is pretty stable now and is a good choice for handling "high level" communication between portal and portlet if the portal implementation supports it. This would really put the stability of out portal API at a risk. The problem is that once those methods are in the interface and portlets are programmed against it, we are dammed to support them in the engine if we don't want to scare the people away from the portlet interface. Sure, but the implementation is trivial if you don't want to do high level communication. The alternative - not quite as nice, but still good - is to do all processing on the portlet side of the API: A Saxlet could take the XML output of the SaxPortlets, do all necessary processing, and produce a markup stream. This is really stupid if you want to postprocess the aggregated page on the other side of the API, in the portal engine, I agree with you. Yet, the question for me is: is there really a need for doing so? First the SAXlet approach does not work, unless you hardcode a "SAXlet" for your portal implementation and expose to this SAXlet all your implementation functionalities. What this means basically is that you reimplement a portal within the context of the Portlet API. This makes no sense. Second, post-processing can occur both before aggregation (post-processing of the portlet output) and after aggregation (post-processing of the complete portal output). The SAXlet approach is stupid for the first case and is irrelevant for the second case since if you post-process the aggregate result you have to buffer the complete aggregation result however you produce it. Now if the question is; is postprocessing required ? My answer is: it's a portal implementation decision (unless we chose to restrict full doucment output for portlets in which case the answer would always be yes) If the question is: is there a need for a SAX interface ? My answer is: yes, because some portal implementations may have different design goals that optimizing for speed and SAX will certainly the best API for high level communication and processing between portlet and portal. So I think Point 2 is better fomulated as: "Is there a requirement for postprocessing the whole portal page in the servlet engine after the aggregation (alternativ 1) or is it sufficient to take the XML and convert it into markup on the portlet side of the API (alternative 2)?" With alternative 1 there is the danger of making the portlet API more complicated and (that's important!) *less stable*. Is this a fair way of putting it? No, you completely miss the point. Providing SAX methods in the API just enables high level communication between Portal and portlets if the portal implementation wants it this way. It give the freedom to portal developers to chose whatever level of post-processing they like and still have an optimized way to communicate with the portlet. It does not impact the performance of native stream based portal and portlet implementations. It *does not* imply any implementation constraint for the portal (apart from the implementation of a trivial SAX-byte stream serializer). Also, SAX is at least as stable as the Servlet API. SAX and post-processing are 2 independant issues. Post-processing is decided by the portal implementor (but if you chose to implement a lot of post-processing, using the SAX streams rather than the byte streams will probably be more efficient) -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris --
Re: [vote] Portlet API
At 22:04 12/02/2001 +0100, you wrote: Raphael, I think we should not decide on these two points as isolated items, they need to be put into perspective to make sure that everybody fully understands the consequences and implications before voting. The larger question behind this is whether we want JetSpeed to be a high-performance, highly scalable portal engine usable for portals under a high load or whether we are willing to accept mediocre/poor performance/scalability which would inhibit use of JetSpeed in larger projects that need high performance and scalability. I think this is where we diverge: the issue at hand is whether we try to create a generic Portlet API which may fit very different model or whether we do an optimized version of the portlet API for our planned 1.3 implementation. You'd like to limit the API to only methods that would be useful for our implementation. I'd like to extend it to fit an possible alternate model. snip I think we should decide for the first option so that JetSpeed gets the chance to evolve into industry strength software like the Apache HTTP Server. The inclusion of SAX calls is completely unrelated to performance (what will impact the performance is if we require full documents rather than fragments) To give you an example, our portal implementation uses JSPs or to generate all output, portlets may use JSPs or stylesheets, everything is written directly to the servlet's output stream, we have reduced per-request memory usage and per-request processor usage as far as possible to achieve the required performance and scalability. We have no need for any kind of post-processing, as our portlets create appropriate markup-fragmentsa and dynamic URL lookup within JSPs entirely avoids the need of URL postprocessing. Your implementation is optimized for speed at the cost of markup robustness. Your have no guarantee that another implementation will accept the exactly same document fragments that your portlets produce. If the vote on point 1 would be yes, this would result in severe performance problems: If the portlet API mandates full documents, this would require costly post-processing to strip off parts during content aggregation. It is much more efficient to have each portlet write a document fragment to the output stream at the appropriate point in time during page aggregation than to have each portlet create a complete document in the form of SAX events, send all these events to a document handler that drops the parts that are not required and finally writes the relevant parts to the output stream. Did you measure by which factor the SAX parsing will reduce performance and increase memory usage per request compared to straight JSP processing ? Yes. It's a tradeoff between robustness and performance. In your portal implementation, you chose performance. In Jetspeed 1.3, we may chose the same but we would be very short-sighted if we don't provide the API for writing other implementations with other design goals. Even if there would be post-processing, portlets could still screw the entire portal by producing large amounts of valid XML, producing well-formed but invalid XML (e.g. invalid WML), or using up the JVMs memory. In all portal projects I have seen so far, portlets were tested before they were deployed and it was the responsibility of the portlets to produce correct mark-up. Of course (although SAX is memory efficient). Are you aware of other projects that try to create a generic cross-implementation portlet API ? You can't say to a portlet developper in one hand: we provide you with a generic API, you just need to write you portlet against our API and it will run correctly on whatever portal implementation supports this API and on the other hand: you need to taylor portlet output for each portal you're deployed on. I think there's a contradiction somewhere. The introduction of a getContentHandler() method to the Portlet interface seems like a compromise that would allow for the SAX approach in addition to the stream-based appropach, but it would force all portal container implementations to implement both mechanisms and it would introduce a direct dependency of the portlet interface and thus the Portlet API to the interface org.xml.sax.DocumentHandler. Of courcse the org.xml.sax package will become a part of J2EE 1.3, but nonetheless I think the Portlet API should not depend on the XML API, it should only depend on core java classes as it currently does. As we intend to turn the Portlet API into a standard, we should not add special methods for such specific tasks as doing SAX event handling. Personally I don't mind tying the API to JAXP/SAX. For me the issue is this: Your API is efficient and perfectly fits your need and design requirements but does not cover some of *my* requirements for an portal implementation (not Jetspeed 1.3 but another project) based on SAX. If the API does not cater for this need, my only logical conclusion is that I
Re: [vote] Portlet API
Man, this discussion gets going now :-0 Santiago, Raphael, You keep referencing the "simple implementation" of the SAX handler, but I am sorry guys: you are not drawing the complete picture here. And while you do so, I would suggest everybody stays away from voting on this issue. Let me give you an example: Assume a portlet that generates HTML output (fragment or whole, it doesn't matter). Part of the HTML is a URL which needs to be resolved against the portal. Now case a) the portlet uses streams. The output is generated straight into the output stream of the portlet response. The URL is generated by Portlet URI (because that's what it is for). So, the URL is already properly inserted into the stream. No need for post-processing here. (Except if the document is a complete one, we need to strip it - I'll cover that topic down below). Consider case b) where the portlet uses SAX events. It would call the appropriate methods on ContentHandler. The URL would be given as is. The ContentHandler implementation takes the event, processes them and puts them into the output stream. THING IS: a "simple implementation" just dumps everything into the stream. No processing here, in particular, the URL is left alone which means *wrong* output is generated. So, it's not that simple. But wait, you'll be saying to yourself "hey, that's unfair, because the URI could be generated using Portlet URI in the SAX case as well as in the stream case. True! But the whole point of the SAX event story was, to enable post-processing. I think I understand now, Raphael, where your "80%" assumption comes from. And indeed, if we were to say "Portlet, return a whole document" that would be the case. But let's face reality (no, not the Jetspeed reality, but *reality*) - how much content is there generated by XSPs (ie. Cocoon2)? The majority comes from static or dynamic server pages of one kind or another, even Velocity does so. Allowing full page document generally as the content returned from portlets seems completely unacceptable. There may be the odd content that *is* a full page (eg. coming from a legacy app) but that can be dealt with an HTML/WML/etc portlet of which a number have been reported on lately. But the general portlet should return a fragment. And yes, ugly as it may be, that requires the Portlet API to specify what and what cannot be returned from a portlet. Well, it is not terribly nice, but not that bad either. But again, that means that either SAX events would either require a similar statement, a "simple implementation" is not possible since the stream aggregation will not aggregate correct pages, because through the SAX mechanism complete output would be injected into the otherwise correct page. Now I will shut up and not comment on this particular topic anymore. Cheers, Thomas B. - Original Message - From: "Santiago Gala" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Tuesday, February 13, 2001 14:14 Subject: Re: [vote] Portlet API Thomas F. Boehme wrote: David, Implementors who do not use SAX will be required to implement these methods (in a abstract base class that does nothing). It's worse than that. A portlet relying on SAX will not work in that case. That means we have to introduce something that says "I require SAX and if you don't implement, I am not going to run". Portlet portability adios! This is not true. I will give you a default implementation that streams the ContentHandler into the ResponseWriter. It is efficient and very simple to implement. This can be the default for any portal that does not want to have higher level processing of SAX events. In fact, javax.xml.transform.stream.StreamResult already provides such an implementation. Cheers, Thomas -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
Raphal Luta wrote: Following the discussions on the Portlet API, there's no strong consensus on the following points of the Portlet API and so they should be voted upon. For those who did not follow the arguments, pleae read the "Secure Portlets" thread in the mail archive before voting. According to the voting rules, -1 is blocking, blah blah... This scares me, as I would strongly like to have a consensus proposal. So, we should refine more the questions. I will not vote yet. I will explain once more why I need these calls: Our templating system is composed of XSLTStylesheets. There are (or could be) portlet level templates, but there are also global templates (layout, page, navigation, soon template...). With the current proposal, our "child" portlets will have to handle their output to a new layout system to avoid expensive reparsing of the output of each portlet when the "layout" processing is done. With the proposal of getContentHandler(), we can send this output straight into the template stylesheet. This is similar to what Turbine does now: allowing the use of the response writer or outputting ECS objects. With the portlet proposal as is, we would have to reparse the output of each portlet and regenerate events to process our templates. If we don't get through this extension, our implementation will have to extend this API to achieve efficiency, and we will be, effectively, creating a new de facto API for our implementation. Our proposal will enable our portlets running in standard engines, while they would be more efficient in XML aware environments. We would be doing "embrace and extend" with the portlet API, and I don't want this to happen. On the other hand, with Raphal's solution, if you reuse a (one of my) XSLTPortlet in a jsp or velocity based implementation, all you have to do is to plug the "SAXStreamer" as ContentHandler of my XSLTPortlet and serialize there. As my portlet would not have donoe this effort, there is no redundant work. If your portlet container is XML aware, it could be processed in a different way, while if not, it will be streamed as it is evaluated. I agree that DOM (maybe ECS) could be asked for. But we already said that DOM can be turned into SAX very easily, and proper ECS also. Thus once you have the basic additions to the API, DOMPortlet and ECSPortlet are simple to implement using this API. (Note: if you use a StringElement of ECS to embed markup, this will not work. But this is dirty anyway) Point 1: Should the Portlet API mandate that portlet only output full documents rather than document fragments ? You mean here "proper" markup? This is more radical thant point 2. And impossible to enforce unless getWriter() disappears or expensive parsing is done with each portlet output. Even for our current SAX model, portlets otput documents that are acceptable as parts of the "global" page DTD. For instance portlet.../portlet This is a document on its own, but is also part of the document that composes the page as a whole. Thus, for us this will be true. But I wonder if it can be true for everybody. Even for us, in some cases HTML fragments are bundled as CDATA (this will not work with WML) and passed through. We are trying to get rid of this, but it will not be easy until when most sites generate XHTML. Point 2: Should we add a getContentHandler() and getLexicalHandler() in the PortletResponse interface ? A portlet will not be able to use both getWriter() and getContentHandler() in the same request response. I need these calls to avoid expensive processing, so my vote is obvious (although I will not vote formally until the issues are clearer). :) -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
Raphael, Please let us clearify your questions a bit more (see my comments below). At 14:12 02/12/01, Raphal Luta wrote: Following the discussions on the Portlet API, there's no strong consensus on the following points of the Portlet API and so they should be voted upon. For those who did not follow the arguments, pleae read the "Secure Portlets" thread in the mail archive before voting. Point 1: Should the Portlet API mandate that portlet only output full documents rather than document fragments ? I don't really get this point. How could portlets output full documents, doesn't it always have to be a fragment? Or are you thinking in XML documents that are stripped don to fragments later? Sorry, I really don't undersand this point. Point 2: Should we add a getContentHandler() and getLexicalHandler() in the PortletResponse interface ? A portlet will not be able to use both getWriter() and getContentHandler() in the same request response. I share the demurs of Thomas: Sax and XML is very popular at the moment, but most general are still streams. I'm not sure if it's wise to open the door for specialized ways of content passing: What if other "standards" want their own interface too, what if the Sax interface changes (it did change often in the past!). This would really put the stability of out portal API at a risk. The problem is that once those methods are in the interface and portlets are programmed against it, we are dammed to support them in the engine if we don't want to scare the people away from the portlet interface. The alternative - not quite as nice, but still good - is to do all processing on the portlet side of the API: A Saxlet could take the XML output of the SaxPortlets, do all necessary processing, and produce a markup stream. This is really stupid if you want to postprocess the aggregated page on the other side of the API, in the portal engine, I agree with you. Yet, the question for me is: is there really a need for doing so? So I think Point 2 is better fomulated as: "Is there a requirement for postprocessing the whole portal page in the servlet engine after the aggregation (alternativ 1) or is it sufficient to take the XML and convert it into markup on the portlet side of the API (alternative 2)?" With alternative 1 there is the danger of making the portlet API more complicated and (that's important!) *less stable*. Is this a fair way of putting it? ingo. -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API
Raphael, I think we should not decide on these two points as isolated items, they need to be put into perspective to make sure that everybody fully understands the consequences and implications before voting. The larger question behind this is whether we want JetSpeed to be a high-performance, highly scalable portal engine usable for portals under a high load or whether we are willing to accept mediocre/poor performance/scalability which would inhibit use of JetSpeed in larger projects that need high performance and scalability. There will be more design decisions where we have to choose between performance/scalability/reliability on one side and something convenient, something nice or cool on the other side and these decisions will depend to a certain extent on our answer to the more fundamental question raised above. I think we should decide for the first option so that JetSpeed gets the chance to evolve into industry strength software like the Apache HTTP Server. To give you an example, our portal implementation uses JSPs or to generate all output, portlets may use JSPs or stylesheets, everything is written directly to the servlet's output stream, we have reduced per-request memory usage and per-request processor usage as far as possible to achieve the required performance and scalability. We have no need for any kind of post-processing, as our portlets create appropriate markup-fragmentsa and dynamic URL lookup within JSPs entirely avoids the need of URL postprocessing. If the vote on point 1 would be yes, this would result in severe performance problems: If the portlet API mandates full documents, this would require costly post-processing to strip off parts during content aggregation. It is much more efficient to have each portlet write a document fragment to the output stream at the appropriate point in time during page aggregation than to have each portlet create a complete document in the form of SAX events, send all these events to a document handler that drops the parts that are not required and finally writes the relevant parts to the output stream. Did you measure by which factor the SAX parsing will reduce performance and increase memory usage per request compared to straight JSP processing ? Even if there would be post-processing, portlets could still screw the entire portal by producing large amounts of valid XML, producing well-formed but invalid XML (e.g. invalid WML), or using up the JVMs memory. In all portal projects I have seen so far, portlets were tested before they were deployed and it was the responsibility of the portlets to produce correct mark-up. The introduction of a getContentHandler() method to the Portlet interface seems like a compromise that would allow for the SAX approach in addition to the stream-based appropach, but it would force all portal container implementations to implement both mechanisms and it would introduce a direct dependency of the portlet interface and thus the Portlet API to the interface org.xml.sax.DocumentHandler. Of courcse the org.xml.sax package will become a part of J2EE 1.3, but nonetheless I think the Portlet API should not depend on the XML API, it should only depend on core java classes as it currently does. As we intend to turn the Portlet API into a standard, we should not add special methods for such specific tasks as doing SAX event handling. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- Raphael Luta wrote: Following the discussions on the Portlet API, there's no strong consensus on the following points of the Portlet API and so they should be voted upon. For those who did not follow the arguments, pleae read the "Secure Portlets" thread in the mail archive before voting. Point 1: Should the Portlet API mandate that portlet only output full documents rather than document fragments ? Point 2: Should we add a getContentHandler() and getLexicalHandler() in the PortletResponse interface ? A portlet will not be able to use both getWriter() and getContentHandler() in the same request response. -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: [vote] Portlet API
Ive been reading this thread with interest. I have some comments, questions and suggestions: Point #1 - Portlet API mandate that portlets only output full documents rather than document fragments: - There is some confusion WRT portlets producing document fragments vs full documents. AFAIK, this is a new concept to Jetspeed, with the exception of Ingo Rammer's WebPagePortlet. This seems to be a complicated process. How would one go about defining the translation of, for ex., a BODY tag to a DIV tag. How do you go about specifying which tags are discarded? Saying that, after some consideration, it does makes sense. When creating portlets, Im often stripping away the headers of HTML. Then there is the issue of merging JavaScript and CSS, namespace conflicts. Do you plan on addressing these issues? As for performance, yes it will be slower, but would we be applying this post-processing with every request? The implementations would be smart enough to do some kind of caching of documents. I hope Raphael can give us some details of the motivation... Is it possible to support both fragments and full documents? Isn't this something that could be configured in the Portlet Configuration - PostProcessing=false Point #2 - add getContentHandler(), getLexicalHandler() to PortletResponse interface: Implementors who do not use SAX will be required to implement these methods (in a abstract base class that does nothing). What is the problem with having a dependency on SAX (JAXP)? Im trying to find some parallels here, how this kind of duality of interfaces has been handled in other designs. Im thinking of some kind of adapter for SAX, assuming that streams are the standard. -- david -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
