OK, sounds good. I don't yet have a good enough feel on what the ideal portlet architecture is, so I'm all for expedience in this case.
Aaron On Wed, 31 Aug 2005, Joe Bohn wrote: > Actually, on second thought: > - since this isn't the final solution anyway > - and it's much easier to just bundle this method in the BasePortlet > class (and have all portlets extend from that class) :-) > ..... I'll just go ahead and include it in the BasePortlet class (unless > you've changed your mind that is). > > Joe Bohn wrote: > > > Yes, I wasn't crazy about the implementation that I saw there > > either. I think we need a more dynamic mechanism to to include the > > correct elements for a particular configuration (be they UI components > > or other internal elements). I also think that this is needed beyond > > just the Jetty/Tomcat choice to things like DB selections, MQ > > implementations, user repositories, authentication engines, etc... > > basically anything that is configurable and which items like the UI > > may need to provide custom logic or views. > > > > However, in the interest of not making radical changes and getting the > > UI working for tomcat I think this is the best short term approach. > > However, wouldn't a utility class be a more general solution? If we > > continue to include this in the Portlet classes it is very limited in > > scope and can't even be used by other utility classes that are invoked > > from within the portlet. We already have a situation with the > > logging portlet where the knowledge of Jetty vs. Tomcat is currently > > necessary in a utility class rather than the portlet (however for that > > particular case it may make more sense to push the check "up" to the > > portlet). Do you believe that this check will always only be needed > > in the portlet code itself? > > > > Aaron Mulder wrote: > > > >> I'm not terribly happy with the way the Tomcat/Jetty check was > >>done (looking for "Tomcat" or "Jetty" in the names of any interfaces the > >>thing implements, IIRC), so I'm a little hesitant to spread the use, but I > >>guess better that we do it in one place rather than have separate versions > >>of that check in separate modules. > >> > >> You can just promote the check from BaseWebPortlet to BasePortlet, > >>I'd say, and make sure the method name indicates that it's for web usage > >>(not just "getComponentType" or something -- I don't have the code in > >>front of me at the moment). > >> > >>Aaron > >> > >>On Wed, 31 Aug 2005, Joe Bohn wrote: > >> > >> > >> > >>>There was recently some code specifically implemented under the > >>>webmanager to determine the server on which a portlet is running (jetty > >>>or tomcat). This was accomplished by extending the BasePortlet to > >>>create a BaseWebPortlet and then having all of the other "web" portlets > >>>extend from this class. The class only contains a common method (and > >>>some constants) to determine the server type when passed the container > >>>class. > >>> > >>>I need this capability in other console modules (and it may be necessary > >>>elsewhere). What are the thoughts if I remove the BaseWebPortlet class > >>>and instead create a utility class under the console for this > >>>function? If this is useful beyond just the console we could move it > >>>to a more general place. Thoughts? > >>> > >>>-- > >>>Joe Bohn > >>>[EMAIL PROTECTED] > >>> > >>>"He is no fool who gives what he cannot keep, to gain what he cannot > >>>lose." -- Jim Elliot > >>> > >>> > >>> > >>> > >> > >> > >> > >> > > > >-- > >Joe Bohn > >[EMAIL PROTECTED] > > > >"He is no fool who gives what he cannot keep, to gain what he cannot lose." > > -- Jim Elliot > > > > > > -- > Joe Bohn > [EMAIL PROTECTED] > > "He is no fool who gives what he cannot keep, to gain what he cannot lose." > -- Jim Elliot > >
