> > I see your point. But this overriding behavior can be potentially bad.
> > IMO we should have a static set of values that are allowed to be
> > overrided. This way if someone defines something like "put" we don't
> > have namespace issues.
> >
> > I don't have a problem with giving you this behavior but we should limit
> > it to a certain set of parameters.
> >
> > We should also build a better "blend" mechanism. I don't like how we
> > are doing the blend in multiple places. This can lead to problems.
> >
>
> Yeah, I thought a little more about the issue and I came to a couple of
> conclusions (while coding over the week-end) :
>
> - the main need for overriding values are in the layout setup and not in the
> parameters for the portlet so if we separate InitParameters and Layout calls,
> we can specify 2 different behaviors. This is currently done in my
> version of PortletConfig, with no cascading InitParameters but cascading layout.
Maybe we should just cascade the <layout> data with a getLayout() method
that returns a Layout object that is the blend? This seems nice.
> - I think there's a need in the Portlet interface for an applet-like
> getParameterInfo() which factories, controllers and editors can use to list
> the expected parameters for a given portlet. This function should give us
> the tools to check parameters validity.
There currently is Portlet.getConfig().getInitParameters() and
getMetaInfo(). Is this not enough? Parameter validity should be up to
the Portlet.
> - I'm still not easy on the storing of the RunData (or any request dependent
> info) in the PortletConfig, I feel these should be passed as parameters in
> for getContent() (nothing major though, I don't propose a change unless
> we find a situation where it would be really useful))
+1. I totally agree. I spent a saturday morning researching this. It
just isn't possible right *now*. Hopefully soon. I am going to write
up an e-mail about this. I will get back to this list with a better
explaination.
-1 on putting it in getContent(). Anything that calls getContent()
should obtain the Portlet through PortletFactory which calls
setRunData() again before returning the Portlet so we are cool here.
> - I think we should avoid propagating portletmarkup elements outside of the
> Factory scope to better separate the interface of the implementation
> (I see the portlet generation as a kind of peer-based system, where the
> PSML markup and objects are the peers of the Portlet, PortletSet and
> PortletConfig elements)
> The only element used outside of this scope is Metainfo in PortletConfig,
> IMO this should be fixed.
I am not happy with this either. The metainfo really isn't needed
anymore. I reworked the PortletFactory to force titles/descriptions on
the Portlet after it was instantiated so that the user can override the
title and description if we want. There shouldn't be any need for this
anymore. I will put it in the TODO.
> I've done some major PSML rework, among the proposed changes:
> - create 2 different markups, one for the registry and one for the site markup
> proper, this allows better description control of the different elements
Cool. I was going to bring this up.
> - rework of the layout elements to simplify handling by castor, the new layout
> section is something like this:
>
> <layout size="NORMAL" position="1">
> <property name="column" value="1"/>
> <property name="stylesheet" value="file://test.xsl"/>
> </layout>
So why not:
<layout size="NORMAL" position="1">
<column value="1"/>
<property value="file://test.xsl"/>
<property name="test" value="hello world"/>
</layout>
This way column/row information is typed.
> - I implemented the PortletSet as Portlet. Each PortletSet have one attached
> PortletController and one PortletConfig. I deprecated all direct parameter
> access methods on the PortletSet since they are now in the PortletConfig.
> When getContent() is called on the PortletSet, it delegates the layout and
> rendering to the attached controller.
>
> - Following the previous change, in the PSML markup I removed the entry
> element (everything has to be declared in the registry), removed the
> pane element (not necessary anymore) and allowed portlets imbrication.
> The pane feature is compeltely handled by the controller choice.
OK..
> Example of new markup:
>
> <portlets user="turbine">
> <controller>org.apache.jetspeed.portal.PanedPortletController</controller>
> <parameter name="defaultpane" value="Home"/>
> <portlets name="Home">
> <controller>org.apache.jetspeed.portal.FlowPortletController
> </controller>
> <layout position="0"/>
> <entryRef ref="RSS">
> <layout position="0">
> <property name="column=" value="1"/>
> </layout>
> </entryRef>
> <entryRef/>
> </portlets>
> <portlets name="Channels">
> <layout position="1"/>
> <portlets>
> <entryRef/>
> </protlets>
> <entryRef/>
> <portlets/>
> </portlets>
Not sure if I like the duplicate "portlets" element. How about
"section" or something?
> - I have a couple of additionnal controllers and a revised XMLPortletController
> along with a ECS patch for XHTML output...
Cool!
> I don't know yet how I'm going to commit these changes back especially since I need
> to merge all Kevin changes... If someone is -1 on one of the changes let me know
> quickly.
No -1 here! Go ahead +1 !!! Still need to look at the PortletSet thing
being a Portlet.... haven't had time.
> Couple of things I'd want to implement but I'd like feedback from the list before:
>
> - place of PortletControl in the new PortletSet/Portlet/PortletController system :
> I've currently kept the PortletControl as is but I think it would be more
> satistying if the PortletControl was as property of Portlet
> I was thinking of allowing multiple controls per portlet which could complement
> each other. This is very handy and correct for the decoration part of the
> PortletControl interface but not really appropriate for the metadata information
> part.
Huh? How could you have multiple PortletControls? What would each do?
Certainly people should be able to pick their PortletControls so that
they can change the look of the screen (or at least configure a master
version) but I am not sure about multiple ones.
> - to allow multi-access to the portal, I think we need to add methods
> to the Portlet interface to specify the content-type that can be returned
> by the portlet. Something like:
>
> String[] getSupportedType() {
> return { "text/html","text/xhtml","text/wml","text/xml" }
> }
I agree. +1024.
> getContent(String type) {}
I am wondering if we should have a basic MimeType object so that we can
add additional functionality in the future. Also we could have:
getContent( MimeType type );
getContent( String someFutureMethod );
so that in the future if we want a getContent(String) we can still do
it.
> This, based on clien capability would allow the protlets to be called only if
> can output the correct desired type (may also be used by XMLController to ask
> xml-compliant output from a portlet, etc...)
In the XML world getContent should just be a CDATA though.... thoughts?
If we start to use XML then I think we should use an XMLSchema to return
from getContent() so that validation and data integrity can be
maintained.
> This could also be ehance to a full client capability map to allow the portlet
> output to change if the browser doesn't support table, etc...
yup. Like on wireless devices, Palm or thin devices!
Just note that any code you commit has to be clean by May 15 or so for
Jetspeed 1.2. :)
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]
