Glenn Golden wrote: >Santiago - > >Thanks for the comments and the vote! I'll change my "content" to "clear", >as you suggested. There is a "clear" portlet control, but not screens or >layouts (yet). > >And I'll use $jlink.forPortlet() instead of setPortlet(). > >Can we change forPortlet() in two ways: > >1) if the portlet parameter is null (as it would be if used on a portlet >that is in the portal page, not maximized or in an iframe), can the method >just ignore the call? > will it receive "null", i.e. null as a String, or ""? I'm not sure of what is the result of "$!data.Portlet" in velocity. I guess it should be "", but one never knows :-)
I think so. > > >2) whatever naming convention we have to id a portlet within a portal page >(uniquely), can forPortlet() be guaranteed to produce such a name? Some >string that can be in the portlet parameter (portlet=) and that the >JetspeedTool's getPortlet() and (my new, newly named) getPortletClear() >would use to find it? And if there's any other name producer / consumer, >that they all be standardized? This might mean the "container=" parameter >which recently was added would go away in favor of a complex portlet luid >(local unique id, local to the portal page). > Yes. We have been needing this for at least two years. Although it will be our collective work to guarantee it, i. e., to audit the code to ensure it is used. I don't know if your proposal brings problems with other developer's effort, so let's wait a bit more until other people comments on it. > >Thanks! > >- Glenn > >-------------------------------------------- >Glenn R. Golden, Systems Research Programmer >University of Michigan School of Information >[EMAIL PROTECTED] 734-615-1419 >http://www-personal.si.umich.edu/~ggolden/ >-------------------------------------------- > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
