Re: Portlet API 2
on 2/2/01 4:50 AM, "Thomas F. Boehme" [EMAIL PROTECTED] wrote: Folks, a few minutes ago we (ie. Ingo) posted the javadocs for Portlet API 2. It is in /proposals department in CVS. All those interested in a common standard for portlets (hopefully even beyond Jetspeed implementations) are invited to comment on the API. ahhh...I see (ignore my email about why checking in javadoc is bad), why didn't you also check in the code? Window and message handling should be well-known concepts, but action handling may not be that obvioius. The intention here is to enable a portlet to attach its own actions to a url without having to deal with the url itself. As soon as a portlet does more than replaying information it found in other places on the web, you get to a point where the portlets needs links or buttons in its content. For example, to finish personalizing a portlet you a "Save" or "Finish" button, or a to-do-list portlet may have an entry field and an "Add" button at the bottom of the current list to add new to-dos. Implementing these has been very tricky so far, because the next screen may be different from the activity you want to perform. The "Save" button, for example, needs to bring the portlet from PERSONALIZE mode to DEFAULT mode, but before doing so the portlet needs to save the posted data which is obviously not the part of the DEFAULT but of the PERSONALIZE mode. This is where actions come in. The url will be constructed for the destination mode (DEFAULT in this case), but a SaveAction can be implemented and attached to the DEFAULT url (whatever it may look like). When the request comes in from the browser, the action(s) are dealt with first, before the service() method is called, similar to the way actions and screens are called in Turbine (thanks Jon for this paradigm). Now, I shall add that all events (actions, messages, and window) are delivered to the respective portlet(s) before the service() methods are called. Therefore, the portlet has a chance to save the posted data before the markup for the new page is generated. Why aren't you just using Turbine's action processing? I don't see a need to abstract this at all. The log() methods on the context have been morphed into a separate class (PortletLog) which provides simplistic log levels. I think this should now be more than enough for that the portlet may log. Plus it's high-level enough to plug different mechanism underneath. -1. Use Turbine's Logging mechanism. This has been recently completely revamped and is *excellent* now as it is backed by Log4J. thanks, -jon -- Honk if you love peace and quiet. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Portlet API 2
on 2/2/01 1:16 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: the intent of this Portlet API is not only to be used in JetSpeed, we envision this API to evolve into a standard. +1 I'm an idiot. -jon -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Portlet API Requirements List
Raphael Luta wrote: [EMAIL PROTECTED] wrote: I volunteer to put together a Portlet API Requirements List that we can put on the web site. Please post your requirements to the JetSpeed list with the topic "Portlet API Requirements", and I'll include them in the document. I'm looking forward to your input :) Great. I've added some comments to some of your requirements in order to foster discussion and provide my own requirements at the end. - The Portlet API should allow for definition of service interfaces and for registration of services implementing particular service interfaces, e.g. - User info (for getting user info like name, address, age...) - Persistence (for storing per-user, per-portlet settings) - Location (for obtaining the user's location) - Personalization (for storing/getting personalization info) - Data (access to databases, schema-to-object mappings) - Content (access to syndicated content) - Cache (access to URLs via caches) - ... Rationale: This allows to have a stable API core that can be extended by services as required. Portals implementing the Portlet API can provide implementations for a subset of the services defined in the Portlet API. I'm not sure what you're saying there: You want the Portlet API to provide a service lookup interface. Yes. The definition of the real services interface would be external to the Portlet API. Yes, the idea is to have a Portlet API and a set of additional standard service interfaces for tasks like the ones listed above. No portal would be required to implement a given service. Correct ? Yes. Each portal could decide which subset of services it wants to provide and how they should be implemented. However, I expect a persistence service and user info service would be provided by virtually all portals, because they are necessary to allow portlets to store settings and obtain info about the user in a standard way. My own requirement not previously listed : - the Portlet API should allow only well-formed XML compliant output from the Portlet. Rationale: this would guarantee that the portal can always post-process the portlet output if needed and would prevent a portlet from breaking the display with a non well-formed output. You mean XML, WML, XHTML, VoiceXML would be ok, but HTML with missing end tags should not be generated ? Is this really a requirement to the API or rather a requirement for portlets to "behave well" by generating only well-formed XML ? It's the only one I can add right now. -- Raphaël Luta - [EMAIL PROTECTED] Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: Portlet API
Hello: Is your AdvancedFileServer portlet free? I would like to use it in my personal project. Thanks in advance, Pablo Lambert: [EMAIL PROTECTED] Ingeniero de Proyectos - REUNA Canada 239 Providencia. Chile. Fono: 56.2.3370337 Fax: 56.2.2040865 -Mensaje original- De: Lerenc, Vedran [SMTP:[EMAIL PROTECTED]] Enviado el: martes 7 de noviembre de 2000 7:41 Para: 'JetSpeed' Asunto: RE: Portlet API Hi, I want to add some more words to the topic of incorporating documents from the web into the portal. I am working with Marcus and refereing to David Sean Taylor's answer on Marcus' posting concerning an "advanced file server". Your discussion is very relevant to some of the problems I am experiencing. My portal is aggregating web pages from several different sources, and frequently from the same company's intranet where they seem to reuse stylesheets and scripts, but they make minor changes to them So yes, you are describing a real headache for me right now. It was and still is a headache to us, because Jetspeed is doing nothing along these lines to help incorporate arbitrary documents into the portal. So we started to write an AdvancedFileServer which forwards cookies from the portal's sources to the client's browser and vice versa, rewrites relative URLs to absolute URLs, redirects HTML hyperlinks to the portal which then gathers the originally requested document and incorporates this into the portal, redirects HTML form actions to the portal in the same ways as hyperlinks are redirected, includes JavaScript files into the page, so that, e.g. JavaScript variables or HTML form input variables can be escaped to avoid name clashes and to allow addressing and assigning escaped HTML form input variables inside JavaScript code. CSS could be handled in the same way as JavaScript includes: Load them, escaped them and include them into the returned page. In summary: There is still much more work to do, also due to the great amount of wrong but browser-accepted HTML code in the web, but right now we can e.g. include www.amazon.com into a portlet and fill our shopping cart right inside our personlized portal page or request finance.yahoo.com to list quotes whose symbols we entered inside a portlet. Beside the fact that the solution is incomplete and will stay incomplete for a long time, the actual portlet approach helps, but isn't enough. We need to access the generated portal page header and the table row and cell the content is stored in. I am new to the portlet API discussion, but thought that incorporating arbitrary documents from the web into the portal should somehow be taken into consideration when thinking about something like a portlet API. In any case this topic should be adressed by the community to avoid so many people either rewriting their content or writing something similar to the AdvancedFileServer we had to write. Thanks, Vedran -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: Portlet API - Regarding Different Porlet Types
Mike, This "philosophical thought train" is already on the go. Santiago's SAXlet ideas go into the very same direction. At the current stage, I am -1 on the idea, but that's mainly for lack for examples. The nice thing about Santiago's approach is the fact that he still wants to be open for the other types of portlets (I wouldn't call them legacy, though). Having different types is not (only) a weakness, but it allows you to say: "hey, why don't you write a portlet? It's easy because you can use this and that method, and all the other ones too!" A JSP portlet, for example, is an easy path for people who have done lots of web app programming and have all the right tools at hand. The problem I see with SAXlets or any related idea, is the lack of support by tools and the limitation of flexibility. Agreed, flexibility comes with some dangers, but together with tools support the benefits outweigh the disadvantages. Again, some examples may be shedding new light on this subject, not just for me, but others too. Cheers, Thomas Boehme - Original Message - From: "Michael Rimov" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 08, 2000 01:19 Subject: Portlet API - Regarding Different Porlet Types Hello All! This is a more philisophical thought train on the overall design of the Portlet API: I think that one of the weaknesses of the Jetspeed implementation is that you have all these different portlet types depending on the type of content that the portlet is actually dealing with. (And its not even dependant upon the final information the portlet is rendering) [Example: Cocoon portlet vs RSS portlet, vs JSP portlet etc. etc.] Instead of throwing all these portlet types for every content type, why don't we have a processing pipeline that would take care of the basic download / transformation, etc. We then would have to set up the generic portlet API to be independent of the actual data returned, but have attributes to allow the portlet container to figure out what it needs to do with the data returned. Any thoughts on this? I'll be more than happy to start coming up with some concrete examples, but I'd really like to know if people are interested in exploring this possibility first. Thanks, -Mike -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
[EMAIL PROTECTED] wrote: Raphael Luta wrote: [EMAIL PROTECTED] wrote: I'm not sure what exactly you mean - wouldn't different forms in different portlets have different targets to which the parameters would get posted ? I'm not sure it's actually possible but if you have a way for a portal to implement this I'm definitely interested. I was thinking about something like this: Assume we have several portlets in a page, which contain forms. Through a rewriting mechanism, the targets of each form could be rewritten to include the portlet ID as a parameter. A central request dispatcher could be used to route each incoming post request to the portlet with the portlet ID specified in the request. However I guess I may be thinking of another scenario than you - real portlets designed for use in a portal instead of portlets wrapping legacy web apps. I believe we are actually thinking of the same thing: creating a parameter separation by using an GUID parameter for each instance of a portlet present in the page. There're may be an additionnal need for namespace separation if the portal needs some portal-variables set in the same request. Of course things are much more complicated if we are talking about portlets that include legacy pages and the targets are not portlets that follow a certain programming model but arbitrary web applications. I guess the mails posted by Marcus Schwarz and Vedran Lerenc give a good impression of the problems that occur in these scenarios. I think we need to differentiate between two different scenarios: - Implementation of portlets exploiting the portal's Portlet API and Framework, adhering to applicable design guidelines. - Implementation of portlets that encapsulate legacy web applications, where these legacy apps cannot be changed. The Portlet API and framework should allow for easy and efficient implementation of portlets for the first scenario. +1 For handling the second scenario, complicated mechanisms for rewriting, handling of cookies and probably other issues may be built into the portal implementation, but they should not impact the portlet API. I even think such capabilities should be handled by the portlet itself just like the AdvancedFilePortlet presented. There will never be a proper way to aggregate different legacy documents in a single page. I'm not sure how exactly this works ... Could you post a little example that shows how an XMLPortlet would generate an HTML page with some XML data and how it would output the XML data ? Well, first I think XMLPortlet is not a good name because everything should be XML in Portlet space, let's call it DataPortlet. Let's take as an example a MailPortlet which retrieves the content of a MailBox. 1st case: MailPortlet extends Portlet The Portal creates a PortletRequest which asks for "luta" mailbox in XHTML1.0 format, no table (for my PDA). It also creates a PortletResponse object in which it puts a reference to its HTML serializer as ContentHandler and then calls the Portlet service method. The Portlet does the following in its service method: - get the ContentHandler from the PortletResponse and use it as target for its generated SAX events. - get the content of luta mailbox - set the XML namaespace of the result to XHTML URI. - format and output the result as XHTML without tables, sending SAX events as elements are created. The portal may do several rewritings/filterings of the events before sending the final output to the client. 2nd case: MailPortlet extends DataPortlet The Portal creates a PortletRequest which asks for "luta" mailbox in XHTML1.0, no table format. It creates a PortletResponse object in which it puts a reference of a PortletRenderer (portal implementation specific) object. The portal then calls the build() method instead of service(). The Portlet does the following in its build method: - get the ContentHandler from the PortletResponse and use it as target for its generated SAX events. - get the content of luta mailbox - set the XML namaespace of the result to a well-known mail description markup. - format and output the result, sending SAX events as elements are created. As soon as the PortletRenderer recieves the root element with the namespace declaration, 2 things may occur: * the Renderer knows how to render this markup in a system specific, it forwards the events to a MailRendered element which may be shared by all portlets in this portal. * the Renderer does not know how to deal with this markup (maybe it's proprietary stuff after all), it uses the DataPortlet as ContentHandler and forwards all the events back to the portlet for rendering (note: the example API provided does not currently handles how the portlet forwards its rendered content beck to the portal). So if the portal knows how to handle the data markup, the processing chain is: | V MailPortlet.build();
Re: Portlet API
[EMAIL PROTECTED] wrote: snip a lot of stuff a customization descriptor will be very useful. An example might be an e-mail portlet: CUSTOMIZATION DESCRIPTOR TITLEE-mail Portlet Settings/TITLE ATTRIBUTE NAMEMail Server Address/NAME TYPEText/TYPE /ATTRIBUTE ATTRIBUTE NAMEUser ID/NAME TYPEText/TYPE /ATTRIBUTE ATTRIBUTE NAMEPassword/NAME TYPEText/TYPE /ATTRIBUTE CUSTOMIZATION DESCRIPTOR/ Comments ? This might get a little hectic when you're talking about a system with a batch of portlets. I could easily conceive of 30 or more configuration files having to be maintained at any given time. In my case, I plan on having all the my portlet-specific configuration information stored in a central database. I didn't mean to imply that the customization descriptors should necessarily be stored in files - storing them in databases should be an option of course. Also, please note that what I posted here was only a simple example to start a more detailed discussion - a more detailed example with many good ideas has been posted by Raphael recently. I think all "interface" documentsor data structure defined with the API or with Jetspeed should use an XML description. How these XML documents will be stored and retrieved is an implementation issue and may depend on any persistence method (database, flat file, ...). To give a little flexibility to the situation why don't we have the portal query the portlet for the descriptor? If the descriptor is an XML file, the portlet can feed the contents of the XML file to the containing portal. In my case, I can query the database, create my own in-memory XML to feed to the portal and send it on its way. Or instead of just using XML to pass information to the containing portal, we could have a Javabean that has a Vector of "attribute classes" as well as standard properties that we want that we pass instead? Wouldn't this be a bit more efficient, and by having vectors of attributes in the beans, we could have something fairly extensible without the portal container having to do a batch of parsing every time it wanted to know about its portlets? [Of course, the portlet could still have its own configuration stored in an xml file which it then translates to the configuration bean, but in any case, it gives us the flexibility of defining our own configuration mechanisms we could even have the xml configuration descriptor as the default implementation so portlet implementors wouldn't have to roll-their- own each time.] If I understand you correctly, you mean this: Customization Customization Descriptors in Descriptors Entries Portlet Registry XML Filein a Database | | +-+ +-+ | Portlet | or| Portlet | +---+-+-+-+-+ | Portlet API | +---+ || || XML Cust. or Cust. Description Bean Description created from XML Description || || \/ \/ +---+ | Portlet Customizer | +---+ i.e. 4 Combinations of the following would be thinkable: - Portlets getting info from XML File - Portlets getting info from Database Entries - Portlets passing Customization Description as Java Bean - Portlets passing Customization Description as XML The Customization Descriptor concept would be exposed though the portlet APIs, Portlets would read the customization info and pass it. I don't think portlet should be aware of their descriptor or even know how to retrieve their cutomization properties. Let's not forget that we're defining a generic interface which can be supported by many portal products with very different capabilities. I also think the envisioned customization mechanism should access the portlet customization description via a well defined interface. This interface needs not necessarily be the Portlet interface, another option would be to define a provider interface within the portal, not as a part of the Portlet API. The portlet customizer would access the available portlet customization description provider - be it file based or using a database - via the same description provider interface: +---+ | Portlet Customizer
Re: Portlet API
David Sean Taylor wrote: Im looking over your configuration design and it reminds of something I've been meaning to research: Prowler. Is anyone familiar with it? http://www.infozone-group.org/projects_main.html +---+ | Portlet Customizer| +---+ | Portlet Cust.Description Provider Interface | +-+--+--+ | File Based Impl | or | Impl. using Database | +-+ +--+ | | Customization Customization Descriptors in Descriptor Entries Portlet Registry XML Filein a Database What I see in common is the abstraction from how the XML customization is stored as in your above diagram. I believe Prowler provides this abstraction under a transaction-controlled api. Prowler is another open-source EIP project whose main focus is to provide an industrial strength XML content management system. As such there are several synergies possible with Jetspeed: - use Jetspeed as the interface to Prowler repositories (and other data sources as well) - Jetspeed may also use Prowler content management system in its implementation for managing its configuration and preferences documents. I've alreay notified the prowler list that they are most welcome to participate in the Portlet API discussion so that we can be sure to integrate with their content management system. -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: Portlet API
-Original Message- From: Raphael Luta [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 7. November 2000 06:20 To: JetSpeed Subject: Re: Portlet API [EMAIL PROTECTED] wrote: . For handling the second scenario, complicated mechanisms for rewriting, handling of cookies and probably other issues may be built into the portal implementation, but they should not impact the portlet API. I even think such capabilities should be handled by the portlet itself just like the AdvancedFilePortlet presented. There will never be a proper way to aggregate different legacy documents in a single page. I disagree, because especially if you want to take care about namespaces, prefixes for variables/javascript functions, cookies and so on, this should be places inside of the framework, because only the framework knows each source inside of an page and can check inter-dependencies. Some other stuff like changing relative to absolute URLs can be inside of the portlet. In our case this was just an easy and quick way to enable this functionality. From an architectural perspective I would preffer to have some parts of this functionality inside of the framework. Marcus -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API - Portlet communication andportletchaining/pipe lining
"Lerenc, Vedran" wrote: Of course things are much more complicated if we are talking about portlets that include legacy pages and the targets are not portlets that follow a certain programming model but arbitrary web applications. I guess the mails posted by Marcus Schwarz and Vedran Lerenc give a good impression of the problems that occur in these scenarios. I think we need to differentiate between two different scenarios: - Implementation of portlets exploiting the portal's Portlet API and Framework, adhering to applicable design guidelines. - Implementation of portlets that encapsulate legacy web applications, where these legacy apps cannot be changed. The Portlet API and framework should allow for easy and efficient implementation of portlets for the first scenario. For handling the second scenario, complicated mechanisms for rewriting, handling of cookies and probably other issues may be built into the portal implementation, but they should not impact the portlet API. Hmm, if this functionality would be build into the portal, then it should be possible to switch it on and off, because it's quite time consuming and not neccessary to perform for well known portlets (first scenario). Therefore we have chosen the way of the AdvancedFileServer model. If we want to incorporate a not well known source (second scenario), we set the portlet's parent to our AdvancedFileServer and define it's behaviour using portlet parameters (rewrite URLs or not, etc.). Following this approach we are quite separated from the core, but still, we could make use of the generated portal page's header or table row/cell the portlet is copied into. I would think that the portlet API is a way to access that information. If we take a closer look, it seems quite legitimate to have access to the generated portal page - after all we also have access to the HTTPServlet response which is part of the actual "portlet API". Both, content and response belong together, because the content is generated using the response's writer. But that's just a minor issue, born out of out problems getting the whole picture, when being limited by the current architeure and view of a single portlet, not knowing what's around on the page. You could also think about a more advanced portlet communication infrastruture then we have implemented so far using HTML form input parameters, escaped and sent between portlets by reloading the portal page. That surely is an interesting topic for the portlet API. We at our project had such requirements, so we added this feature in a very rough way to our AdvancedFileServer. That is good. We have been discussing the issues previously, and I think a component around these lines will be needed in Jetspeed. Another issue is that only one portlet object is run to render a portlet's view, e.g. you may only specify the AdvancedFileServer to render an external source, but what if this source serves content based on a Cocoon transformation? You would have to implement something combining the AdvancedFileServerPortlet and CocoonPortlet. What about portlet chaining/pipelining, i.e. setting up a chain like having a source rendered by the CocoonPortlet and then rendering the result by the another portlet, like the AdvancedFileServerPortlet? With regards to the chaining of portlet requests, it does not look natural to me. It belongs more to a product like Cocoon. Even if there are no good mechanisms today for rendering XML content in the Servlet API, I'm quite sure that they will appear, as the compilation of SAX events in Cocoon and other ideas we spoke about at the ApacheCON are quite natural to be extended as a different mechanism from the ByteStream based one currently in servlets. I even used the word SAXlets, meaning precisely this, in a previous post. I understand by a SAXlet an object that will generate/transform content in a stream of SAX events, mostly like the Cocoon2 architecture producers, transformers and renderers do. It would be something similar to servlets, but much more natural in a XML environment. The servlet API should be extended in the future to deal with the mix of these objects and "standard" servlets, as chaining SAX events is simpler than having to regenerate XML and re-parse at the next inclusion level. I hope that the Jetspeed API will be able to handle the three kinds of portlets: - ByteStream based (Servlets or legacy HTTP requests) - Object Tree based (ECS, DOM, other implementations, mostly legacy due to the lack of escalability WRT tree size, but maybe useful in some contexts) - SAX event Stream based (Somethind that will generate, receive or filter events from other components in a chain, that will eventually end in the generation of a ByteStream to the client) The results produced by the last two classes of portlets will be very oriented to the kind of transformations that we will need to render a page.
Re: Portlet API (not really jetspeed)
Marco Romeny wrote:
another important thing is javascript events.
a lot of code normally has a need to be run not
until the page has loaded, ie. onload="" / window.onload
and there is only one event.
This is one of the reasons why I think that we should have event handling and action
registering capabilities in Jetspeed (maybe even in Turbine).
There are quite a few unique things here:
The page
The URI (including Query string namespace)
The Javascript namespace
...
My idea was to specify (for certain events), that they could be triggered on the
server side
or on the client side. One good example is form validation. If the media is capable,
the
server could render the form with validating Javascript functions to do the validation
at
the browser. If the media does not have scripting capabilities, all form fields would
be
validated back at the server.
I once wrote a function popToFunc(code) which would
append a javascript code (if string) or function to an
existing/non-existing function.
function popToFunc(funcdesc,code){
if(!eval('window.'+funcdesc)) eval('window.'+funcdesc +'=function
(){\na=1}');
func=eval('window.'+funcdesc).toString();
eval('window.'+funcdesc+'='+func.replace(/function
\w*\(([\s\w,]*)\).*\{([\W\s\w]*)\}/g,
'function
($1){$2\n'+(typeof(code)=='function'?code+'()':code)+';\n}'));
}
use:
popToFunc('hello','alert(3)');
hello(); -- alerts 3
popToFunc('hello','alert(4)');
hello(); -- alerts 3, alerts 4
popToFunc('hello',function (){alert(5)}); // good if you dont want to escape all
you do
hello(); -- alerts 3, alerts 4, alerts 5
popToFunc('hello',hello);
hello(); -- alerts 3, alerts 4, alerts 5, alerts 3, alerts 4, alerts 5
haven't tested it throughly, but this would resolve the problems with the
customizer i think.
Can you be more specific?
I have very little time and a lot of bugs to fix.
I think I could try to fix it, but I would need more specific help.
Add Function.prototype.append=function (code){popToFunc(this.toString(),code)}
and you can use hello.append('alert(6)') which looks nicer. make sure hello exists...
/m
"Schwarz, Marcus" wrote:
-Original Message-
From: Raphael Luta [mailto:[EMAIL PROTECTED]]
Sent: Samstag, 4. November 2000 13:15
To: JetSpeed
Subject: Re: Portlet API
- this may create problems with form handling because the
portal *needs*
to
make sure there are no variable name collisions.
I'm not sure what exactly you mean - wouldn't different
forms in different
portlets have different targets to which the parameters
would get posted ?
I'm not sure it's actually possible but if you have a way for a portal
to implement this I'm definitely interested.
Variables/functions:
I also think collisions are really a problem. But they can not just happen
to
variables but also to Javascript functions. As we are mixing up several
different information sources together into one HTML page the probability
that some variables/Javascript functions are named equal is quite high.
I don't think that styleguides are very helpful for this problem, because
very often one wants to include foreign (mostly HTML based) sources/apps
into
the framework, which are not under his control.
We have to prefixing all incoming variables and functions with an GUID.
So there are no collisions and also later it's possible to identify the
source of the variable (-- the related portlet). We have a prototyp
implementation of a porlet, which is handling this stuff using a HTML parser
and a replacement (the problem is: of course you have to replace the
variables
also in all Javascript parts, which are referencing them...).
I think that functionality should later clearly be a feature of the portal
framework, not of the portlet. Only the framework have all informations to
enable such a relation between variables and their sources.
relative URLs
Also we have to rewrite incoming relative URLs. E.g. images are often
relativley
linked (e.g. ../../imageex.jpg), which will clearly not work inside of the
portal.
They have to be substituted with absolute URLs.
Because we just need knowledge about one source this functionality can be
inside
of a portlet (e.g. advanced file server).
links:
If we want to have interactive portlets, we want to have the effect, that
after
e.g. a form-action inside of the portlet is launched not the whole portal is
away, but just the context of the one portlet is replaced by the result.
Therefore
we have to replace links (action, href) with links to the portal. Of course
we have to remember the original location. One way e.g. in the case of forms
would
be to add a new parameter:
INPUT type="hidden" name="GUID.redirect" value"orginalURL"
RE: Portlet API
Puh, that text is longer as planned, I hope somebody is reading it:-) Marcus, don't worry I read it all and Im thankful i did Your discussion is very relevant to some of the problems I am experiencing. My portal is aggregating web pages from several different sources, and frequently from the same company's intranet where they seem to reuse stylesheets and scripts, but they make minor changes to them (i believe this is called the cutpaste antipattern which seems to be prevalent these days). So yes, you are describing a real headache for me right now. These pages each have their own HTMLHEADTITLE and within the HEAD they each have their own cascading stylesheets and scripts. In an open, api-based environment, I am not sure how the API can address these kinds of collision problems. As Thomas Schaeck stated, guidelines "How-to-write-portlets Guide" may be necessary. One guideline may be for scripts and stylesheets to always be stored in separate files, perhaps some kind of registration of these resources could be formalised and requested by the portal before requesting the content of each portlet. In any case, much of the content that I am working most always comes from pre-existing sources, and I always need to edit it, rewrite urls etc, before incorporating it in the portal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Schwarz, Marcus Sent: Sunday, November 05, 2000 12:21 PM To: 'JetSpeed' Subject: RE: Portlet API -Original Message- From: Raphael Luta [mailto:[EMAIL PROTECTED]] Sent: Samstag, 4. November 2000 13:15 To: JetSpeed Subject: Re: Portlet API - this may create problems with form handling because the portal *needs* to make sure there are no variable name collisions. I'm not sure what exactly you mean - wouldn't different forms in different portlets have different targets to which the parameters would get posted ? I'm not sure it's actually possible but if you have a way for a portal to implement this I'm definitely interested. Variables/functions: I also think collisions are really a problem. But they can not just happen to variables but also to Javascript functions. As we are mixing up several different information sources together into one HTML page the probability that some variables/Javascript functions are named equal is quite high. I don't think that styleguides are very helpful for this problem, because very often one wants to include foreign (mostly HTML based) sources/apps into the framework, which are not under his control. We have to prefixing all incoming variables and functions with an GUID. So there are no collisions and also later it's possible to identify the source of the variable (-- the related portlet). We have a prototyp implementation of a porlet, which is handling this stuff using a HTML parser and a replacement (the problem is: of course you have to replace the variables also in all Javascript parts, which are referencing them...). I think that functionality should later clearly be a feature of the portal framework, not of the portlet. Only the framework have all informations to enable such a relation between variables and their sources. relative URLs Also we have to rewrite incoming relative URLs. E.g. images are often relativley linked (e.g. ../../imageex.jpg), which will clearly not work inside of the portal. They have to be substituted with absolute URLs. Because we just need knowledge about one source this functionality can be inside of a portlet (e.g. advanced file server). links: If we want to have interactive portlets, we want to have the effect, that after e.g. a form-action inside of the portlet is launched not the whole portal is away, but just the context of the one portlet is replaced by the result. Therefore we have to replace links (action, href) with links to the portal. Of course we have to remember the original location. One way e.g. in the case of forms would be to add a new parameter: INPUT type="hidden" name="GUID.redirect" value"orginalURL" Also we have to take care, that all variables are routed to this URL (e.g. form parameters). That should also be a functionality of the portal. We will post a proposal for this soon. Cookies: The last problem is, that some dynamic sources will use cookies to store information in the user's browser. This is not working in the current approach, because currently cookies are set against the portal, not the user's browser. Therefore we have to take care, that cookies are routed to the browsers by the portal and the same way back to the portlet/information source. Another possibility would be to store them inside of the session at the portal. Both approaches have advantages and disadvantages. This should also be a feature of the portal framework. Puh, that text is longer as planned,
RE: Portlet API
Hi, I want to add some more words to the topic of incorporating documents from the web into the portal. I am working with Marcus and refereing to David Sean Taylor's answer on Marcus' posting concerning an "advanced file server". Your discussion is very relevant to some of the problems I am experiencing. My portal is aggregating web pages from several different sources, and frequently from the same company's intranet where they seem to reuse stylesheets and scripts, but they make minor changes to them So yes, you are describing a real headache for me right now. It was and still is a headache to us, because Jetspeed is doing nothing along these lines to help incorporate arbitrary documents into the portal. So we started to write an AdvancedFileServer which forwards cookies from the portal's sources to the client's browser and vice versa, rewrites relative URLs to absolute URLs, redirects HTML hyperlinks to the portal which then gathers the originally requested document and incorporates this into the portal, redirects HTML form actions to the portal in the same ways as hyperlinks are redirected, includes JavaScript files into the page, so that, e.g. JavaScript variables or HTML form input variables can be escaped to avoid name clashes and to allow addressing and assigning escaped HTML form input variables inside JavaScript code. CSS could be handled in the same way as JavaScript includes: Load them, escaped them and include them into the returned page. In summary: There is still much more work to do, also due to the great amount of wrong but browser-accepted HTML code in the web, but right now we can e.g. include www.amazon.com into a portlet and fill our shopping cart right inside our personlized portal page or request finance.yahoo.com to list quotes whose symbols we entered inside a portlet. Beside the fact that the solution is incomplete and will stay incomplete for a long time, the actual portlet approach helps, but isn't enough. We need to access the generated portal page header and the table row and cell the content is stored in. I am new to the portlet API discussion, but thought that incorporating arbitrary documents from the web into the portal should somehow be taken into consideration when thinking about something like a portlet API. In any case this topic should be adressed by the community to avoid so many people either rewriting their content or writing something similar to the AdvancedFileServer we had to write. Thanks, Vedran -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
Raphael Luta wrote:
[EMAIL PROTECTED] wrote:
- the portal can't easily guarantee that the aggregated result will
display
correctly on a given device because the markup generated by one
portlet
may
alter the markup of the whole page.
Yes, to make it work, the portlets have to follow some guidelines
regarding
generated mark-up. We intend to write a "How-to-write-portlets Guide"
that
does
not only explain use of the API but also contains such guidelines for
generated
mark-up.
I don't really believe in the effectiveness of guidelines, especially not
when they're not enforceable: developpers are as good in following
guidelines as they are in documenting their code ;/
Yes, guidelines only help those who follow to them. However, portlet
programmers who want their portlets to work well will probably follow
guidelines that help them make things work. (This doesn't help with
legacy pages that are not designed for use in portlets, though.)
- the portlet writer has the responsability to implement all its
supported
format. The portal administrator can't just add support for an
additionnal
format without altering the portlet.
- this may create problems with form handling because the portal
*needs*
to
make sure there are no variable name collisions.
I'm not sure what exactly you mean - wouldn't different forms in
different
portlets have different targets to which the parameters would get
posted ?
I'm not sure it's actually possible but if you have a way for a portal
to implement this I'm definitely interested.
I was thinking about something like this: Assume we have several portlets
in a page, which contain forms. Through a rewriting mechanism,
the targets of each form could be rewritten to include the portlet ID as
a parameter. A central request dispatcher could be used to route each
incoming post request to the portlet with the portlet ID specified in
the request. However I guess I may be thinking of another scenario than
you - real portlets designed for use in a portal instead of portlets
wrapping legacy web apps.
Of course things are much more complicated if we are talking about
portlets that include legacy pages and the targets are not portlets
that follow a certain programming model but arbitrary web applications.
I guess the mails posted by Marcus Schwarz and Vedran Lerenc give a good
impression of the problems that occur in these scenarios.
I think we need to differentiate between two different scenarios:
- Implementation of portlets exploiting the portal's Portlet API and
Framework, adhering to applicable design guidelines.
- Implementation of portlets that encapsulate legacy web applications,
where these legacy apps cannot be changed.
The Portlet API and framework should allow for easy and efficient
implementation of portlets for the first scenario.
For handling the second scenario, complicated mechanisms for rewriting,
handling of cookies and probably other issues may be built into the
portal implementation, but they should not impact the portlet API.
I'd think the best way to design the API will be to first define a
generic
Portlet API which require the Portlet to output a completely rendered
content, and then create a sub-interface XMLPortlet (or DataPortlet
or
whatever) that would provide additionnal entry points on the portlet
so
that
the portal could query a portlet independently for either its "data"
output
or its "layout" output.
In any case, I believe we should always require the portlet to output
XML
compliant markup, even if it's a already a layout markup (for
example
XHTML
instead of HTML) so that if needed, the portal can easily
post-process
any
output.
I think this is flexible enough so that it'll not create a major
concern
of portability.
Sounds good. We are currently doing work on the generic Portlet API.
I'm looking forward to your ideas about the XMLPortlet.
XMLPortlet or whatever would be actually quite simple, something like:
public interface XMLPortlet extends Portlet, ContentHandler {
/*
The content output by this method should be
in a data markup
*/
public void build( PortletRequest rq,
PortletResponse rs,
PortletContext ctx );
}
It may need to also extend LexicalHandler but I'm not sure.
Of course, this construct implies that the generic Portlet
outputs SAX events and the XMLPortlet may just act as both a
XML SAX event producer as the Portlet and SAX event consumer so that
it may itself transform its data markup in layout markup.
So to make this work, we would need for example to define
something like:
interface PortletResponse {
/** other methods */
public ContentHandler getContentHandler();
}
In the case of the generic Portlet API, the Portal itself would
register itself in the PortletResponse as recipient of
RE: Portlet API
Im looking over your configuration design and it reminds of something I've
been meaning to research: Prowler.
Is anyone familiar with it? http://www.infozone-group.org/projects_main.html
+---+
| Portlet Customizer|
+---+
| Portlet Cust.Description Provider Interface |
+-+--+--+
| File Based Impl | or | Impl. using Database |
+-+ +--+
| |
Customization Customization
Descriptors in Descriptor Entries
Portlet Registry XML Filein a Database
What I see in common is the abstraction from how the XML customization is
stored as in your above diagram.
I believe Prowler provides this abstraction under a transaction-controlled
api.
From reading the online docs, I would say Prowler is an xml-based content
management system with some versioning and
transaction support. I could see how Jetspeed can use Prowler as a source
for its content via the Prowler Java
API and tag library. Transactions and versioning could be very valuable.
I also need to disclaim: Ive just discovered Prowler a few days ago. I
believe its open source but I really don't know much about it.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
Sent: Monday, November 06, 2000 1:48 PM
To: JetSpeed
Subject: Re: Portlet API
Note: The most interesting part of this mail is at the end.
Micheal Rimov wrote:
snip snip
public void service( PortletRequest rq, PortletResponse rs,
PortletContext
ctx )
I know exactly what you mean. In the proposal we are currently working
on,
the portlet context is also passed as the third parameter of the service
method, I think that's the way to go.
Agreed!
...
disclaimer I'm not a particularly hot designer./disclaimer :-)
The problem as I see with this method of going about it is that today it
will be WAP devices, but tomorrow it will be something totally different
that we'll be having to provide capabilities for, and I really would like
to keep the core API as stable as possible.
So what if we start providing a "PortalServices" interface that allows us
to plug in arbitrary services for which we define the actual abstract
class
API for each service later as the need arises. In our specification we
will then have a list of optional services that a portlet container may
implement. So for a [very rough] pseudocode example we have:
interface PortalService { /*blah blah blah*/ }
class LocatorService implements PortalService { /*blah blah blah*/}
And then within the portlet we have:
LocatorService ls = (LocatorService)ctx.getService("Locator");
if (ls == null)
{
throw new Exception("Unable to locate an implementation of the
Locator Service");
}
Well, you get the idea (I hope :-) )
Anyway, I believe something along this line would allow us to keep the
core
API pretty much intact, as well as allow people that want to play with
implementing a PortletContainer to do so without having to provide for a
batch of services they don't care about.
Any thoughts on this?
We're currently looking into the service approach in detail. We may have
services for location, persistence of portlet settings, obtaining user
information, potentially others.
There's one additional very important thing to consider :
customization.
How does a portal know what parameters can be set for a given Portlet
?
How do we build an UI for customization ? Should we let the Portlet
give us a specific UI for handling its customization (in case of
complex
Portlets ?).
Our approach for this is to let the portlets provide the UI and logic
for
their customization.
I agree completely with this. I have a fairly nice "state-machine"
framework that I would be using for my own porlets and would prefer to be
not restricted by a standardized UI.
snip snip
For me, a Portlet is basically a Servlet and JavaBeans/EJB mix.
I would propose to handle customization by mandating Portlet to
provide
a descriptor file describing its operational parameters. The portal
should
provide a default UI implementation for entering parameters based on
this
descriptor but the Portlet may register a specific Customizer for
handling
complex needs.
This is a great idea! We expect that most of the portlets we'll
implement
will require specific customization, but there will be a lot of cases
were
a customization descriptor will be very useful. An example might be an
e-mail
portlet:
CUSTOMIZATION DESCRIPTOR
TITLEE-mail Portlet Settings/TITLE
ATTRIBUTE
NAMEMail Server Address/NAME
RE: Portlet API
Eric, Seems like you invested alot of time and work into this problem. I assume your AdvancedFileServer extends FileServerPortlet. Are you doing the url rewrites etc on the fly during getContent() or in a preprocessing stage, outside of the portal? Sounds like its happening on the fly, which leads me to think that amazon is running in full-screen application mode. I totally agree with you: I am new to the portlet API discussion, but thought that incorporating arbitrary documents from the web into the portal should somehow be taken into consideration when thinking about something like a portlet API. In any case this topic should be adressed by the community to avoid so many people either rewriting their content or writing something similar to the AdvancedFileServer we had to write. Do you have any rough ideas of how the AdvancedFileServer would work in the future portlet api? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Lerenc, Vedran Sent: Monday, November 06, 2000 1:44 PM To: 'JetSpeed' Subject: RE: Portlet API Hi, I want to add some more words to the topic of incorporating documents from the web into the portal. I am working with Marcus and refereing to David Sean Taylor's answer on Marcus' posting concerning an "advanced file server". Your discussion is very relevant to some of the problems I am experiencing. My portal is aggregating web pages from several different sources, and frequently from the same company's intranet where they seem to reuse stylesheets and scripts, but they make minor changes to them So yes, you are describing a real headache for me right now. It was and still is a headache to us, because Jetspeed is doing nothing along these lines to help incorporate arbitrary documents into the portal. So we started to write an AdvancedFileServer which forwards cookies from the portal's sources to the client's browser and vice versa, rewrites relative URLs to absolute URLs, redirects HTML hyperlinks to the portal which then gathers the originally requested document and incorporates this into the portal, redirects HTML form actions to the portal in the same ways as hyperlinks are redirected, includes JavaScript files into the page, so that, e.g. JavaScript variables or HTML form input variables can be escaped to avoid name clashes and to allow addressing and assigning escaped HTML form input variables inside JavaScript code. CSS could be handled in the same way as JavaScript includes: Load them, escaped them and include them into the returned page. In summary: There is still much more work to do, also due to the great amount of wrong but browser-accepted HTML code in the web, but right now we can e.g. include www.amazon.com into a portlet and fill our shopping cart right inside our personlized portal page or request finance.yahoo.com to list quotes whose symbols we entered inside a portlet. Beside the fact that the solution is incomplete and will stay incomplete for a long time, the actual portlet approach helps, but isn't enough. We need to access the generated portal page header and the table row and cell the content is stored in. I am new to the portlet API discussion, but thought that incorporating arbitrary documents from the web into the portal should somehow be taken into consideration when thinking about something like a portlet API. In any case this topic should be adressed by the community to avoid so many people either rewriting their content or writing something similar to the AdvancedFileServer we had to write. Thanks, Vedran -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: Portlet API - Portlet communication and portletchaining/pipe lining
Of course things are much more complicated if we are talking about portlets that include legacy pages and the targets are not portlets that follow a certain programming model but arbitrary web applications. I guess the mails posted by Marcus Schwarz and Vedran Lerenc give a good impression of the problems that occur in these scenarios. I think we need to differentiate between two different scenarios: - Implementation of portlets exploiting the portal's Portlet API and Framework, adhering to applicable design guidelines. - Implementation of portlets that encapsulate legacy web applications, where these legacy apps cannot be changed. The Portlet API and framework should allow for easy and efficient implementation of portlets for the first scenario. For handling the second scenario, complicated mechanisms for rewriting, handling of cookies and probably other issues may be built into the portal implementation, but they should not impact the portlet API. Hmm, if this functionality would be build into the portal, then it should be possible to switch it on and off, because it's quite time consuming and not neccessary to perform for well known portlets (first scenario). Therefore we have chosen the way of the AdvancedFileServer model. If we want to incorporate a not well known source (second scenario), we set the portlet's parent to our AdvancedFileServer and define it's behaviour using portlet parameters (rewrite URLs or not, etc.). Following this approach we are quite separated from the core, but still, we could make use of the generated portal page's header or table row/cell the portlet is copied into. I would think that the portlet API is a way to access that information. If we take a closer look, it seems quite legitimate to have access to the generated portal page - after all we also have access to the HTTPServlet response which is part of the actual "portlet API". Both, content and response belong together, because the content is generated using the response's writer. But that's just a minor issue, born out of out problems getting the whole picture, when being limited by the current architeure and view of a single portlet, not knowing what's around on the page. You could also think about a more advanced portlet communication infrastruture then we have implemented so far using HTML form input parameters, escaped and sent between portlets by reloading the portal page. That surely is an interesting topic for the portlet API. We at our project had such requirements, so we added this feature in a very rough way to our AdvancedFileServer. Another issue is that only one portlet object is run to render a portlet's view, e.g. you may only specify the AdvancedFileServer to render an external source, but what if this source serves content based on a Cocoon transformation? You would have to implement something combining the AdvancedFileServerPortlet and CocoonPortlet. What about portlet chaining/pipelining, i.e. setting up a chain like having a source rendered by the CocoonPortlet and then rendering the result by the another portlet, like the AdvancedFileServerPortlet? Thanks for taking these thoughts into consideration, Vedran -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: Portlet API
Seems like you invested alot of time and work into this problem. I assume your AdvancedFileServer extends FileServerPortlet. It extends FileWatchPortlet. Are you doing the url rewrites etc on the fly during getContent() or in a preprocessing stage, outside of the portal? Sounds like its happening on the fly, which leads me to think that amazon is running in full-screen application mode. It does it on the fly and it runs not in application mode - amazon, yahoo, our intranet site, all that runs as portlet being part of a personalized portal site at the same time - otherwise we wouldn't have that a big issue with name clashes/base URLs and so on. It works all quite well, but still we have problems, e.g. when navigating more than one portlet. When you do that, you lose your navigational path when you navigate another portlet - in the portlet you navigated first you see the orginal page defined in the registry. That's due to the fact, that a portlet has no consciousness. The redirection through the AdvancedFileServer is done using a request parameter - for Jetspeed the displayed content is still the page defined inside the registry. That might be another issue for the porlet API: User/Portlet specific consciousness per session. Do you have any rough ideas of how the AdvancedFileServer would work in the future portlet api? I just joined your discussion and need some time to catch up with you guys on the portlet API (what you have talked about/settled on in the past) - right now our project doesn't give me much time, so I just can contribute problems and our part-solutions (see also RE: Portlet API - Portlet communication and portlet chaining/pipelining). -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
Raphael Luta wrote:
[EMAIL PROTECTED] wrote:
- the portal can't easily guarantee that the aggregated result will
display
correctly on a given device because the markup generated by one portlet
may
alter the markup of the whole page.
Yes, to make it work, the portlets have to follow some guidelines regarding
generated mark-up. We intend to write a "How-to-write-portlets Guide" that
does
not only explain use of the API but also contains such guidelines for
generated
mark-up.
I don't really believe in the effectiveness of guidelines, especially not
when they're not enforceable: developpers are as good in following
guidelines as they are in documenting their code ;/
- the portlet writer has the responsability to implement all its
supported
format. The portal administrator can't just add support for an
additionnal
format without altering the portlet.
- this may create problems with form handling because the portal *needs*
to
make sure there are no variable name collisions.
I'm not sure what exactly you mean - wouldn't different forms in different
portlets have different targets to which the parameters would get posted ?
I'm not sure it's actually possible but if you have a way for a portal
to implement this I'm definitely interested.
I'd think the best way to design the API will be to first define a
generic
Portlet API which require the Portlet to output a completely rendered
content, and then create a sub-interface XMLPortlet (or DataPortlet or
whatever) that would provide additionnal entry points on the portlet so
that
the portal could query a portlet independently for either its "data"
output
or its "layout" output.
In any case, I believe we should always require the portlet to output XML
compliant markup, even if it's a already a layout markup (for example
XHTML
instead of HTML) so that if needed, the portal can easily post-process
any
output.
I think this is flexible enough so that it'll not create a major concern
of portability.
Sounds good. We are currently doing work on the generic Portlet API.
I'm looking forward to your ideas about the XMLPortlet.
XMLPortlet or whatever would be actually quite simple, something like:
public interface XMLPortlet extends Portlet, ContentHandler {
/*
The content output by this method should be
in a data markup
*/
public void build( PortletRequest rq,
PortletResponse rs,
PortletContext ctx );
}
It may need to also extend LexicalHandler but I'm not sure.
Of course, this construct implies that the generic Portlet
outputs SAX events and the XMLPortlet may just act as both a
XML SAX event producer as the Portlet and SAX event consumer so that
it may itself transform its data markup in layout markup.
So to make this work, we would need for example to define
something like:
interface PortletResponse {
/** other methods */
public ContentHandler getContentHandler();
}
In the case of the generic Portlet API, the Portal itself would
register itself in the PortletResponse as recipient of the Portlet
markup, whereas in the XMLPortlet case, the Portal may either
register itself as the ContentHandler for the build() output if it
knows how to deal with the data markup or else pipe the events
back to the XMLPortlet for rendering.
The tuple (request, response, context, + other stuff) is called
Environment
in Cocoon 2 or RunData in Turbine.
We could follow this pattern and define
public void service(PortletEnvironment env);
I'd prefer
public void service(PortletRequest req, PortletResponse rsp,
PortletContext context)
as it is similar to the well-known Servlet API and exposes the request/
response concept. The PortletEnvironment would contain both per-request
info
as well as more long-lived info, which might confuse portlet programmers.
I agree, on the other hand, using a wrapper object such as Environment
allows to add new methods or objects in the wrapper without altering
the base API. I'm +0 on either alternative.
If we could have the PortletContext be recovered from the PortletRequest, then we
could have PortletRequest subclassing ServletRequest and PortletResponse
subclassing ServletResponse. Also, PortletConfig would subclass ServletConfig,
and PortletContext ServletContext.
The service call would be identical to the Servlet call
A well-written Portlet could be displayed also as a servlet or a SAXlet (have I
invented the concept?), if it does not depend on any specialized service from the
portal, or if the format for service lookup is the same used in other frameworks
like, for instance, Avalon.
If we could aim to this, it could be very helpful in the long term, as the
Portlet API would be an pure extension of the
RE: Portlet API
-Original Message- From: Raphael Luta [mailto:[EMAIL PROTECTED]] Sent: Samstag, 4. November 2000 13:15 To: JetSpeed Subject: Re: Portlet API - this may create problems with form handling because the portal *needs* to make sure there are no variable name collisions. I'm not sure what exactly you mean - wouldn't different forms in different portlets have different targets to which the parameters would get posted ? I'm not sure it's actually possible but if you have a way for a portal to implement this I'm definitely interested. Variables/functions: I also think collisions are really a problem. But they can not just happen to variables but also to Javascript functions. As we are mixing up several different information sources together into one HTML page the probability that some variables/Javascript functions are named equal is quite high. I don't think that styleguides are very helpful for this problem, because very often one wants to include foreign (mostly HTML based) sources/apps into the framework, which are not under his control. We have to prefixing all incoming variables and functions with an GUID. So there are no collisions and also later it's possible to identify the source of the variable (-- the related portlet). We have a prototyp implementation of a porlet, which is handling this stuff using a HTML parser and a replacement (the problem is: of course you have to replace the variables also in all Javascript parts, which are referencing them...). I think that functionality should later clearly be a feature of the portal framework, not of the portlet. Only the framework have all informations to enable such a relation between variables and their sources. relative URLs Also we have to rewrite incoming relative URLs. E.g. images are often relativley linked (e.g. ../../imageex.jpg), which will clearly not work inside of the portal. They have to be substituted with absolute URLs. Because we just need knowledge about one source this functionality can be inside of a portlet (e.g. advanced file server). links: If we want to have interactive portlets, we want to have the effect, that after e.g. a form-action inside of the portlet is launched not the whole portal is away, but just the context of the one portlet is replaced by the result. Therefore we have to replace links (action, href) with links to the portal. Of course we have to remember the original location. One way e.g. in the case of forms would be to add a new parameter: INPUT type="hidden" name="GUID.redirect" value"orginalURL" Also we have to take care, that all variables are routed to this URL (e.g. form parameters). That should also be a functionality of the portal. We will post a proposal for this soon. Cookies: The last problem is, that some dynamic sources will use cookies to store information in the user's browser. This is not working in the current approach, because currently cookies are set against the portal, not the user's browser. Therefore we have to take care, that cookies are routed to the browsers by the portal and the same way back to the portlet/information source. Another possibility would be to store them inside of the session at the portal. Both approaches have advantages and disadvantages. This should also be a feature of the portal framework. Puh, that text is longer as planned, I hope somebody is reading it:-) Marcus -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
Raphael Luta wrote: - the portal can't easily guarantee that the aggregated result will display correctly on a given device because the markup generated by one portlet may alter the markup of the whole page. Yes, to make it work, the portlets have to follow some guidelines regarding generated mark-up. We intend to write a "How-to-write-portlets Guide" that does not only explain use of the API but also contains such guidelines for generated mark-up. - the portlet writer has the responsability to implement all its supported format. The portal administrator can't just add support for an additionnal format without altering the portlet. - this may create problems with form handling because the portal *needs* to make sure there are no variable name collisions. I'm not sure what exactly you mean - wouldn't different forms in different portlets have different targets to which the parameters would get posted ? I'd think the best way to design the API will be to first define a generic Portlet API which require the Portlet to output a completely rendered content, and then create a sub-interface XMLPortlet (or DataPortlet or whatever) that would provide additionnal entry points on the portlet so that the portal could query a portlet independently for either its "data" output or its "layout" output. In any case, I believe we should always require the portlet to output XML compliant markup, even if it's a already a layout markup (for example XHTML instead of HTML) so that if needed, the portal can easily post-process any output. I think this is flexible enough so that it'll not create a major concern of portability. Sounds good. We are currently doing work on the generic Portlet API. I'm looking forward to your ideas about the XMLPortlet. The tuple (request, response, context, + other stuff) is called Environment in Cocoon 2 or RunData in Turbine. We could follow this pattern and define public void service(PortletEnvironment env); I'd prefer public void service(PortletRequest req, PortletResponse rsp, PortletContext context) as it is similar to the well-known Servlet API and exposes the request/ response concept. The PortletEnvironment would contain both per-request info as well as more long-lived info, which might confuse portlet programmers. Right, the Locator is something of particular interest for mobile devices. However, if loaction awareness is not covered by the Portlet API, there will be no way to write location-aware portlets that runs on different portals. We'd like to make the Locator a property of PortletRequest. If a portal or the user's device is not location aware, getLocator() would just return null. Just implement a "portal service lookup" mechanism in the PortletEnvironment (or PortletConfig) so that the Portlet can query the framework for any "locator" service. An additionnal Locator API can be proposed with the Portlet API. I view such a service as a "value added" optional framework capability that the portlet may wish to take advantage of, but not as central to the basic portal functionality as user authentication. Conceptually, the location is an attribute of requests - the location may change over a sequence of requests originating from the same user, each request may contain different location info. Either the Location has to be a property of the PortletRequest or it must be obtained by passing a request to a locator service that parses the HTTP headers that contain the location info and returns a Location object with a standard interface. May be done like Micheal Rimov proposed ... we have to look into this some more. For simple case, a descriptor file along with some variable validation (a la JavaBean VetoableChange) shoule be used by the framework to construct homogenous UI for the user. However, for complex cases, the Portlet will have to provide its own customizer (or edit mode) because there'll be no easy way for the portal to deal with this. I agree, we need both of these cases. I was thinking of something more complex: ... param name="maxNumOfMail" type="Integer" hidden="yes" "hidden" may be misleading. You mean that this should be visible for users in the role "administrator", right ? What about something like param name="maxNumOfMail" type="Integer" edit_role="Administrator" vs param name="maxNumOfMail" type="Integer" edit_role="User" description Maximum number of mails retrieved /description default5/default /param /parameters !-- maybe other stuff missing -- /portlet Note that this allows the system administrator to determine what is user-settable and should be hidden to user and set only by the site administrator. This will allow to easily adapt a component customization policy based on a site-wide policy. I think this discussion is very interesting, mainly because we
Re: Portlet API
"Schwarz, Marcus" wrote: - Locator provides methods to determine the current location of a user's device, e.g. longitude/latitude, country, state, city, ZIP code. I don't think hooks should exist in a generic portlet API to cater for this. Too biased towards mobile devices and probably not available on every implementation. On the other hand we surely need a way to provide this information to the portlet. Regarding to your question above the need of the device-specific info depends on the way to portlet is handling it's context to the framework. If it is handling optimized data we have to take care about devices. An easy way to access the info about the current user should be available in most frameworks. As soon as authentication/authorization is available this should also be available in the framework and it's clearly helpful in the portlet. If the portlet is not directly connected to the UM, we have to provide this info via an interface. The same is true for localization. Maybe we should provide something like a capability-map of the framework, with which a portlet can discover the capabilities of the underlying infrastructure. My point was just that such a capability should not appear in a Portlet API directly. Providing a service lookup method in the PortletContext and defining a generic Location service API is fine, as long as implementing such an API is not mandatory netither for Portlets nor for Portals. Some Portals may only wish to cater for PC clients and should not be imposed an increased complexity. I would propose to handle customization by mandating Portlet to provide a descriptor file describing its operational parameters. The portal should provide a default UI implementation for entering parameters based on this descriptor but the Portlet may register a specific Customizer for handling complex needs. +1. In some cases like stocks the portal should store the parameters and also provide an generic UI (which can be more or less controlled by the portlet). But full-blown applications surely brings in complex UI's, which should be registered in the framework. OK -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
|Remove| IBM |X| |X| |Remove| ICGE|X| | | |Remove| --- - | | |Add| --- - -- |Save||Cancel| -- -- 6. The user inputs the desired settings and they are posted in a request like "/PortletID=xyzAction=EditStocks=ARBA-1+IBM-1-2+ICGE-1" 7. The portlet realizes that it is still in edit mode, detects the parameters and stores them using the setAttribute method in the PortletContext. For me, a Portlet is basically a Servlet and JavaBeans/EJB mix. I would propose to handle customization by mandating Portlet to provide a descriptor file describing its operational parameters. The portal should provide a default UI implementation for entering parameters based on this descriptor but the Portlet may register a specific Customizer for handling complex needs. This is a great idea! We expect that most of the portlets we'll implement will require specific customization, but there will be a lot of cases were a customization descriptor will be very useful. An example might be an e-mail portlet: CUSTOMIZATION DESCRIPTOR TITLEE-mail Portlet Settings/TITLE ATTRIBUTE NAMEMail Server Address/NAME TYPEText/TYPE /ATTRIBUTE ATTRIBUTE NAMEUser ID/NAME TYPEText/TYPE /ATTRIBUTE ATTRIBUTE NAMEPassword/NAME TYPEText/TYPE /ATTRIBUTE CUSTOMIZATION DESCRIPTOR/ Comments ? Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Raphael Luta [EMAIL PROTECTED] on 02.11.2000 15:22:43 Please respond to "JetSpeed" [EMAIL PROTECTED] To: JetSpeed [EMAIL PROTECTED] cc: Subject: Re: Portlet API [EMAIL PROTECTED] wrote: (Seems this mail did not get delivered, I hope you don't receive it twice) It's good to see such a positive reaction on my first note about the need for a standard Portlet API and that such a live discussion started. Great, I don't have to write this anymore... :) I guess we should go into more detail now. The figure below shows a portal that provides a Portlet API for portlets to make them independent of any specifics of the portal implementation (e.g. Turbine, ECS, Cocoon, for JetSpeed or something else for other portals). DB EJBs SOAP XML XML XML ||| | | | JSPs/Servlets Cocoon || +---++---+ |Portlet| ... |Portlet| +==+ | Portlet API| +==+ ++ +-+ DB --+ Persistence Service| | Location Service | ++ +-+ | Portal Framework | ++ +-+ LDAP-+ User Data Service | | Device Info Service | | ++ +-+ | +--+ | | Rendering Engine| | | WML | HTML | VoiceXML | CHTML | ...| - User PSML | +--+--+--+---+-+ | | Capability Detection/Rendering Selection | | +--+ +-|Authentication| +--+ /\ || || \/ Request Response I completely agree with this drawing (if I read it correctly that is): in your portlet API view, is the Portlet responsible for rendering its output in the device format or is it handled by the portal framework ? if the Portlet does not do the rendering, what does it output ? We envision a standard Portlet API similar to the Servlet API, providing amongst others the following interfaces: - Portlet is used by the framework to invoke the portlet. Every portlet has to implement this interface. +1 - PortletRequest encapsulates the request to the p
RE: Portlet API
-Original Message- From: Raphael Luta [mailto:[EMAIL PROTECTED]] Sent: Freitag, 3. November 2000 00:53 To: JetSpeed Subject: Re: Portlet API "Schwarz, Marcus" wrote: - Locator provides methods to determine the current location of a user's device, e.g. longitude/latitude, country, state, city, ZIP code. I don't think hooks should exist in a generic portlet API to cater for this. Too biased towards mobile devices and probably not available on every implementation. On the other hand we surely need a way to provide this information to the portlet. Regarding to your question above the need of the device-specific info depends on the way to portlet is handling it's context to the framework. If it is handling optimized data we have to take care about devices. An easy way to access the info about the current user should be available in most frameworks. As soon as authentication/authorization is available this should also be available in the framework and it's clearly helpful in the portlet. If the portlet is not directly connected to the UM, we have to provide this info via an interface. The same is true for localization. Maybe we should provide something like a capability-map of the framework, with which a portlet can discover the capabilities of the underlying infrastructure. My point was just that such a capability should not appear in a Portlet API directly. Providing a service lookup method in the PortletContext and defining a generic Location service API is fine, as long as implementing such an API is not mandatory netither for Portlets nor for Portals. Some Portals may only wish to cater for PC clients and should not be imposed an increased complexity. +1. It should just be an option, not a "must-to-implement", which is dictated by the Portlet API. -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
(Seems this mail did not get delivered, I hope you don't receive it twice) It's good to see such a positive reaction on my first note about the need for a standard Portlet API and that such a live discussion started. I guess we should go into more detail now. The figure below shows a portal that provides a Portlet API for portlets to make them independent of any specifics of the portal implementation (e.g. Turbine, ECS, Cocoon, for JetSpeed or something else for other portals). DB EJBs SOAP XML XML XML ||| | | | JSPs/Servlets Cocoon || +---++---+ |Portlet| ... |Portlet| +==+ | Portlet API| +==+ ++ +-+ DB --+ Persistence Service| | Location Service | ++ +-+ | Portal Framework | ++ +-+ LDAP-+ User Data Service | | Device Info Service | | ++ +-+ | +--+ | | Rendering Engine| | | WML | HTML | VoiceXML | CHTML | ...| - User PSML | +--+--+--+---+-+ | | Capability Detection/Rendering Selection | | +--+ +-|Authentication| +--+ /\ || || \/ Request Response We envision a standard Portlet API similar to the Servlet API, providing amongst others the following interfaces: - Portlet is used by the framework to invoke the portlet. Every portlet has to implement this interface. - PortletRequest encapsulates the request to the portlet. It provides access to parameters/attributes, locator and client information, etc. - PortletResponse encapsulates the response to the portlet. - PortletConfig provides the portlet with config info used by the portlet as well as the framework to render the content. - PortletContext provides the portlet with access to the framework's services. The context allows the portlet to store/retrieve information and access information that the portlet requires to render itself. - UserProfile provides access to the user data. - Client represents the user's client device. It provides methods to get manufacturer, model, user agent and check for capabilities. - Locator provides methods to determine the current location of a user's device, e.g. longitude/latitude, country, state, city, ZIP code. This is a preliminary, not-yet-complete list that we post to get early feedback from the JetSpeed community. Please let us know your comments! We also plan to submit a more detailled proposal soon. Best regards, Thomas Thomas Schaeck IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED] Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
[EMAIL PROTECTED] wrote:
(Seems this mail did not get delivered, I hope you don't receive it twice)
It's good to see such a positive reaction on my first note about the
need for a standard Portlet API and that such a live discussion started.
Great, I don't have to write this anymore... :)
I guess we should go into more detail now. The figure below shows a
portal that provides a Portlet API for portlets to make them independent
of any specifics of the portal implementation (e.g. Turbine, ECS, Cocoon,
for JetSpeed or something else for other portals).
DB EJBs SOAP XML XML XML
||| | | |
JSPs/Servlets Cocoon
||
+---++---+
|Portlet| ... |Portlet|
+==+
| Portlet API|
+==+
++ +-+
DB --+ Persistence Service| | Location Service |
++ +-+
| Portal Framework |
++ +-+
LDAP-+ User Data Service | | Device Info Service |
| ++ +-+
| +--+
| | Rendering Engine|
| | WML | HTML | VoiceXML | CHTML | ...| - User PSML
| +--+--+--+---+-+
| | Capability Detection/Rendering Selection |
| +--+
+-|Authentication|
+--+
/\ ||
|| \/
Request Response
I completely agree with this drawing (if I read it correctly that is):
in your portlet API view, is the Portlet responsible for rendering its
output in the device format or is it handled by the portal framework ?
if the Portlet does not do the rendering, what does it output ?
We envision a standard Portlet API similar to the Servlet API, providing
amongst others the following interfaces:
- Portlet is used by the framework to invoke the portlet. Every portlet
has to implement this interface.
+1
- PortletRequest encapsulates the request to the portlet. It provides
access to parameters/attributes, locator and client information, etc.
+1
- PortletResponse encapsulates the response to the portlet.
+1
- PortletConfig provides the portlet with config info used by the portlet
as well as the framework to render the content.
+1. But we may need to differentiate between static init parameters set the
portal administrator and instance-defined parameters (for example those set in
the current PSML).
If we start with this basic servlet-like API:
interface Portlet {
public void init( PortletConfig cfg );
public void service( PortletRequest rq, PortletResponse rs );
public void destroy();
}
If both admin-defined and user-defined parameters are set in PortletConfig
passed to the init() called, the portal engine needs as many portlet
instances running as there are different parameters value for a given portlet.
This doesn't scale very well for things like a RSSPortlet which takes its
URL as parameter...
If the user-defined parameters are given the PortletRequest we mix 2
different information source within the same object (user-defined
parameters are stored locally and may be trusted, form/query parameters
should not be trusted) and we may prevent the portlet from doing
some optimization of resource.
If the user-defined are accessible from the context and the context is
obtained by ServletConfig.getServletContext(), this is not thread-safe so we
still have one portlet instance/parameters set.
I thought about adding an additionnal setConfig() call in the Portlet API
thus leaving the portal implementation to use any instanciation model they
like (SingleThread or multi-thread) and make sure their implementation is
thread-safe.
Another way to do it is:
public void service( PortletRequest rq, PortletResponse rs, PortletContext ctx )
- PortletContext provides the portlet with access to the framework's
services. The context allows the portlet to store/retrieve information
and access information that the portlet requires to render itself.
+1 with the caveat above: how does a Portlet get its PortletContext ?
- UserProfile provides access to the user data.
- Client represents the user's client device. It provides methods to get
manufacturer, model, user agent and check for capabilities.
- Locator provides methods
Re: Portlet API
[EMAIL PROTECTED] wrote: Same here since we would not be working on top of Turbine, but be using Cocoon2 instead. I'm not sure whether a application neutral Portal API would be a feasible thing, at least a common feature list should be possible. I think an application neutral Portal API is possible but would certainly leave a lot of responsabilities on the portlet developers, especially if we aim for multi-device access. More on this when I have finished my Jetspeed 2 paper... Since thoughts on content aggregation are surfacing quite a lot on the Cocoon dev list, and Santiago has been talking with the Cocoon people during ApacheCon, I believe working across the two apps could be beneficial for both. The Cocoon project will mainly work on *static* content aggregation so that they can offer the same functionalities than Turbine layout model. A Jetspeed implementation on Cocoon 2 will definitely take advantage of their work in static aggregation but I don't see currently a way to integrate in a meaningful way dynamic aggregation in a Cocoon 2 sitemap. -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: Portlet API
Raphael Luta wrote: I think an application neutral Portal API is possible but would certainly leave a lot of responsabilities on the portlet developers, especially if we aim for multi-device access. More on this when I have finished my Jetspeed 2 paper... Can't wait until then ;-) I would think that a device negotiation layer as you could call Cocoon would be extremely helpful working towards different devices - it does already quite a lot of things in terms of user agent detection and the like. The Cocoon project will mainly work on *static* content aggregation so that they can offer the same functionalities than Turbine layout model. A Jetspeed implementation on Cocoon 2 will definitely take advantage of their work in static aggregation but I don't see currently a way to integrate in a meaningful way dynamic aggregation in a Cocoon 2 sitemap. What do you mean with dynamic aggregation? User-based? From what I understood of what Giacomo told me, the Action component is the way to go for all things dynamic in Cocoon(2). /Steven -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
Re: Portlet API
[EMAIL PROTECTED] wrote: Raphael Luta wrote: I think an application neutral Portal API is possible but would certainly leave a lot of responsabilities on the portlet developers, especially if we aim for multi-device access. More on this when I have finished my Jetspeed 2 paper... Can't wait until then ;-) I don't write fast :( I would think that a device negotiation layer as you could call Cocoon would be extremely helpful working towards different devices - it does already quite a lot of things in terms of user agent detection and the like. The browser detection of Cocoon definitely needs an improvement. The main issue being that it detects browsers and not *capabilities*. The ideal capability detection scheme would be something like : - define a series of basic capabilities (ex: HTML3.2 or 4, CSS1, WML1.1, screen resolutions, etc...) - define a mapping between user-agent and capabilities: Mozilla/5=HTML4,CSS1,DOM1 ... This way, designers can create LF based on device capabilities and not a specific browser model. Such a piece of code would be of tremendous use for many Apache projects : Turbine, Cocoon, Jetspeed, Jyve... and so should probably be considered part of the Avalon project. Of course, the difficult task in this is to keep track of all the browsers capabilities... The Cocoon project will mainly work on *static* content aggregation so that they can offer the same functionalities than Turbine layout model. A Jetspeed implementation on Cocoon 2 will definitely take advantage of their work in static aggregation but I don't see currently a way to integrate in a meaningful way dynamic aggregation in a Cocoon 2 sitemap. What do you mean with dynamic aggregation? User-based? From what I understood of what Giacomo told me, the Action component is the way to go for all things dynamic in Cocoon(2). For me: dynamic = user customizable. I'm waiting for Stefano proposal to see what hooks would be available for jetspeed within the sitemap, but I fear SoC (separation of concerns, Stefano's mantra for Cocoon 2) issues. -- Raphaël Luta - [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: Portlet API
Raphael Luta wrote: I would think that a device negotiation layer as you could call Cocoon would be extremely helpful working towards different devices - it does already quite a lot of things in terms of user agent detection and the like. The browser detection of Cocoon definitely needs an improvement. The main issue being that it detects browsers and not *capabilities*. Some people on the Cocoon mailing list have start sending in patches doing some 'browscap' style UA detection. So I suppose this is heading into the right direction. Such a piece of code would be of tremendous use for many Apache projects : Turbine, Cocoon, Jetspeed, Jyve... and so should probably be considered part of the Avalon project. Of course, the difficult task in this is to keep track of all the browsers capabilities... Problem is also that the interpretation of a certain capability sometimes differs from browser to browser. It's nice to know that both XYZ and ABC support JavaScript 3.98, but in our reality we would end up designing towards specific browsers, since they have a different interpretation for a certain JavaScript statement. I know this is kind of pragmatic, but reality kicks in when you design build websites for a living. For me: dynamic = user customizable. I'm waiting for Stefano proposal to see what hooks would be available for jetspeed within the sitemap, but I fear SoC (separation of concerns, Stefano's mantra for Cocoon 2) issues. The Action component gives you the possibility to specify some code (which has a required minimal interface) to invoke during a certain pipeline. Giacomo Pati told me you had full access to the Cocoon internals during the execution of that class but you could do all kinds of back-end stuff also within it (like accessing a DB, checking the session, etc...) That's what I understood from it, but IANAProgrammer :-| SoC is an issue of course, but offering a web publishing platform without some sound integration with a web application platform doesn't make much sense to me also, and I can't assume Stefano hasn't been thinking about that one also. After all, the sitemap could also be considered as being some kind of basic webapp (mapping the URI namespace into serverside content generation filtering processes, where personalization sure needs to be an issue). /Steven -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
RE: Portlet API
Raphael Luta wrote: My point is that you actually don't have to use all the features offered by a browser, just stick to standard stuff. Used any blink tags lately ? :) Blink? Huh? :-) You're right but unfortunately sometimes customers want all the latest stuff possible with IE, and all the latest stuff possible with Mozilla/NS/... at the same time. So we end up matching UA instead of using a browscap, sigh. The Action component gives you the possibility to specify some code (which has a required minimal interface) to invoke during a certain pipeline. Giacomo Pati told me you had full access to the Cocoon internals during the execution of that class but you could do all kinds of back-end stuff also within it (like accessing a DB, checking the session, etc...) That's what I understood from it, but IANAProgrammer :-| Is that implemented yet ? I thought they were still working on designing this, but it sure sounds like a cool idea. There's a org\apache\cocoon\acting\Action.java in the source tree, together with a README and a sample piece of code that logs whether a Session object is created on the Tomcat level. After all, the sitemap could also be considered as being some kind of basic webapp (mapping the URI namespace into serverside content generation filtering processes, where personalization sure needs to be an issue). I'm not sure that the sitemap needs to be personalization aware, most of the time personalization only occurs at the content level. Also the sitemap currently knows how to select a resource based on personalization but there's currently no provision for joining resources. I'm not sure whether all personalization only occurs on the content level, and even less sure how you would do this, then. Personalization typically occurs in code (shudder), so your webpub environment needs a webapp backing in order to facilitate in-page-personalization. But anyway, we should be thinking about this Portal API, not? :-) /Steven (off for a couple of days, so don't expect me to continue on this interesting thread until Monday) -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
