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




Reply via email to