> Does anyone have any thoughts on this? Should Compojure output HTML
> without any indentation?
I like the indentation. I think reading HTML output in the REPL or in
test results (not to mention curl) is a common enough use case that it's
worth spending a bit of extra effort to keep it readable.
It's easy enough to turn off by using xml instead of html. But I haven't
been bitten by any problems such as with pre. Is it infeasible to
special-case pre?
-Phil
> The problem is that it's turning into a significant effort to maintain
> three different formatters: raw xml, indented xml, and formatted html.
> Removing formatting means I can cut all the formatting code that's
> giving me trouble.
>
> It would also open up the possibility of using Mark McGranaghan's clj-
> html library, which should be faster than Compojure's current
> implementation.
OK, I buy that. I like more maintainable code. =)
> Readable output is useful. However, Java's XML libraries can parse and
> output indented XML, so it wouldn't be too difficult to whip up an XML
> pretty-printer function for this scenario. If I added an ppxml
> function to the standard libraries, would this be an acceptable
> substitute?
Yeah, sure. We would need output from higher-level tests to use it where
appropriate, but that's not hard. Speaking of higher-level tests, the
example app is a little short on them; is there anywhere else we could
find guidelines on compojure tests, or is this another one of those "the
trail is yours to blaze" situations?
> In order to get around this, I need to add an indentation argument to
> each formatter, so that each element would render its own indentation,
> rather than being indented by its parent. This would allow pre to
> ignore the indentation level.
Could you use a dynamic variable to do this without passing an argument
around all over the place? If not, I'd vote for dropping it in favour of
xmlpp.
-Phil
> On Jan 9, 12:54 am, Phil Hagelberg <p...@hagelb.org> wrote:
>> Yeah, sure. We would need output from higher-level tests to use it where
>> appropriate, but that's not hard. Speaking of higher-level tests, the
>> example app is a little short on them; is there anywhere else we could
>> find guidelines on compojure tests, or is this another one of those "the
>> trail is yours to blaze" situations?
>
> Higher-level tests? Do you mean unit testing?
I guess I'm used to having my test suite split up into lower level unit
tests and then integration tests that are about how the pieces fit
together. But because Compojure views are just functions, (rather than
in most Ruby systems where they're separate files in another language)
you don't need any special tools to test them.
Still, it would be nice to have test-helper functions that can do things
like set up fake requests and make it easy to fake sessions. You can
just def those in your tests of course, but I wouldn't know what kinds
of things they would need to contain to really be a viable replacement
for the jetty ones. Functions to test that a given HTML rendering
contains what you're expecting would be great too, but that would
require implementing a jQuery-style CSS-selector engine, which is
probably a fair amount of work.
>> Could you use a dynamic variable to do this without passing an argument
>> around all over the place? If not, I'd vote for dropping it in favour of
>> xmlpp.
>
> I'm not sure what you mean by a dynamic variable, I'm afraid, unless
> you mean putting it in a top-level var.
I was thinking you could use binding; that way the indentation level
could be based on the previous value, but it would automatically
decrement when you return from a function. You could bind it to zero
within <pre>s. But maybe that's not feasible in this case; I haven't
looked at it closely.
In any case, converting it to pretty-printed after the fact is fine for
me. That way you don't incur the overhead of all these calculations
unless you really need it.
-Phil