[Solr Wiki] Update of "TaskList" by HossMan

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The following page has been changed by HossMan:
http://wiki.apache.org/solr/TaskList

------------------------------------------------------------------------------
    * FederatedSearch
    * A "user query" parameter for standard request handler, much like what dismax handler has, for unstructured queries entered from a search box
    * refactor and separate update XML parsing from update handling... possibly implement support for JSON updates.
+   * refactor all of the JSP pages into servlets so a JDK/JSP compiler isn't needed (the current JSPs are very sparse on presentation, and use no custom tags, so there is almost no advantage to them being JSPs)
  

Re: [Solr Wiki] Update of "TaskList" by HossMan

[Chris Hostetter <ho...@fucit.org>]

: Yes, it depends on the customization.  What I had in mind was not just
: formating changes, but adding additional content to the pages or adding a
: new page.  With servlets it can still be done.  But then it will require
: building Solr from source.  A little more involved.

are you talking about clients adding their own modifcations to the pages
(or new pages) when they install Solr? ... that would require unpacking
the WAR and at that point we might as well ask them to recompile --
letting people specify a flat HTML file to include on the admin page is
one thing, but if people want custom code in the admin pages expectingthem
to recompile doesn't seem like much of a stretch.

:
: Bill
:
: On 8/29/06, Chris Hostetter <ho...@fucit.org> wrote:
: >
: >
: > : Leaving them as JSPs would make it easier to customize the admin pages.
: >
: > It depends on the customization.  CSS is still easy to do with servlet
: > output.  if you look at the JSPs right now, the most complicated HTML I
: > found is actually being created inside of scriptlet blocks that would be
: > *easier* to macke sense of in a Servlet.
: >
: > :
: > : Bill
: > :
: > : On 8/28/06, Chris Hostetter <ho...@fucit.org> wrote:
: > : >
: > : > : > + * refactor all of the JSP pages into servlets so a JDK/JSP
: > compiler
: > : >
: > : > : It seems like a simpler option would be to just move to Tomcat 5.5or
: > : > : Jetty 6, both of which handle JSPs file with a JRE.
: > : >
: > : > that solves confusion people have when running the example out of the
: > box,
: > : > but doesn't help situations where people try using Solr in their own
: > : > Servlet Container.   I just wanted to through the idea out there since
: > we
: > : > don't really gain that much with the current JSPs, but it has caused
: > us
: > : > some annoyance.
: > : >
: > : > (an added bonus is the entire webapp would be compiled at build time,
: > so
: > : > there would be less risk of commiting changes to src/java that seemed
: > : > simple but actually cause compile failures in the webapp)
: > : >
: > : >
: > : >
: > : > -Hoss
: > : >
: > : >
: > :
: >
: >
: >
: > -Hoss
: >
: >
:



-Hoss

Re: [Solr Wiki] Update of "TaskList" by HossMan

[Bill Au <bi...@gmail.com>]

Yes, it depends on the customization.  What I had in mind was not just
formating changes, but adding additional content to the pages or adding a
new page.  With servlets it can still be done.  But then it will require
building Solr from source.  A little more involved.

Bill

On 8/29/06, Chris Hostetter <ho...@fucit.org> wrote:
>
>
> : Leaving them as JSPs would make it easier to customize the admin pages.
>
> It depends on the customization.  CSS is still easy to do with servlet
> output.  if you look at the JSPs right now, the most complicated HTML I
> found is actually being created inside of scriptlet blocks that would be
> *easier* to macke sense of in a Servlet.
>
> :
> : Bill
> :
> : On 8/28/06, Chris Hostetter <ho...@fucit.org> wrote:
> : >
> : > : > + * refactor all of the JSP pages into servlets so a JDK/JSP
> compiler
> : >
> : > : It seems like a simpler option would be to just move to Tomcat 5.5or
> : > : Jetty 6, both of which handle JSPs file with a JRE.
> : >
> : > that solves confusion people have when running the example out of the
> box,
> : > but doesn't help situations where people try using Solr in their own
> : > Servlet Container.   I just wanted to through the idea out there since
> we
> : > don't really gain that much with the current JSPs, but it has caused
> us
> : > some annoyance.
> : >
> : > (an added bonus is the entire webapp would be compiled at build time,
> so
> : > there would be less risk of commiting changes to src/java that seemed
> : > simple but actually cause compile failures in the webapp)
> : >
> : >
> : >
> : > -Hoss
> : >
> : >
> :
>
>
>
> -Hoss
>
>

Re: [Solr Wiki] Update of "TaskList" by HossMan

[Chris Hostetter <ho...@fucit.org>]

: Leaving them as JSPs would make it easier to customize the admin pages.

It depends on the customization.  CSS is still easy to do with servlet
output.  if you look at the JSPs right now, the most complicated HTML I
found is actually being created inside of scriptlet blocks that would be
*easier* to macke sense of in a Servlet.

:
: Bill
:
: On 8/28/06, Chris Hostetter <ho...@fucit.org> wrote:
: >
: > : > + * refactor all of the JSP pages into servlets so a JDK/JSP compiler
: >
: > : It seems like a simpler option would be to just move to Tomcat 5.5 or
: > : Jetty 6, both of which handle JSPs file with a JRE.
: >
: > that solves confusion people have when running the example out of the box,
: > but doesn't help situations where people try using Solr in their own
: > Servlet Container.   I just wanted to through the idea out there since we
: > don't really gain that much with the current JSPs, but it has caused us
: > some annoyance.
: >
: > (an added bonus is the entire webapp would be compiled at build time, so
: > there would be less risk of commiting changes to src/java that seemed
: > simple but actually cause compile failures in the webapp)
: >
: >
: >
: > -Hoss
: >
: >
:



-Hoss

Re: [Solr Wiki] Update of "TaskList" by HossMan

[Bill Au <bi...@gmail.com>]

Leaving them as JSPs would make it easier to customize the admin pages.

Bill

On 8/28/06, Chris Hostetter <ho...@fucit.org> wrote:
>
> : > + * refactor all of the JSP pages into servlets so a JDK/JSP compiler
>
> : It seems like a simpler option would be to just move to Tomcat 5.5 or
> : Jetty 6, both of which handle JSPs file with a JRE.
>
> that solves confusion people have when running the example out of the box,
> but doesn't help situations where people try using Solr in their own
> Servlet Container.   I just wanted to through the idea out there since we
> don't really gain that much with the current JSPs, but it has caused us
> some annoyance.
>
> (an added bonus is the entire webapp would be compiled at build time, so
> there would be less risk of commiting changes to src/java that seemed
> simple but actually cause compile failures in the webapp)
>
>
>
> -Hoss
>
>

Re: [Solr Wiki] Update of "TaskList" by HossMan

[Chris Hostetter <ho...@fucit.org>]

: > + * refactor all of the JSP pages into servlets so a JDK/JSP compiler

: It seems like a simpler option would be to just move to Tomcat 5.5 or
: Jetty 6, both of which handle JSPs file with a JRE.

that solves confusion people have when running the example out of the box,
but doesn't help situations where people try using Solr in their own
Servlet Container.   I just wanted to through the idea out there since we
don't really gain that much with the current JSPs, but it has caused us
some annoyance.

(an added bonus is the entire webapp would be compiled at build time, so
there would be less risk of commiting changes to src/java that seemed
simple but actually cause compile failures in the webapp)



-Hoss

Re: [Solr Wiki] Update of "TaskList" by HossMan

[Yonik Seeley <yo...@apache.org>]

On 8/27/06, Apache Wiki <wi...@apache.org> wrote:
> +   * refactor all of the JSP pages into servlets so a JDK/JSP compiler isn't needed (the current JSPs are very sparse on presentation, and use no custom tags, so there is almost no advantage to them being JSPs)

It seems like a simpler option would be to just move to Tomcat 5.5 or
Jetty 6, both of which handle JSPs file with a JRE.

-Yonik