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
