You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2006/12/07 00:14:21 UTC
[jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin
view
[ http://issues.apache.org/jira/browse/SOLR-75?page=comments#action_12456253 ]
Hoss Man commented on SOLR-75:
------------------------------
I really haven't had the time to play with this that i hoped i would (i was really hoping to try and tweak it to add some logic to pull all of the fieldtype attributes into the field, and add some links from this tool out to the analysis page as well) but I just wanted to go on record that i think it's really cool.
Greg: if you are interested, one way to avoid the issues with get-files and the stylesheet hearder would be to write a new JSP and/or servlet just for powering the schema explorer that applies the transformation on the server side -- it should be fairly easy with the XSL Transform utility methods Bertrand added to support the XSLTResponseWriter. ... then we don't have to require the files have the correct stylesheet declaration, or inject the one we want, or rely on the browser to apply it properly.
As for the license issues ... i don't think we can use those images *or* any javascript you cut/paste from the article ... but i could be wrong. if there are similar methods you can find that have an Apache compatible license, we should definitely be able to use those.
> XSLT-based "Schema Browser" in admin view
> -----------------------------------------
>
> Key: SOLR-75
> URL: http://issues.apache.org/jira/browse/SOLR-75
> Project: Solr
> Issue Type: New Feature
> Components: web gui
> Environment: any
> Reporter: Greg Ludington
> Priority: Minor
> Attachments: closed.gif, open.gif, solr75v1.diff
>
>
> The files in this upcoming patch create a simple "schema browser" for the admin tool. It serves schema.xml along with a stylesheet that in compliant browsers creates a page with a tree widget to show the fieldtypes and fields, as well as their uses and cross references. This is similar to the schemaxsl.zip originally attached to SOLR-58, but a few features have been added, and the look and feel has been changed to fit in better with the rest of the admin tool.
> Note that it does *not* work against the live IndexSchema -- it merely transforms schema.xml. There is probably not a significant difference now, but it is worth raising the issue in case there are future administration capabilities in mind (i.e. on http://wiki.apache.org/solr/MakeSolrMoreSelfService ) that might require a schema browser to be talking to the live values.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Greg Ludington <gl...@gmail.com>.
> Taking this off the list for a moment, because I may be a bit obtuse here:
(And, apparently so obtuse I negelcted to change the to: field. Such
things happen late after a launch night.)
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Greg Ludington <gl...@gmail.com>.
I attached an updated sample to the ticket that has some inheritance
support. Rather than a patch, it is a zip file that you should be
able to unzip and double-click the schema.xml (in IE or Firefox, at
least) to view the transformed result. It does show inheritance or
overriding of attributes -- although only the "weight" field has both
-- but it does not expect analyzers or any child node to be overriden,
only attributes. Let me know if this assumption is correct, as well
as any other thoughts on the sample.
Thanks,
Greg
On 12/11/06, Greg Ludington <gl...@gmail.com> wrote:
> > : What about creating an xml report (using a the live index searcher)
> > : and transforming that with XSLT to add look&feel?
> >
> > yeah ... i think you've really got something totally usable as is right
> > now, os don't feel like you have to start over. when i first typed up
>
> I do not have any real preference about starting over -- it would
> probably take the same amount of time to figure out the ugly parts of
> the XSL as it would to just do it all as straight JSP. As you both
> have suggested, I can generate intermediate XML from the IndexSchema
> to avoid doing the really ugly things in XSLT (which, of course, would
> also take some time). However, I was thinking more in terms of
> trade-offs on future work:
>
> Pro-XSLT: Using the Config utility methods, very easy for somebody to
> swap in their own version in $SOLR/conf/ in order to get their own
> look and feel.
>
> Pro-JSP: Easier for maintenance, and more approachable for new
> contributors, as JSP tends to be less impenetrable than XSLT.
>
> I should be able to finish it either way; however, I have an emerging
> crisis in my day job, so I may not be able to respond for a few days.
>
> Thanks,
> Greg
>
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Greg Ludington <gl...@gmail.com>.
> : What about creating an xml report (using a the live index searcher)
> : and transforming that with XSLT to add look&feel?
>
> yeah ... i think you've really got something totally usable as is right
> now, os don't feel like you have to start over. when i first typed up
I do not have any real preference about starting over -- it would
probably take the same amount of time to figure out the ugly parts of
the XSL as it would to just do it all as straight JSP. As you both
have suggested, I can generate intermediate XML from the IndexSchema
to avoid doing the really ugly things in XSLT (which, of course, would
also take some time). However, I was thinking more in terms of
trade-offs on future work:
Pro-XSLT: Using the Config utility methods, very easy for somebody to
swap in their own version in $SOLR/conf/ in order to get their own
look and feel.
Pro-JSP: Easier for maintenance, and more approachable for new
contributors, as JSP tends to be less impenetrable than XSLT.
I should be able to finish it either way; however, I have an emerging
crisis in my day job, so I may not be able to respond for a few days.
Thanks,
Greg
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin
view
Posted by Chris Hostetter <ho...@fucit.org>.
: > a bit -- this sort of inheritance gets ugly in XSL. Assuming there
: > are the appropriate public methods, it might be better to work
: > directly against the live IndexSchema rather than by XSLT transforming
: > the schema.xml file. The drawback, of course, is that you cannot swap
: What about creating an xml report (using a the live index searcher)
: and transforming that with XSLT to add look&feel?
yeah ... i think you've really got something totally usable as is right
now, os don't feel like you have to start over. when i first typed up
that "MakeSolrMoreSelfService" and the "Schema Explorer" section, it never
occured to me how much of that can be done using XSLT. What i was
debating in my head recently was for the things that *can't* be done over
XSLT, or are hard to do with XSLT, maybe a servlet can generated an XML
doc which reuses much of hte smae syntax, but has extra "denormalized"
tags in it for easier XSLT procesing (ie: imaging a doc where the top
level tag is "<generated-schema>" instead of schema, and all of the
default values are explicitly filled in for every <fieldtype> and all of
the inherited values are filled in for every <field> and <dynamicField>)
then you can have a XSLT which could be used to style the
schema.xml directly -- or it could be used to style the "generated-schema"
...either way: what you've got right now gets us really really far.
-Hoss
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Mike Klaas <mi...@gmail.com>.
On 12/11/06, Greg Ludington <gl...@gmail.com> wrote:
> Yes, it makes more sense, but I might go back to the drawing board for
> a bit -- this sort of inheritance gets ugly in XSL. Assuming there
> are the appropriate public methods, it might be better to work
> directly against the live IndexSchema rather than by XSLT transforming
> the schema.xml file. The drawback, of course, is that you cannot swap
> in your own XSLT to make your own look and feel, which seems to be the
> direction many people want to go with the admin tools. Any opinions
> as to how important that ability is?
What about creating an xml report (using a the live index searcher)
and transforming that with XSLT to add look&feel?
-Mike
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Greg Ludington <gl...@gmail.com>.
Yes, it makes more sense, but I might go back to the drawing board for
a bit -- this sort of inheritance gets ugly in XSL. Assuming there
are the appropriate public methods, it might be better to work
directly against the live IndexSchema rather than by XSLT transforming
the schema.xml file. The drawback, of course, is that you cannot swap
in your own XSLT to make your own look and feel, which seems to be the
direction many people want to go with the admin tools. Any opinions
as to how important that ability is?
-Greg
On 12/8/06, Chris Hostetter <ho...@fucit.org> wrote:
>
> : What do you mean by inheritng/overriding? Granted, I am only working
> : with the example schema here, but I do not see any similarities
> : between the attributes of a field, and the fieldtype. For fieldtypes,
>
> Doh! ... you're right ... there aren't any examples of what i'm talking
> about in the sample schema.xml.
>
> Basically, any "core" boolean attribute that can be set on a <field> can
> be set on a <fieldtype>, by default a field inherits all of it's
> attributes from the <filedtype> it uses, this is touched on briefly in the
> SchemaXml wiki page...
>
> Individual fields can override the various options (indexed, stored,
> etc...) that they inherit from their fieldtype.
>
> (it just so happens that the CNET schema we used as a template for hte
> orriginal example schema.xml didn't excercise this feature)
>
>
> looking at the code, the only core attribute of a <fieldtype> that can't
> be overridden by a <field> is "positionIncrementGap" (and i think that has
> more to do with it being a numeric attribute then anything else. If you
> define a new custom FieldType with custom attributes, those wouldn't
> overridable by the <field> either.
>
> I'll make a note on the TaskList that we should both document this a
> little better (and add some examples to the schema.xml)
>
>
> ...does what i was suggesting earlier make more sense now?
>
>
> -Hoss
>
>
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin
view
Posted by Chris Hostetter <ho...@fucit.org>.
: What do you mean by inheritng/overriding? Granted, I am only working
: with the example schema here, but I do not see any similarities
: between the attributes of a field, and the fieldtype. For fieldtypes,
Doh! ... you're right ... there aren't any examples of what i'm talking
about in the sample schema.xml.
Basically, any "core" boolean attribute that can be set on a <field> can
be set on a <fieldtype>, by default a field inherits all of it's
attributes from the <filedtype> it uses, this is touched on briefly in the
SchemaXml wiki page...
Individual fields can override the various options (indexed, stored,
etc...) that they inherit from their fieldtype.
(it just so happens that the CNET schema we used as a template for hte
orriginal example schema.xml didn't excercise this feature)
looking at the code, the only core attribute of a <fieldtype> that can't
be overridden by a <field> is "positionIncrementGap" (and i think that has
more to do with it being a numeric attribute then anything else. If you
define a new custom FieldType with custom attributes, those wouldn't
overridable by the <field> either.
I'll make a note on the TaskList that we should both document this a
little better (and add some examples to the schema.xml)
...does what i was suggesting earlier make more sense now?
-Hoss
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Greg Ludington <gl...@gmail.com>.
> i think it would definitely be helpful ... showing the inherited
> attributes "inline" is really what would make using the schema
> browser worth while (as opposed to just reading hte XML directly) ... it
> saves the confusion of looking at the field, then clicking over to the
> fieldtype to see what it inherits, then noticing something set on the
> fieldtype and trying to remember if the field overrides it so you go back
> ...etc.
Taking this off the list for a moment, because I may be a bit obtuse here:
What do you mean by inheritng/overriding? Granted, I am only working
with the example schema here, but I do not see any similarities
between the attributes of a field, and the fieldtype. For fieldtypes,
I see attributes like name, class, and sortMissingLast (as well as
child analyzers), whereas for fields, I see name, type, indexed,
stored, and multiValued. I do not see any overlap in attribute names
that suggest some manner of per-field override of fieldtype
definitions. Am I missing something crucial here, or when you speak
of overriding, do you just mean you want to see the separate fieldtype
attributes on the same screen as each field of that type, for
convenience sake?
Thanks,
Greg
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin
view
Posted by Chris Hostetter <ho...@fucit.org>.
: Currently, there is "usage" table on the field page, that contains a
: link from the field to the fieldtype (the usage table on the fieldtype
: page links back to all implementing fields) -- does that satisfy the
: need, or is it important to display the fieldtype data embedded within
: the field screen?
i think it would definitely be helpful ... showing the inherited
attributes "inline" is really what would make using the schema
browser worth while (as opposed to just reading hte XML directly) ... it
saves the confusion of looking at the field, then clicking over to the
fieldtype to see what it inherits, then noticing something set on the
fieldtype and trying to remember if the field overrides it so you go back
...etc.
-Hoss
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Greg Ludington <gl...@gmail.com>.
> yeah .. i wasn't sure if this version was identicle or not, it sounds like
> you added some stuff, but the key thing i was refering to was what
> when showing a "field" we should display both the direct attributes as
> well as any attributes it inherits from it's "fieldtype"
Currently, there is "usage" table on the field page, that contains a
link from the field to the fieldtype (the usage table on the fieldtype
page links back to all implementing fields) -- does that satisfy the
need, or is it important to display the fieldtype data embedded within
the field screen?
-Greg
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin
view
Posted by Chris Hostetter <ho...@fucit.org>.
: originally attached to an earlier JIRA issue, but this one should
: include every attribute in a field or fieldtype -- the "attributes"
: table should contain every attribute of the node. Also, I included
yeah .. i wasn't sure if this version was identicle or not, it sounds like
you added some stuff, but the key thing i was refering to was what
when showing a "field" we should display both the direct attributes as
well as any attributes it inherits from it's "fieldtype"
: (via cut-and-paste) the basic analysis form, so that it shows for each
: field (and submits to analysis.jsp) as well. If these do not fit what
i was just thinking that link to the form with the field field name
prepopulated would be great, but it sounds like you've already done one
better.
: I thought about doing the transformation server-side as well, but I
: stuck client-side because other admin pages rely on client-side
: transformation. I can rework it as a server-side transformation, if
i don't really have a strong opinion about it .. but i do see a big
distinction between this and the existing JSPs -- they are generating XML
content which includes a hint for the client about how it can be styled
for readability. In this case, we are proactively styling a flat config
file regardless of what kind of styling information it may have in it.
afterall: if you already need to do some parsing of hte file serverside to
put in the stylesheet header, you might as well go all out.
(incidently: what happens with the existing patch if the file already has
a differnet stylesheet header that the client uses for other purposes?)
: characters instead, unless somebody can locate license free icons, or
i believe there are a few creative commons icon repositories out there --
we wouldnt' be the first OpenSource project to need some images :)
: have to rework the XSL to take SOLR-76 into account.) If it is
: permissible, I think it would be better to use the original code and
: credit the author, both to give the original author deserved credit
: for his idea and to minimize duplication of work on our parts :)
yeah, but code is code and the Apache rules of using someones code without
their explicit permission are fairly rigid -- not that i completley
understand them, but i'm pretty sure cutting and pasting from a random
webside is a no-no.
-Hoss
Re: [jira] Commented: (SOLR-75) XSLT-based "Schema Browser" in admin view
Posted by Greg Ludington <gl...@gmail.com>.
I do not know if you have seen the update, as opposed to the one
originally attached to an earlier JIRA issue, but this one should
include every attribute in a field or fieldtype -- the "attributes"
table should contain every attribute of the node. Also, I included
(via cut-and-paste) the basic analysis form, so that it shows for each
field (and submits to analysis.jsp) as well. If these do not fit what
you need, and do not have time to take a further look, I would be
happy to take suggestions for tweaks.
I thought about doing the transformation server-side as well, but I
stuck client-side because other admin pages rely on client-side
transformation. I can rework it as a server-side transformation, if
that is preferable. The only downsides to server-side approach would
be the extra (likely insignificant) burden on the server, and the size
of the page -- the transformed HTML will be an order of magnitude
larger than the XML.
As for the licensing, I did modify the code from an article, but it is
still largely intact. I could easily write javascript that is
entirely free of the original article code, and/or contact the
original author for explicit permission. As for the icons -- I am not
much of a graphic artist. I could also rewrite the tree to use
characters instead, unless somebody can locate license free icons, or
perhaps the people redoing SOLR-76 could also create new icons of that
size? (The XSL in this issue shares the base admin.css, so we may
have to rework the XSL to take SOLR-76 into account.) If it is
permissible, I think it would be better to use the original code and
credit the author, both to give the original author deserved credit
for his idea and to minimize duplication of work on our parts :)
-Greg
On 12/6/06, Hoss Man (JIRA) <ji...@apache.org> wrote:
> [ http://issues.apache.org/jira/browse/SOLR-75?page=comments#action_12456253 ]
>
> Hoss Man commented on SOLR-75:
> ------------------------------
>
> I really haven't had the time to play with this that i hoped i would (i was really hoping to try and tweak it to add some logic to pull all of the fieldtype attributes into the field, and add some links from this tool out to the analysis page as well) but I just wanted to go on record that i think it's really cool.
>
> Greg: if you are interested, one way to avoid the issues with get-files and the stylesheet hearder would be to write a new JSP and/or servlet just for powering the schema explorer that applies the transformation on the server side -- it should be fairly easy with the XSL Transform utility methods Bertrand added to support the XSLTResponseWriter. ... then we don't have to require the files have the correct stylesheet declaration, or inject the one we want, or rely on the browser to apply it properly.
>
> As for the license issues ... i don't think we can use those images *or* any javascript you cut/paste from the article ... but i could be wrong. if there are similar methods you can find that have an Apache compatible license, we should definitely be able to use those.
>
> > XSLT-based "Schema Browser" in admin view
> > -----------------------------------------
> >
> > Key: SOLR-75
> > URL: http://issues.apache.org/jira/browse/SOLR-75
> > Project: Solr
> > Issue Type: New Feature
> > Components: web gui
> > Environment: any
> > Reporter: Greg Ludington
> > Priority: Minor
> > Attachments: closed.gif, open.gif, solr75v1.diff
> >
> >
> > The files in this upcoming patch create a simple "schema browser" for the admin tool. It serves schema.xml along with a stylesheet that in compliant browsers creates a page with a tree widget to show the fieldtypes and fields, as well as their uses and cross references. This is similar to the schemaxsl.zip originally attached to SOLR-58, but a few features have been added, and the look and feel has been changed to fit in better with the rest of the admin tool.
> > Note that it does *not* work against the live IndexSchema -- it merely transforms schema.xml. There is probably not a significant difference now, but it is worth raising the issue in case there are future administration capabilities in mind (i.e. on http://wiki.apache.org/solr/MakeSolrMoreSelfService ) that might require a schema browser to be talking to the live values.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>