DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17756>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17756 MVCPortlet Proposal ------- Additional Comments From [EMAIL PROTECTED] 2003-03-11 16:33 ------- I've been somewhat following your discussions and here's my .02: 1. Backwards compatibility is top priority. We wouldn't want to introduce any migration issues in a minor release (as we did going from b2 to b3). This change should be totally transparent - and the way this stuff is designed, it can be (that's a complement, BTW). 2. We should keep JspPortlet and VelocityPortlet classes because unfortunatly the class entry gets "merged" with every instance of these portlets when the registry is rewritten on shutdown. So if you were to reuse these registries with Jsp/VelocityPortlet gone, it would cause problems. They can be deprecated in the future. 3. We add GenericMVCPortlet entry to registry so other can take advantage of it (we need to document it as well): <portlet-entry name="GenericMVCPortlet" hidden="false" type="abstract" application="false/> <classname>org.apache.jetspeed.portal.portlets.GenericMVCPortlet</classname> </portlet-entry> 4. We could provide convenience definitions for Jsp/VelocityPortlet: <portlet-entry name="VelocityPortlet" hidden="false" type="ref" parent="GenericMVCPortlet" application="false"> <parameter name="viewtype" value="Velocity" hidden="true"/> </portlet-entry> <portlet-entry name="JspPortlet" hidden="false" type="ref" parent="GenericMVCPortlet" application="false"> <parameter name="viewtype" value="Jsp" hidden="true"/> </portlet-entry> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
