"Kevin A. Burton" wrote:
>
> Rapha�l Luta wrote:
> >
> > Markup differences
> > ==================
> >
> > An important difference between the old PSML and the new is that all entry in the
> > markup must reference an entry in the registry, you can't have standalone entry
> > directly.
> > Also note that you *CAN'T* specify an URL in the portletmarkup anymore, every URL
> > needs to be registered in the registry.
>
> -1 I think that any "ref" should be able to override any entry in the
> registry. This should break the FileServer and RSSPortlet. :(
>
see below
> > I know this is tedious but it is the only way we can easily:
> > - bulk download all URLs
> > - implement a security feature
>
> What security feature? I am not sure users should be able to define
> Portlets.
>
Agreed, but some channels may be restricted to some users, so these channels
should be referenced in the registry and properly tagged as restricted.
> > - browse the available portlets
>
> The FeedDaemon should just be able to add a entry like:
>
> <entry type="ref" name="http://www.cnn.com/cnn.rss">
> <url>http://www.cnn.com/cnn.rss</url>
> <entry>
>
> This should solve any namespace/browsing concerns :)
>
Yes, but he should do it in the registry so that this channel is available
for any user. Remember that there's only 1 registry file used currently,
but 1 / user psml file.
I think the psml should concentrate on describing the screen organisation
for the user and the registry should be used to describe what is available
in the system.
> Also. We should have FileServer and RSSPortlet setup like <entry
> type="abstract"> so that they don't get instantiated directly. I can
> handle this too.
>
Yes, I agree that we need this kind of scheme.
Now that the branch is committed, I planned to tweak the registry markup in
the following fashion:
- allow entry templates (or types or prototypes I'm not yet decided on the name)
with the following markup
<template name="RSS">
<classname>org.apache.jetspeed.portal.portlets.RSSPortlet</classname>
<url/>
<parameter name="itemDisplayed" value="10"/>
</template>
This would be similar to your <entry type="abstract"> except that:
- you don't need to check for the abstract type at instanciation since they won't
come up with a getEntry() call.
- they must declare all available elements and parameters that must be used for
entry instanciation, thus providing a checking method for instantiation.
An entry could then be declared:
<entry type="RSS" name="http://www.cnn.com/cnn.rss">
<url>http://www.cnn.com/cnn.rss</url>
<entry>
If a type is not provided the factory work the same as currently, if a type is
provided the factory would enumerate all elements in the template, fill those
without value, override those redifined (except classname) and instanciate.
I think this markup sould provide all the tools we need for the PortletBrowser,
RSSPortlet, FilePortlet, etc... and is more expressive than using type="...".
Let me know if you want to work on that or if I should go on with this
implementation, so that we don't work on the same areas.
> > without exploring all the user-defined psml files to search for new unknown
> > entries...
>
> Well. I am sure these would all just be references to something in the
> PortletRegistry:
>
Sure, but we would still have 2 different entry classes to deal with:
org.apache.jetspeed.xml.api.portletmarkup.Entry
and
org.apache.jetspeed.xml.api.registrymarkup.Entry
> <entry ref="http://www.cnn.com/cnn.rss"/>
>
> Does that work? We should probably merge my PortletBrowser markup and
> blend the two to basically be some type of reference only markup.
>
Yes, it works. I haven't have time yet to check the PortletBrowser markup
but I think the registrymarkup (or a subset of this markup) should be suitable
for the PortletBrowser markup.
I also think we should rename the portletmarkup package to psml or sitemarkup,
because it describes a site prganisation and presentation and not the
portlet internals.
--
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]
