I've entered a ticket CONNECTORS-40 for this work. What I propose is that this gets done before first official LCF release, because of the potential backwards-compatibility issues involved. It is, however, quite a heavy lift - I can't imagine getting it done in less than a couple of weeks straight-out effort. To minimize the elapsed development time of this step, I propose that we not attempt to convert any JSP's from the framework itself in this round, but merely those for each connector. I'll start by adding appropriate placeholder methods to the interfaces and all connectors, and then try to port the UI components one at a time, for one specific connector. Then, we can have a back-and-forth about how to refine that one implementation before I attempt the rest.
Sound reasonable? Karl -----Original Message----- From: ext Erik Hatcher [mailto:erik.hatc...@gmail.com] Sent: Wednesday, June 02, 2010 8:51 AM To: connectors-dev@incubator.apache.org Subject: Re: Some more thoughts on a classloader plug-in style architecture Yeah, definitely embedded Java (ala JSP's <%....%> stuff) isn't how Velocity works. It can call Java code just fine via "tools" (Java objects) that are injected into the Velocity context. Any sophisticated business logic can be distilled from the existing plugin JSPs and migrated to Java classes and added to the Velocity context. If specific connectors need more logic, they could ship with their own tools, and we build in a mechanism to pull in custom tools into the context. Erik On Jun 2, 2010, at 8:28 AM, <karl.wri...@nokia.com> <karl.wri...@nokia.com > wrote: > 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 >>>> >>>> >> >
