response writer 'default' action

[Ryan McKinley <ry...@gmail.com>]

The response writers print a debug message when you put a non-standard
value in them:

    } else {
      // default... for debugging only
      writeStr(name, val.getClass().getName() + ':' + val.toString(), true);
    }

All the values used in the standard handlers are in the list, so this
is fine.  I'm writing some custom handlers where it would be nice to
put an arbitrary object into the response and have it printed out with
toString()

    } else {
      writeStr(name, val.toString(), true);
    }

Of course I could put it into the response with .toString(), but it
would be more convenient to keep it in the response as an Object so
that I can use it later down the chain.

Can we change this behavior?

thanks
ryan

Re: response writer 'default' action

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

On 3/4/07, Ryan McKinley <ry...@gmail.com> wrote:
> Yes, i could figure some other way to do this, but mostly I was
> surprised that the writers default to a debugging action rather then a
> useful one.

It was useful to me at the time to try and figure out if I had
everything in the list I needed ;-)

I'm OK with toString() for Object (I don't see it as a big deal either
way, really).

> > ... but i agree it would be handy to add a...
> >
> >   public void writeUnknown(String name, Object val, boolean needsEscaping) {
> >     writeStr(name, val.getClass().getName() + ':' + val.toString(), needsEscaping);
> >   }
> >
> > ...to the base writers so that people could override in subclasss
> > for special purposes and then call that in the else case.
> >
>
> Yes, that would be nice.

Very expert level use, may change from release-to-release :-)

-Yonik

Re: response writer 'default' action

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

: That list is not quite up-to-date, it should add:
:
:  * Document

Really? ... i guess i missed that one (i thought it had to be in a
DocList)

:   * Collection should be changed to: Iterable
:  * Iterator

Collection changed to Iterable i remember (that was totally backwards
compatably) adding Iterator didn't click for me.

: Yes, I'm suggesting we say what happens if you add an Object not on
: the list.  I think the most reasonable behavior is to say: "Objects
: not contained in this list will be treated as a String using the value
: returned from Object.toString()"

i was mainly just pointing out that changes like that affect people who
have already written their own ResponseWriters ... i'd prefer not to do
that in backwards INcompatible ways without a really good reason.

: > personaly, i'd prefer we encourage RequestHandler writers to stick to that
: > contract and unwind their objects themselves so that their RequestHandlers
: > can be reused with any ResponseWRiter
:
: how would treating Objects as "toString()" limit what ResponseWriters
: could be used?  Am i missing something?

i was refering to ResponseWriters written for older versions of hte
contract: that don't expect anything not on that list.

in general, i think it's better if RequestHandlers unwind the object
because that way any errors happen well before the writer starts to
generate the response (while there is still time to deal with the error,
and well before any risk of the HTTP response already being flushed so
that we can't change the HTTP status code.

besides which a RequestHandler is in a better position to say
response.add(obj.toString()) and know that is the right thing to do then a
ResponseWriter ... you might have a bug in your RequestHandler that causes
it to put hte wrong thing in the response and not understand where the
weird string in your response is coming from ... letting hte
ResponseWriter throw an error (or return the debuging info it currently
does) forces you to do the right thing in your RequestHandler.

: The thing that is nice about allowing an Object in the response is
: that the you can pull it out later rather then a unwound version.  In

...that's what SOlrQueryRequest.getContext() is for, the response should
really only be for data you genuniely want returned (unwound into simple
primitives so there's less risk of error once your RequestHandler no
longer has any control over it)


-Hoss

Re: response writer 'default' action

[Ryan McKinley <ry...@gmail.com>]

>
> Keep in mind, there is a contract about what constitutes "Returnable data"
>
> http://lucene.apache.org/solr/api/org/apache/solr/request/SolrQueryResponse.html#returnable_data
>

That list is not quite up-to-date, it should add:

 * Document
  * Collection should be changed to: Iterable
 * Iterator

> ...what you're describing would be a modification of that contract.
>

Yes, I'm suggesting we say what happens if you add an Object not on
the list.  I think the most reasonable behavior is to say: "Objects
not contained in this list will be treated as a String using the value
returned from Object.toString()"


> personaly, i'd prefer we encourage RequestHandler writers to stick to that
> contract and unwind their objects themselves so that their RequestHandlers
> can be reused with any ResponseWRiter

how would treating Objects as "toString()" limit what ResponseWriters
could be used?  Am i missing something?

The thing that is nice about allowing an Object in the response is
that the you can pull it out later rather then a unwound version.  In
my use case, I have functions that pump data into the response, they
are surrounded with at try {} that if something goes wrong checks
their content and does stuff.

Yes, i could figure some other way to do this, but mostly I was
surprised that the writers default to a debugging action rather then a
useful one.


> ... but i agree it would be handy to add a...
>
>   public void writeUnknown(String name, Object val, boolean needsEscaping) {
>     writeStr(name, val.getClass().getName() + ':' + val.toString(), needsEscaping);
>   }
>
> ...to the base writers so that people could override in subclasss
> for special purposes and then call that in the else case.
>

Yes, that would be nice.

Re: response writer 'default' action

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

: All the values used in the standard handlers are in the list, so this
: is fine.  I'm writing some custom handlers where it would be nice to
: put an arbitrary object into the response and have it printed out with
: toString()

Keep in mind, there is a contract about what constitutes "Returnable data"

http://lucene.apache.org/solr/api/org/apache/solr/request/SolrQueryResponse.html#returnable_data

...what you're describing would be a modification of that contract.

personaly, i'd prefer we encourage RequestHandler writers to stick to that
contract and unwind their objects themselves so that their RequestHandlers
can be reused with any ResponseWRiter ... but i agree it would be handy to
add a...

  public void writeUnknown(String name, Object val, boolean needsEscaping) {
    writeStr(name, val.getClass().getName() + ':' + val.toString(), needsEscaping);
  }

...to the base writers so that people could override in subclasss
for special purposes and then call that in the else case.



-Hoss