I've just spelunked through what I could find online, and it seems at least plausible to use Velocity for various LCF HTML templating needs. The major concern that I have is that the mix of inline java to HTML in the LCF stuff is weighted heavily towards inline java - which doesn't seem to be where Velocity's sweet spot is. ;-) The general underlying idea of invoking a connector-API-based method instead of providing a JSP seems sound, however, no matter what the templating engine is that does the final assembly.
Karl -----Original Message----- From: ext Erik Hatcher [mailto:erik.hatc...@gmail.com] Sent: Wednesday, June 02, 2010 8:19 AM To: connectors-dev@incubator.apache.org Subject: Re: Some more thoughts on a classloader plug-in style architecture Velocity is just a simple templating engine, so it could be used in the intermediate fashion to produce only snippets that mesh into the rest of the built-in UI, no problem. Erik On Jun 2, 2010, at 8:04 AM, <karl.wri...@nokia.com> <karl.wri...@nokia.com > wrote: > Does the entire UI have to be converted to Velocity for this > approach to work? There's an intermediate path that would involve > converting only the connector portions, which might be viable. > > Karl > > > -----Original Message----- > From: ext Erik Hatcher [mailto:erik.hatc...@gmail.com] > Sent: Wednesday, June 02, 2010 7:27 AM > To: connectors-dev@incubator.apache.org > Subject: Re: Some more thoughts on a classloader plug-in style > architecture > > Actually the problem is quite tractable. We switch the UI over to > Velocity templates (like Solr's VelocityResponseWriter, for example) > and embed the UI bits into plugin JAR files that can live externally. > > JSPs aren't really workable in this fashion. > > Velocity templates can be loaded from the file system, the classpath, > from a String, or from thin air. For example, VelocityResponseWriter > allows templates to load from the actual request (clients can send in > a template as an HTTP parameter), if not found it looks on the > filesystem, and if not found it looks in the classpath. > > Erik > > On Jun 2, 2010, at 6:55 AM, Jack Krupansky wrote: > >> Good point. LCF is a bit more complex than Solr in that sense. >> >> Maybe a separate class is needed that has methods to retrieve the >> crawl and UI components of a connector. >> >> Or a small XML file with whatever info about the connector is >> needed. Or maybe it is simple enough for a properties file. >> >> Or maybe just a naming convention so that the name of the UI >> component can be deduced given the logical name of a connector. >> >> -- Jack Krupansky >> >> -------------------------------------------------- >> From: <karl.wri...@nokia.com> >> Sent: Wednesday, June 02, 2010 6:45 AM >> To: <connectors-dev@incubator.apache.org> >> Subject: Some more thoughts on a classloader plug-in style >> architecture >> >>> It occurred to me that a classloader plug-in reader for LCF would >>> not achieve the goal of allowing a fully prebuilt LCF with >>> connector add-ons. The reason, which should have been obvious from >>> the beginning, is because each connector consists not only of the >>> Java implementation, but also a UI component. The UI component >>> will need a mechanism similar to the classloader one in order for >>> everything to work. >>> >>> It is possible, I suppose, for precompiled JSP's to be class-loaded >>> instead of uncompiled JSP's in the lcf-crawler-ui.war file. >>> However this is going to require some care and finesse (and example >>> build.xml files) to get it to work properly. >>> >>> Karl >>> >>> >
