[EMAIL PROTECTED] wrote:
>
> PSML - Portal Site Markup Language
>
> Following last week discussion on the list, here's a proposition
> for an evolution of the Portlet Markup Language to allow
> a more extensive description of a site.
>
> Note:
> This is a draft and may heavily be changed as soon as I'll
> really try to implement it... :)
>
> The following schema is NOT directly backward compatible
> because I renamed 'entry' to 'portlet', but was still designed
> with backward compatibility in mind.
>
> The main additions to the previous format are:
> - addition of layout and skin elements:
> . layout elements are structural hints to build the resulting page
> . skin are simple display properties which may easily delegated
> to the client (for example as CSS stylesheets...)
> - extension of the parameter element to allow typecasting
Cool. I think this was on the TODO. I would like to see this
implemented like:
PortletConfig.getPortletParameters().getString("handle")
Similar to org.apache.turbine.util.ParameterParser
Hopefully we can get rid of RunData soon. This would involve providing
servlet parameters to the Portlet as well. This would be information
that would be included within a form. So I was thinking about:
public class PortletConfig {
public org.apache.turbine.util.ParameterParser getEngineParameters();
}
The only problem is that the current ParameterParser impl only works
with a HttpServletRequest. Hopefully we can maybe make this an
interface or overload the constructor.
> for automatic customization screen building
> - introduction of panes for portlets grouping
+1. As long as this is actually implemented. I don't want to just
ignore panes.
> - possibility of profile definition to automatically create
> user portlets set from a base template
> - decorrelation of portlets instanciation, portlet definition and
> channel definition:
> - a pane should use portletRef to indicate its wish to use
> a given portlet (with maybe some additional infos).
> The portletRef use a custom portlet URL to reference the portlet
> which may be defined in the local file or in a registry
>
> portlet URL format:
>
> portlet:[//<registry host>:<port>/]<portlet name>[:<portlet dependent
> extension>]
>
> for example:
> portlet:MailPortlet
> portlet://myregistryserver:1199/RSSPortlet
> portlet:RSSPortlet://relativity.yi.org/jetspeed.rss
Why would we need a registry host? Does this provide us anything?
Also I assume your registry host imple would have a mapping from
RSSPortlet -> org.apache.jetspeed.portal.portlets.RSSPortlet?
The problem with using URIs as I see it is that the URL requirement
doesn't work. IE you need to provide a URL for this.
> - a portlet defintion should provide the implementation classname
> and default properties for the portlet operation
> It may also notify the Factory that it's a stateless portlet
> using the pool element
>
> - a portlet should reference a channel through a registry lookup
> URL
>
<snip>
OK. I am a big +1 on using channels. The problem is that the OCS file
format does not provide this information. For future version of
Jetspeed I was considering allowing users to vote for what channel an
RSS item should belong to. Hopefully in the future we can integrate
DMOZ information. Then this could be used to correlate and guess
channel information. So for example:
http://www.pcweek.com/channel.rss
What is this?
Well if we have the DMOZ RDF info we could find out what channel PCWeek
was in and then assume that the content was within the same DMOZ
channel.
This should work. I can't think of any problems but implementation
might be interesting. Especially considering the DMOZ problems:
- it is about 500M of data.
- We need a search engine for this much content.
- Need to provide a fast XSLT interface for this data.
I am going to review the documents you sent and then post another
e-mail.
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
--
--------------------------------------------------------------
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]
