Rapha�l Luta wrote:
> Well getInitParameters() will return the parameters set for the portlet in the PSML.
> How do you know how to set them in the first place ? In the registry markup.
> How do you add en entry in the registry ? currently manually but we can envision a
> register(Portlet) call in the PortletRegistry and this would require a way to
> ask the portlet which parameters it needs to operate so we either need a
> getParameterInfo or a EJB-like deployment descriptor file...
Hm. What would call register()?
> > > - 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.
> >
>
> *waiting mode*
I think specifically all it was the CocoonPortlet. Specifically:
JetspeedServletRequest request = new JetspeedServletRequest(
fileName, content, rundata.getRequest() );
JetspeedServletResponse response = new JetspeedServletResponse(
new PrintWriter( cos ), rundata.getResponse() );
cocoon.handle( request, response );
If we can get rid of this then maybe it would be OK. We could possibly
base it on the Turbine ParameterParser. This needs to be fixed for
Tomcat anyway so... They changes I made to DynamicURI to use a
ParameterParser are into Turbine now so we could potentially have
support for this just fine.
> > -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.
> >
>
> Yeah I know, it's just that I don't like the forced call to setRunData(), but
> it's more on religious grounds than anything else... :)
Welll hopefully that will go away :)
> > > - 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.
> >
>
> OK, I'll take care of that.
>
> > > 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.
> >
>
> :)
So where is it? Show me the money :)
> > > - 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.
> >
>
> because some controllers (or should I say many) have no notions of "columns"
> whereas position is used to give a display order for siblings entries in the
> markup so is meaningful for any controller (this is important because it allows
> to use non-ordering object stores (like Hashtable) in implementations but still
> return an appropriate display order.
I think that basically we only ever need 2 or 3 controllers. One for IE
and Netscape and then medium content providers, Palm V or Mozilla thin
clients, then WAP clients. This is where your mime types on portlets
comes in.
> I wish to type in the markup only the elements that can be acted upon by *all*
> controllers.
Yeah. But this is a pipe dream IMO. Some WAP clients will barely be
able to view a full portlet less a PortletController with multiple
columns.
<snip>
> >
> > > 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.
> >
>
> OK, I'll try to polish up the code and land everything over the week-end.
Still waiting. Just work from CVS so that we don't have the major
conflicts.
> > > 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.
> >
>
> If you remove the "provide metadata" role of a PortletControl, it basically provides
> a decoration to the portlet (ie, draw title bar, draw a frame around the portlet,
> and so on...). We can then imagine than by writing of couple of basic "decorations":
> TitleBarControl, BorderControl, etc... and attaching them to a portlet we can
> achieve a much more flexible decoration system...
But you can just put this into the PortletControl too.
<snip>
> > > 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?
>
> I don't know, putting the content in CDATA would:
> - prevent the controller from accessing any part of the content information
> (title, headers, etc..)
> - require a type-specific serializer to convert the CDATA to markup if the
> output is not XML (eg HTML...)
OK. I am not sure here. But in XML the getContent would return a
Document fragment, not the DOM DocumentFragment, but an actual subset of
the original data. If there were some required elements in getContent
we can't do validation.
I guess I am 50/50.
> I'd rather have the portlet itself determine what it should return based on
> a type/capability request than enforcing XML compliance but removing any
> useful data-processing capability.
OK....
> > 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.
> >
>
> I don't understand this point, how can you enforce validity of every
> possible portlet output ? I'd rather have the following process:
>
> - System build an ordered list a desired output format such as:
> - text/html, no table, css1
> - text/html
> - text/plain
>
> - Ask the portlet for supported types
> - Determine best type supported by portlet
> if non supported, don't ask for content
> if there's a match, ask content for the best match
>
> If you query for text/xml, you just want any xml compliant markup. If
> you want a specific format query directly to that format (text/rss, text/xhtml,
> text/rdf, etc...)
Yup. I agree. Just need an impl :)
> > > 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!
> >
>
> Yeah, I have a nice Nokia 9110 that doesn't handle tables...
Ug. I have got to get a WAP device. None of the emulators (at least
the ones I have found) work under Linux. :(
> > Just note that any code you commit has to be clean by May 15 or so for
> > Jetspeed 1.2. :)
> >
>
> I'll be preparing my wedding, so everything will either be committed before that
> date or long after...
Cool. Congrats. Have fun!
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
The house of the unbelievers shall be razed and they shall be
scorched to the earth. Their code will be open until the end of days.
--
--------------------------------------------------------------
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]
