webiyo-developers — Developers

Re: [Webiyo-developers] TreeBuilder in Python 2.5

[Justin T. S. <ju...@kr...>]

On 3/9/07, Jim Kingdon <jki...@gr...> wrote:

> The hotter one just now is Ruby's builder:
> http://builder.rubyforge.org/

Hm! Interesting use of dynamic method names for building elements, and
closures for specifying the content inside an element.

I just ran across this one:
http://allegroserve.sourceforge.net/aserve-dist/doc/htmlgen.html

They get some important things wrong (like, umm, not escaping text by
default) but it's an interesting direction to go with Lisp macros...

Cheers,
Justin

Re: [Webiyo-developers] TreeBuilder in Python 2.5

[Jim K. <jki...@gr...>]

> http://docs.python.org/lib/elementtree-treebuilder-objects.html

Thanks; I hadn't seen that one.

The hotter one just now is Ruby's builder:
 http://builder.rubyforge.org/

[Webiyo-developers] TreeBuilder in Python 2.5

[Brian S. <br...@sl...>]

This API looks rather familiar:

http://docs.python.org/lib/elementtree-treebuilder-objects.html

Re: [Webiyo-developers] XmlFormat and a few method renames

[Jim K. <jki...@gr...>]

> The rules for newlines are whatever seemed to result in readable
> output when doing "view source".

The existing rules in HtmlWriter are pretty simple now that I
understand them: most tags, especially block-level tags, put newlines
before start tags and after end tags.  The rest, especially inline-level
tags, do not insert newlines.  I have preserved these rules.

Anyway, I have finished the transition to XmlFormat, in the sense that
the newline flag is gone from TagType and XmlFormat.GENERIC now works
and in general I'm not really aware of glaring problems.

> I chose "tag" just because I wanted something short for a
> commonly-used method.  "emptyTag" sounds fine although I'll miss the
> brevity.  (Or would if I were actually using Webiyo :-)

Well, it is less commonly used than startTag, endTag, or text.
I'll leave this one alone for the moment in case more consensus
develops.

I have gone ahead with println->newline.

Re: [Webiyo-developers] XmlFormat and a few method renames

[Brian S. <br...@sl...>]

The rules for newlines are whatever seemed to result in readable
output when doing "view source".  If you change the defaults, I expect
it will break some tests, and then you can look at the output to see
if the new behavior is also readable.

I chose "tag" just because I wanted something short for a
commonly-used method.  "emptyTag" sounds fine although I'll miss the
brevity.  (Or would if I were actually using Webiyo :-)

- Brian

On 2/13/07, Jim Kingdon <jki...@gr...> wrote:
> 1.  Justin, if you still have local changes you haven't
> checked in, it would be great if you could get those in.
> The more I hack, the more trouble merging will be...
>
> 2.  I have checked in a partial implementation of the
> XmlFormattter which Justin discussed on the list (I called
> it XmlFormat).
>
> Previous behavior should be preserved:
>
> a.  for XmlBuilder (which never automatically adds newlines), and
>
> b.  for HtmlWriter
>
> But:
>
> c.  If you construct an XmlWriter directly, you may get strange
> results (depending a bit on which methods you call).
>
> The reason the job is not done is:
>
> a.  I'm still trying to get my mind around the rules currently
> implemented by HtmlWriter, and those implied by the XmlFormat
> interface which Justin described, and
>
> b.  I just ran out of time for today.
>
> 3.  Probably not my last naming question, but I propose
> renaming the following two methods in XmlWriter:
>
> println -> newline
>   This method is not public, so I propose to just rename it.
> tag -> emptyTag
>   These two methods are public, so I suppose we should add
>     new ones and deprecate the old (although that's largely
>     up to you, Justin.  I know I'm not using this).
>
> Perhaps the rationale for these names is obvious, but "tag"
> doesn't seem specific to me.  I think we might have used
> "singleTag" at NewEdu (certainly I called it that in
> XmlBuilder), but that doesn't really make much sense.  The
> phrase in the XML spec is "empty-element tag", of which
> emptyTag seems like a reasonable short form.
>
> And "println", well, it may have tradition behind it, but
> we just don't name methods like that these days...
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> webiyo-developers mailing list
> web...@li...
> https://lists.sourceforge.net/lists/listinfo/webiyo-developers
>
>

[Webiyo-developers] XmlFormat and a few method renames

[Jim K. <jki...@gr...>]

1.  Justin, if you still have local changes you haven't
checked in, it would be great if you could get those in.
The more I hack, the more trouble merging will be...

2.  I have checked in a partial implementation of the
XmlFormattter which Justin discussed on the list (I called
it XmlFormat).

Previous behavior should be preserved:

a.  for XmlBuilder (which never automatically adds newlines), and

b.  for HtmlWriter

But:

c.  If you construct an XmlWriter directly, you may get strange
results (depending a bit on which methods you call).

The reason the job is not done is:

a.  I'm still trying to get my mind around the rules currently
implemented by HtmlWriter, and those implied by the XmlFormat
interface which Justin described, and

b.  I just ran out of time for today.

3.  Probably not my last naming question, but I propose
renaming the following two methods in XmlWriter:

println -> newline
  This method is not public, so I propose to just rename it.
tag -> emptyTag
  These two methods are public, so I suppose we should add
    new ones and deprecate the old (although that's largely
    up to you, Justin.  I know I'm not using this).

Perhaps the rationale for these names is obvious, but "tag"
doesn't seem specific to me.  I think we might have used
"singleTag" at NewEdu (certainly I called it that in
XmlBuilder), but that doesn't really make much sense.  The
phrase in the XML spec is "empty-element tag", of which
emptyTag seems like a reasonable short form.

And "println", well, it may have tradition behind it, but
we just don't name methods like that these days...

Re: [Webiyo-developers] XmlBuilder checked in

[Jim K. <ki...@pa...>]

> I actually tried using Java 5 tricks to get around this. You can use
> generic types in throws clauses, so I tried parameterizing HtmlWriter
> with something like <E extends Exception> and then changing all the
> 'throws IOException' to 'throws E'. This allows a user to declare
> HtmlWriter<RuntimeException> and not have to deal with IOException.

Interesting.

I may have to play around with that some day.

As you found, it might end up being too cumbersome (which also matches
my experience in trying to use generics heavily - one just gets lost
in angle brackets whenever declaring a variable/parameter/etc).  But I
didn't know the "throws E" bit was even possible.

Re: [Webiyo-developers] XmlBuilder checked in

[Justin T. S. <ju...@kr...>]

On 2/10/07, Jim Kingdon <ki...@pa...> wrote:

> * XmlBuilder does not just inherit from XmlWriter, it delegates to it.
>   This is so that the delegation methods can avoid being declared
>   throws IOException (which won't happen because we pass in a
>   StringWriter).
>
> I have not yet implemented the common interface/superclass.  Given the
> exception handling detail, I'm not sure it would be as useful as it
> looks.

Oh yeah, that is one thing about using the Appendable style that got
in my way. It's a good thing I don't really mind saying 'throws
Exception' everywhere. :)

I actually tried using Java 5 tricks to get around this. You can use
generic types in throws clauses, so I tried parameterizing HtmlWriter
with something like <E extends Exception> and then changing all the
'throws IOException' to 'throws E'. This allows a user to declare
HtmlWriter<RuntimeException> and not have to deal with IOException.
However, it was such a pain to declare HtmlWriter<RuntimeException>
everywhere that I abandoned the idea. :P

Cheers,
Justin

Re: [Webiyo-developers] XmlBuilder checked in

[Jim K. <ki...@pa...>]

> So, I think Jim is ahead of us as usual.  :-)

If so, it might be accidental :-).  I'm certainly not seeing all the
implications in terms of Page, View, immutability, etc.  But I've
never been the quickest one in the bunch to see the big picture.

> Maybe it's time to read some code.

Sure.  Like I think I said in the other message, XmlBuilder and
XmlWriter are now unified to the point where XmlBuilder is a thin
wrapper around XmlWriter.  So there is code to look at.

I suppose if you want examples of usage, you can always look at MIFOS,
for example:
http://fisheye4.cenqua.com/browse/mifos/trunk/mifos/src/org/mifos/application/office/struts/tag/OfficeListTag.java?r=trunk

Re: [Webiyo-developers] XmlBuilder checked in

[Jim K. <ki...@pa...>]

> Replying to the whole thread...

It will make for a long message, but I'll do the same.

> I definitely like building web pages in memory, but I haven't
> noticed Appendable being an issue. Then again I haven't had a need
> for passing around fragments.

I've already unified the streaming and non-streaming variants in
webiyo's CVS.  And the streaming stuff is no longer in the way if you
just want to do the non-streaming style.  So I don't really have a
need to get rid of the streaming code.  The key points are:

* XmlWriter and XmlBuilder each have an .append(XmlBuilder) method.

* XmlBuilder does not just inherit from XmlWriter, it delegates to it.
  This is so that the delegation methods can avoid being declared
  throws IOException (which won't happen because we pass in a
  StringWriter).

I have not yet implemented the common interface/superclass.  Given the
exception handling detail, I'm not sure it would be as useful as it
looks.

> Have any of y'all ever tried just using DOM (or a variation such
> as JDOM) for rendering web pages?

This is often advocated (see for example the first comment to
http://lwn.net/Articles/179569/ ).  The DOM just seems like a
complicated API, and that doesn't do wonders for the readability of
the rendering code.  I guess you hit the nail on the head of a good
part of the complexity when you suggest "Unless, of course, we had a
builder object that kept a stack, giving an API much like what we have
with XmlWriter/Builder...".  Depending on which DOM dialect there may
be other annoying details (namespaces, whatever).

> interface XMLFormatter {
>     boolean newlineBeforeStartTag(String tagName);
>     . . .

That looks fairly nice.  What about making it even simpler and adding
methods to XmlWriter:
    void newlineBeforeStartTag(String tagName);
so that you could just call
    XmlWriter writer = new XmlWriter();
    writer.newlineBeforeStartTag("body");
    writer.newlineBeforeStartTag("p");
etc.

I don't know, maybe I like the XMLFormatter one better (especially
when I start to think about needing additional features to do
something like "always before a start tag").  And I like your
observation that there are a lot of documents for which "always before
a start tag and after an end tag" works well.

But something like this...

> I'm curious, which do you think is not necessarily a good thing,
> DOCTYPE or processing instructions?

Well, I was talking about XML declarations (that's the thing which
starts "<?xml" - despite looking like a processing instruction it
isn't one, see:
http://www.w3.org/TR/xml/#sec-prolog-dtd
).

DOCTYPE is very evil, or more specifically what is evil is when XML
parsers insist on fetching the DTD over the network in order to load a
file (thus slowing things down and failing to work when you aren't
connected).  By leaving out DOCTYPE you can avoid tempting anyone.  I
see that the HTML5 draft at 
  http://www.whatwg.org/specs/web-apps/current-work/#the-doctype
has "solved" this problem by specifying a doctype of 
  <!DOCTYPE html>
which at least has no DTD to fetch.

As for XML declarations, they're more harmless, but I'm also not sure
there are a lot of problems that they solve.

I guess my objections boil down mostly just to "I don't really see the
need for DOCTYPES or XML declarations, and the mental cycles spent
thinking about them can be better spent".  They do make it hard to do
things like write something which can be either an entire document or
a piece of one, but that's probably more of an aesthetic objection
than a big problem.

> 4. XmlBuilder has comments.

XmlWriter now has them too.

> Didn't we end up having most objects *not* implement Renderable at
> NewEdu?

That's right.  With a Renderable, when you need to pass in data to the
object, you need to pass it in via the constructor.  Whereas if you
know where the render method is going to get called from, then you can
pass in whatever makes sense.

> I hadn't heard of XMLStreamWriter so I got a little excited, but I
> just looked at the interface and I'm no longer exicted.

Yeah, I've had the same reaction to the other XML writing libraries
I've seen.  I guess if you are more worried about "can it enforce
well-formedness in all cases" and other such things, you get a rather
different interface than if the problem is "how can I make it as easy
as possible to generate some XML"?

> Ah, I hadn't heard the phrase "opinionated software" yet either.
> Thanks! I can definitely see Webiyo as being opinionated. My other
> favorite tool, Prevayler, certainly is. :)

The term was popularized (maybe invented) by the Ruby on Rails guy.  I
wrote a bit more about opinionated software in another context towards
the end of
http://jkingdon2000.blogspot.com/2007/01/is-sql-strongly-typed-language.html

Oddly enough, I recently broke down and started adding options to
Mayfly.  But that's worth writing about for the world:
http://jkingdon2000.blogspot.com/2007/02/mayfly-starts-to-get-options-sooner.html

> http://happs.org/HAppS/README.html

This also looks cool.  Unfortunately, I've never really climbed far
enough up the Haskell learning curve to get most of what is going on
there, but maybe someday...

Re: [Webiyo-developers] XmlBuilder checked in

[Brian S. <br...@sl...>]

On 2/10/07, Justin T. Sampson <ju...@kr...> wrote:

> I definitely like building web pages in memory, but I haven't
> noticed Appendable being an issue. Then again I haven't had a need
> for passing around fragments.

I thought this over a bit more.  The approach I've been using based on
what we did at NewEdu is to define Page and View classes with render()
methods.  These classes tend to have a bunch of instance variables
containing the parts of the template that change.  When render() is
called, they get interspersed with string constants representing the
fixed part of the template.

Another way of representing the same thing is to have an array of
bytes or characters.  Though one representation is high-level and the
other is low-level, as far as basic rendering is concerned, the two
representations implement the same functionality.  (The high-level
representation can do more but normally we don't need it.)

The low-level representation might seem to use more memory because it
includes the constant parts of the page as well as the dynamic parts.
However, it seems really hard to judge: there's a lot of overhead in a
tree of Java objects, but on the other hand if the objects are
immutable there might be sharing.  Probably the only way to tell for
sure is to do some benchmarks, and I don't think that's how we want to
make the decision anyway.

Maybe the main advantage to an XmlBuffer class is that lots of
boilerplate classes and instance variables go away and get replaced by
a single representation for all Pages and Views that only needs to be
written once.  If there's an immutable variant of an XmlBuffer, then
it also solves the immutability problem once and for all.  I remember
writing (and refactoring) lots of application-level immutable objects
just so we could pass them out of Prevayler in a thread-safe way, and
it seems like that would all go away.  If there were classes for
separate Pages and Views, it would be purely for type-checking to
avoid mixing them up, such as if you subclassed the Id class to get
UserId, ProductId, and so on.

So, I think Jim is ahead of us as usual.  :-)  Although I seem to
recall that William asked for something similar when he was using
Webiyo.  Maybe it's time to read some code.

- Brian

Re: [Webiyo-developers] XmlBuilder checked in

[Justin T. S. <ju...@kr...>]

Howdy,

Replying to the whole thread...

Jim wrote:

> 2. It builds in memory rather than sending to an Appendable.
> Although the Appendable is the more general solution, and you
> can always think of a use case where you don't want to store the
> entire XML document in memory, generating web pages is not one
> of those use cases, and I really like the ability to pass around
> an XmlBuilder instead of a Renderable. See XmlBuilder#append(
> XmlBuilder builder) or XmlBuilderTest#testCompose for that. With
> XmlWriter you end up with two objects, a StringBuilder and an
> XmlWriter, and you can't just forget about one because you need
> the builder around to get your output at the end.

I definitely like building web pages in memory, but I haven't
noticed Appendable being an issue. Then again I haven't had a need
for passing around fragments.

Have any of y'all ever tried just using DOM (or a variation such
as JDOM) for rendering web pages? I guess it would resolve some
issues and introduce some others. It would be impossible to forget
to call endTag, say (though we catch that at runtime anyway), and
it trivially answers the question of how to generate fragments and
assemble them later. The actual coding might get awkward, though,
since you'd have to keep track of individual objects in order to
add children to them, so there would be lots of temporary
variables cluttering the code. Unless, of course, we had a builder
object that kept a stack, giving an API much like what we have
with XmlWriter/Builder...

> 3. XmlWriter can insert newlines for you. XmlBuilder is still at
> the stage of either do without, or call .newline(). The
> XmlWriter feature is handy, of course the catch is that it
> requires knowledge of the schema (e.g. that this is HTML).

The last time I implemented this pattern (unfortunately in a
proprietary codebase) I came up with a fairly elegant little
formatter interface for determining which tags should have
newlines at which places. The interface looked something like
this:

interface XMLFormatter {
    boolean newlineBeforeStartTag(String tagName);
    boolean newlineAfterStartTag(String tagName);
    boolean newlineBeforeEndTag(String tagName);
    boolean newlineAfterEndTag(String tagName);
}

I think it basically came down to having a list of block-level
tags and a list of inline-level tags in the case of HTML, though I
think there was some subtle difference; and we also had a generic
XML formatter that just always returned true for
newlineBeforeStartTag and newlineAfterEndTag and false for the
others, which worked nicely for any XML format where every element
contains either child elements or text but not mixed content, of
which we had several (some simple webservices).

> 4. XmlBuilder has comments. XmlWriter has DOCTYPE and <?xml
> declarations (not necessarily a good thing, but that could
> easily be a whole 'nother flamewar and I could see catering to
> callers of different religions on this).

Yeah, might as well support all three. I'm curious, which do you
think is not necessarily a good thing, DOCTYPE or processing
instructions?

Brian wrote:

> Writing multiple-megabyte XML data files seems reasonably common
> and it would be a shame for a stream-like API to not actually
> support streaming. How about having XmlBuffer and XmlStream
> concrete classes and a common XmlSink (name grabbed at random)
> superclass? This would be somewhat analogous to Writer/
> StringWriter/OutputStreamWriter. It seems like it would be
> reasonably common to write a loop that creates XmlBuffers for
> fragments and writes them to a stream. But maybe that's too
> complicated.

Hm! That actually sounds quite nice.

> BTW, I think Webiyo might get more adoption if promoted as a way
> to write XML data rather than HTML documents. People seem pretty
> tied to templates but a programmatic API for writing well-formed
> XML is much less controversial. We can always use it for XHTML
> anyway.

Yeah, as I hinted above, I used this style (though not Webiyo
itself) for XML webservices as well as HTML webpages in one
project. It didn't catch on for HTML... Actually, come to think of
it, I had pretty much only used it for HTML in a standalone
prototype I built; the actual app was all JSF with JSP for
webpages. Then I was happy to be able to reuse the code when the
webservices came up, and it was just me and a reasonable colleague
(Che Hammond, who you might have met at BayXP from time to time)
working on it so we could do whatever we wanted. :)

Oh, it *did* end up getting used for rendering reports when
Crystal was finally judged inadequate (I could use harsher words,
but that's a whole other story). In that case we had another
interface expressing higher-level styles in order to have an
HTMLWriter-style implementation as well as an iText (PDF)
implementation driven by the same report code.

> Yes, I do like having some kind of XmlBuffer object.
>
> (I kind of like Renderable but it's a frameworky thing and
> there's no reason you can't define your own.)
>
> Hm... that's a bit too opinionated. Prefix everything with, "Do
> what you like, but for what it's worth, "

Good point about Renderable being "frameworky". It does impose
itself a bit much on the calling code. I haven't really had a
problem with it so far, except for the occasional need for more
parameters. Didn't we end up having most objects *not* implement
Renderable at NewEdu? Seems like we started out marking any object
that had a render() method as Renderable, but actually most
objects were just handled directly and never needed to be passed
as Renderable so the interface was unnecessary and just getting in
the way.

Jim wrote:

> > How about having XmlBuffer and XmlStream concrete classes and
> > a common XmlSink (name grabbed at random) superclass?
>
> I'm not eager to jump on this, since the only real thing we have
> going for us is simplicity (there are lots of other XML writing
> libraries, with the most famous perhaps being
> javax.xml.stream.XMLStreamWriter which is part of Java 1.6).

I hadn't heard of XMLStreamWriter so I got a little excited, but I
just looked at the interface and I'm no longer exicted. :P We
definitely have simplicity. I actually like that we do *not*
handle namespaces explicitly. Their method names are too wordy
(writeStartElement vs. startTag). And they got writeEndElement
wrong -- it doesn't take the tagname as a parameter.

> > People seem pretty tied to templates
>
> Well, one of the things I'm using XmlBuilder for is to implement
> JSP tags. I haven't really been following the newfangled
> template systems, but I would kind of guess that something like
> tag libraries will either survive or get reinvented.

Yeah -- which reminds me of another area where HTMLWriter got used
on that project I mentioned earlier. We also used it for
implementing some custom JSP tags. Actually, one thing (well, the
only thing) that impressed me about JSF is that their "custom
component" interface includes an HTMLWriter-like output object. It
was even more ugly and complicated than XMLStreamWriter, but it
was a nice thought anyway...

> > Hm... that's a bit too opinionated. Prefix everything with,
> > "Do what you like, but for what it's worth, "
>
> Well, opinionated is good, in the sense of "opinionated
> software". We just have to figure out which opinions are
> webiyo's opinions.

Ah, I hadn't heard the phrase "opinionated software" yet either.
Thanks! I can definitely see Webiyo as being opinionated. My other
favorite tool, Prevayler, certainly is. :)

By the way, this was posted to the Prevayler list recently:
http://happs.org/HAppS/README.html

Cheers,
Justin

Re: [Webiyo-developers] XmlBuilder checked in

[Jim K. <jki...@gr...>]

> I'll meekly admit that I've also added a few convenience methods that
> aren't covered by tests in the Webiyo codebase, but are covered by
> tests in my application's codebase...

I think I've even advocated roughly similar behavior (at
least in some contexts).

Amazing how different it seems when looking at it from a
different angle.  (I wonder if Eric Evans talks about this
in the second half of Domain Driven Design?  I really need
to get a copy of that book some day and find time to read it).

Re: [Webiyo-developers] XmlBuilder checked in

[Justin T. S. <ju...@kr...>]

On 1/31/07, Jim Kingdon <jki...@gr...> wrote:

> Sounds good.  Of course, I first had to write tests for HtmlWriter
> (please tell me you just forgot to check them in, Brian.  Or maybe
> I don't want to know :-)).

I'll meekly admit that I've also added a few convenience methods that
aren't covered by tests in the Webiyo codebase, but are covered by
tests in my application's codebase...

Cheers,
Justin (now in Boston for a meeting at his company's headquarters)

Re: [Webiyo-developers] XmlBuilder checked in

[Jim K. <ki...@pa...>]

> If you try to run all the tests, you'll find that there is a test of
> the self-generating HTML for http://webiyo.sourceforge.net/ that
> requires CVS access and probably fails unless you have things
> configured the same way I did.

Eerily, that one (PublishWebiyoTest for those following at home)
(usually) passes for me.

But yeah, it requires internet access (and can fail in other ways
related to its spawning of a separate process).  Some of the other
tests in examples are a bit slow (although not as bad), and so I
created a FastTests.java which just has the more-purely-unit-tests.

Re: [Webiyo-developers] XmlBuilder checked in

[Brian S. <br...@sl...>]

On 1/31/07, Jim Kingdon <jki...@gr...> wrote:

> Sounds good.  Of course, I first had to write tests for HtmlWriter
> (please tell me you just forgot to check them in, Brian.  Or maybe
> I don't want to know :-)).

Oh ye of little faith.  The tests are in a different directory:

http://webiyo.cvs.sourceforge.net/webiyo/webiyo/test/src/org/webiyo/web/HtmlWriterTest.java?revision=1.1&view=markup

If you try to run all the tests, you'll find that there is a test of
the self-generating HTML for http://webiyo.sourceforge.net/ that
requires CVS access and probably fails unless you have things
configured the same way I did.  Other than that, they passed a couple
of years ago. :-)

- Brian

Re: [Webiyo-developers] XmlBuilder checked in

[Jim K. <jki...@gr...>]

> http://www.agileopennorthwest.com/cgi-bin/wiki.pl?SessionNotes

Sounds fun.  There was something like this on the east coast a
month or two ago, and I kind of wanted to go, but found out about
it at the last minute.

Anyway, looking forward to your larger webiyo comments once you
get back.

> Don't worry too much about my installed base, as long as the
> HtmlWriter interface basically keeps working for the near future.

Sounds good.  Of course, I first had to write tests for HtmlWriter
(please tell me you just forgot to check them in, Brian.  Or maybe
I don't want to know :-)).

Anyway, I have refactored XmlWriter and XmlBuilder to the point where
they now share a common implementation (as a side effect, XmlWriter
gained a comment() method, which I think you had wanted, Justin).
I didn't intentionally change the interface to either one.
(Oh wait, that isn't quite true, I got rid of the indent() method
in XmlBuilder because the auto-indent code in XmlWriter replaces it).

All in all, the exercise was easier than I feared (the nastiest
little detail is IOException).

> think I might have a couple small changes not checked in at the moment
> as well. :P

OK, might as well get those in (shouldn't be too hard to merge,
although if you made changes to certain parts of XmlWriter, that
could add to the work a bit).

Re: [Webiyo-developers] XmlBuilder checked in

[Justin T. S. <ju...@kr...>]

Hi! I've only glanced through these messages and I have lots of
comments to make, which I'll do in a reply in a couple of days since
I'm here now:

http://www.agileopennorthwest.com/cgi-bin/wiki.pl?SessionNotes

:)

Don't worry too much about my installed base, as long as the
HtmlWriter interface basically keeps working for the near future. I
think I might have a couple small changes not checked in at the moment
as well. :P

See ya,
Justin


On 1/30/07, Jim Kingdon <jki...@gr...> wrote:

> > I don't think there's enough of an installed base to worry about
> > backward compatibility.
>
> Well, the installed base, as far as I know, is Justin.  So
> I'll consider him the authority (I wouldn't be bothering with
> trying to discuss this on a mailing list and all that overhead
> if I just wanted something that I alone was going to work on -
> I already have that).
>
> [...]

Re: [Webiyo-developers] XmlBuilder checked in

[Jim K. <jki...@gr...>]

> I don't think there's enough of an installed base to worry about
> backward compatibility.

Well, the installed base, as far as I know, is Justin.  So
I'll consider him the authority (I wouldn't be bothering with
trying to discuss this on a mailing list and all that overhead
if I just wanted something that I alone was going to work on -
I already have that).

> How about having XmlBuffer and XmlStream concrete classes
> and a common XmlSink (name grabbed at random) superclass?

I'm not eager to jump on this, since the only real thing we
have going for us is simplicity (there are lots of other XML
writing libraries, with the most famous perhaps being
javax.xml.stream.XMLStreamWriter which is part of Java 1.6).

But you do have a good point that having the buffer variant
as a subclass would still let us have a append(XmlBuilder)
method in the superclass.

Of course it is easy to add the streaming variant later if
we start with just the buffer variant.

> People seem pretty tied to templates

Well, one of the things I'm using XmlBuilder for is to
implement JSP tags.  I haven't really been following the
newfangled template systems, but I would kind of guess
that something like tag libraries will either survive or get
reinvented.

> Hm... that's a bit too opinionated.  Prefix everything=20
> with, "Do what
> you like, but for what it's worth, "

Well, opinionated is good, in the sense of "opinionated
software".  We just have to figure out which opinions are
webiyo's opinions.

Re: [Webiyo-developers] XmlBuilder checked in

[Brian S. <br...@sl...>]

I don't think there's enough of an installed base to worry about
backward compatibility. Maybe call the new thing Webiyo 1, start
clean, and steal anything from the old code that looks useful.  (Since
the previous one never had a 1.0 release, it's Webiyo 0.)

On 1/29/07, Jim Kingdon <jki...@gr...> wrote:

> 2.  It builds in memory rather than sending to an Appendable.
> Although the Appendable is the more general solution, and
> you can always think of a use case where you don't want to
> store the entire XML document in memory, generating web pages
> is not one of those use cases,

Not having looked at the code, I'll comment anyway:

Writing multiple-megabyte XML data files seems reasonably common and
it would be a shame for a stream-like API to not actually support
streaming.  How about having XmlBuffer and XmlStream concrete classes
and a common XmlSink (name grabbed at random) superclass?  This would
be somewhat analogous to Writer/StringWriter/OutputStreamWriter.
It seems like it would be reasonably common to write a loop that
creates XmlBuffers for fragments and writes them to a stream.  But
maybe that's too complicated.

BTW, I think Webiyo might get more adoption if promoted as a way to
write XML data rather than HTML documents.  People seem pretty tied to
templates but a programmatic API for writing well-formed XML is much
less controversial.  We can always use it for XHTML anyway.

> I really like the ability to pass around an XmlBuilder instead of a Renderable.

Makes sense.

  With XmlWriter you end
> up with two objects, a StringBuilder and an XmlWriter, and you
> can't just forget about one because you need the builder around
> to get your output at the end.

Yes, I do like having some kind of XmlBuffer object.

(I kind of like Renderable but it's a frameworky thing and there's no
reason you can't define your own.)

Hm... that's a bit too opinionated.  Prefix everything with, "Do what
you like, but for what it's worth, "

- Brian

[Webiyo-developers] XmlBuilder checked in

[Jim K. <jki...@gr...>]

OK, as Justin probably already knows, I've already written
an XML-generating class.  I've now checked it into webiyo's
CVS, on the theory that this is the easiest way for us
to compare the two and perhaps even have them share things.

Obvious differences with webiyo's existing XmlWriter are:

1.  Xmlbuilder is simpler, in various ways. =20
No AttributeSource, AttributeSink, TagType, etc.

2.  It builds in memory rather than sending to an Appendable.
Although the Appendable is the more general solution, and
you can always think of a use case where you don't want to
store the entire XML document in memory, generating web pages
is not one of those use cases, and I really like the ability
to pass around an XmlBuilder instead of a Renderable.  See
XmlBuilder#append(XmlBuilder builder) or=20
XmlBuilderTest#testCompose for that.  With XmlWriter you end
up with two objects, a StringBuilder and an XmlWriter, and you
can't just forget about one because you need the builder around
to get your output at the end.

3.  XmlWriter can insert newlines for you.  XmlBuilder is still
at the stage of either do without, or call .newline().  The
XmlWriter feature is handy, of course the catch is that it
requires knowledge of the schema (e.g. that this is HTML).

4.  XmlBuilder has comments.  XmlWriter has DOCTYPE and <?xml
declarations (not necessarily a good thing, but that could
easily be a whole 'nother flamewar and I could see catering
to callers of different religions on this).

5.  I think XmlBuilder has a few more error-check cases.  But
I didn't do a test-by-test comparison (and perhaps the best
way would be just to hook up one test to the other class,
and vice versa).

Anyway, this message is long already but the options include
(a) factor HtmlWriter, or some replacement, to call XmlBuilder,
(b) add XmlBuilder features into XmlWriter and remove the former,
(c) let them coexist and see what comes of it, (d) etc.  The biggest
obstacle to any kind of unification might be the streaming thing
(#2 above).

Re: [Webiyo-developers] Failing tests

[Justin T. S. <ju...@kr...>]

Howdy,

Sure enough, most of the failing tests were due to silly Windows
differences: different line endings, different file path separator
character, executables end with .exe... Also, it appears
dir.listFiles() may return null; I wonder if it returns an empty array
on Linux. I've fixed all those issues, hopefully in a way that lets
the tests still work on Linux as well. I also added a mechanism that
suppresses the 'cvs log' call in the tests that don't actually care
about it. That left just a single failing test,
ProjectTest.testLoadChangeLog, the one test that *does* care about the
'cvs log' output. (I don't have command-line CVS installed.) So I've
suppressed that test when running on Windows (it will still run on
Linux).

Cheers,
Justin

Re: [Webiyo-developers] Failing tests

[Tony F. <to...@ta...>]

Thanks for the reply, Brian!

I did build the project, ignoring the tests, and all appears to work 
well. I've added a bunch of new tags and attributes and they are seem to 
be working correctly. I run this by William when he gets back to see 
what he thinks.

I'll include my modified Html.java file with this message in case you'd 
like to add it to the project. I've tried to add as many valid tags and 
attributes that I could from the Html DTD.

Thanks!

Tony



Brian Slesinsky wrote:
> Hi Tony,
> 
> I hate to say it, but if you're pressed for time, you might be better
> off ignoring the example code and its tests.  Adding new HTML tags and
> attributes should be fairly straightforward and the tests in the
> example package have little to do with what you're working on.
> 
> In retrospect, the way I did unit testing was not so great. 
> Everything in the "example" package is actually testing sample code,
> some of which is fairly tricky (including rendering the Webiyo
> website), and the core Webiyo library is only being tested indirectly.
> 
> If you do want to look into it:
> 
> I suspect the Linux failures have to do with CVS.  As part of building
> the Webiyo website, the code runs "cvs log" to generate a changelog. 
> There are also tests that start up another java process, just because
> there's no way to change the current directory from inside Java.  So
> you might get a failure if the java or cvs commands aren't in your
> path.
> 
> It looks like I never enabled logging of the individual test failures
> in the junit task in the ant build file, so that's probably your first
> step.  That will give us a better idea of what's going on.  Or run
> them from your IDE if you know how to do that.
> 
> I've never tried building on Windows so it's unsurprising that you've
> discovered problems there.  Hopefully they won't be too hard to fix. 
> (I have access to a Windows box here and maybe I'll get to it.)
> 
> - Brian
> 
> On 12/20/05, Tony Fardella <to...@ta...> wrote:
>> Hi,
>>
>> I've been working with William on a project that uses Webiyo. I'm
>> finally getting around to posting my problem as he suggested long ago.
>>
>> I would like to add support for more HTML tags and attributes that I
>> need for the project but I'm having problems getting the tests to pass
>> when building the project. Since this project has a Windows desktop
>> component my preference it to work on my Windows system. There are about
>> 10 tests that fail. Most of these look like they're related to building
>> the Webiyo site. I also tried building under Linux without luck (though
>> a few more tests passed).
>>
>> If this is related to tests related to building the Webiyo website is
>> there a directory structure that needs to be setup to make this work?
>> Alternatively, is there an easy way to separate the website tests from
>> the rest of the tests?
>>
>> Thanks!
>>
>> Tony Fardella
>> to...@ta...
>>
>>
>> Below are the test results for Windows and Linux.
>>
>>
>> Windows Build Results
>> ---------------------
>> [junit unit tests] Running org.webiyo.examples.cheese.CheeseTest
>> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
>> 0.015 sec
>> [junit unit tests] Test org.webiyo.examples.cheese.CheeseTest FAILED
>> [junit unit tests] Running org.webiyo.examples.hello.HelloTest
>> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
>> 0.016 sec
>> [junit unit tests] Test org.webiyo.examples.hello.HelloTest FAILED
>> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogPageTest
>> [junit unit tests] Tests run: 3, Failures: 0, Errors: 3, Time elapsed:
>> 0.125 sec
>> [junit unit tests] Test
>> org.webiyo.examples.sourceforge.ChangeLogPageTest FAILED
>> [junit unit tests] Running
>> org.webiyo.examples.sourceforge.ChangeLogReaderTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.047 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.047 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.HomePageTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 1, Time elapsed:
>> 0.187 sec
>> [junit unit tests] Test org.webiyo.examples.sourceforge.HomePageTest FAILED
>> [junit unit tests] Running org.webiyo.examples.sourceforge.NewsTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.141 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.ProjectTest
>> [junit unit tests] Tests run: 2, Failures: 0, Errors: 1, Time elapsed:
>> 0.031 sec
>> [junit unit tests] Test org.webiyo.examples.sourceforge.ProjectTest FAILED
>> [junit unit tests] Running org.webiyo.examples.sourceforge.PublishWebiyoTest
>> [junit unit tests] Tests run: 2, Failures: 1, Errors: 1, Time elapsed:
>> 0.235 sec
>> [junit unit tests] Test
>> org.webiyo.examples.sourceforge.PublishWebiyoTest FAILED
>> [junit unit tests] Running
>> org.webiyo.examples.sourceforge.ViewSourcePageTest
>> [junit unit tests] Tests run: 2, Failures: 2, Errors: 0, Time elapsed:
>> 0.016 sec
>> [junit unit tests] Test
>> org.webiyo.examples.sourceforge.ViewSourcePageTest FAILED
>> [junit unit tests] Running org.webiyo.examples.viewjava.LexerTest
>> [junit unit tests] Tests run: 3, Failures: 0, Errors: 0, Time elapsed:
>> 0.016 sec
>> [junit unit tests] Running org.webiyo.examples.viewjava.SourceIndexTest
>> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
>> 0.016 sec
>> [junit unit tests] Test org.webiyo.examples.viewjava.SourceIndexTest FAILED
>> [junit unit tests] Running org.webiyo.examples.viewjava.SourceTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.031 sec
>> [junit unit tests] Running org.webiyo.examples.viewjava.SourceViewTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.188 sec
>> [junit unit tests] Running org.webiyo.examples.viewjava.ViewJavaTest
>> [junit unit tests] Tests run: 2, Failures: 0, Errors: 2, Time elapsed:
>> 0.156 sec
>> [junit unit tests] Test org.webiyo.examples.viewjava.ViewJavaTest FAILED
>> [junit unit tests] Running org.webiyo.util.MultiMapTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 sec
>> [junit unit tests] Running org.webiyo.util.test.dtds.ResolverTest
>> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
>> 0.063 sec
>> [junit unit tests] Test org.webiyo.util.test.dtds.ResolverTest FAILED
>> [junit unit tests] Running org.webiyo.web.LinkTest
>> [junit unit tests] Tests run: 11, Failures: 0, Errors: 0, Time elapsed:
>> 0.015 sec
>> [junit unit tests] Running org.webiyo.web.LocationTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.016 sec
>> [junit unit tests] Running org.webiyo.xml.XmlWriterTest
>> [junit unit tests] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
>> 0.078 sec
>>
>>
>> Linux Build Results
>> ---------------------------------------
>> [junit unit tests] Running org.webiyo.examples.cheese.CheeseTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 2.441 sec
>> [junit unit tests] Running org.webiyo.examples.hello.HelloTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.4 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogPageTest
>> [junit unit tests] Tests run: 3, Failures: 0, Errors: 3, Time elapsed:
>> 0.308 sec
>> [junit unit tests] Test
>> org.webiyo.examples.sourceforge.ChangeLogPageTest FAILED
>> [junit unit tests] Running
>> org.webiyo.examples.sourceforge.ChangeLogReaderTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.134 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.15 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.HomePageTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 1, Time elapsed:
>> 0.639 sec
>> [junit unit tests] Test org.webiyo.examples.sourceforge.HomePageTest FAILED
>> [junit unit tests] Running org.webiyo.examples.sourceforge.NewsTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.57 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.ProjectTest
>> [junit unit tests] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
>> 0.893 sec
>> [junit unit tests] Running org.webiyo.examples.sourceforge.PublishWebiyoTest
>> [junit unit tests] Tests run: 2, Failures: 1, Errors: 0, Time elapsed:
>> 9.575 sec
>> [junit unit tests] Test
>> org.webiyo.examples.sourceforge.PublishWebiyoTest FAILED
>> [junit unit tests] Running
>> org.webiyo.examples.sourceforge.ViewSourcePageTest
>> [junit unit tests] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
>> 2.806 sec
>> [junit unit tests] Running org.webiyo.examples.viewjava.LexerTest
>> [junit unit tests] Tests run: 3, Failures: 0, Errors: 0, Time elapsed:
>> 0.031 sec
>> [junit unit tests] Running org.webiyo.examples.viewjava.SourceIndexTest
>> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
>> 0.064 sec
>> [junit unit tests] Test org.webiyo.examples.viewjava.SourceIndexTest FAILED
>> [junit unit tests] Running org.webiyo.examples.viewjava.SourceTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.052 sec
>> [junit unit tests] Running org.webiyo.examples.viewjava.SourceViewTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.671 sec
>> [junit unit tests] Running org.webiyo.examples.viewjava.ViewJavaTest
>> [junit unit tests] Tests run: 2, Failures: 1, Errors: 0, Time elapsed:
>> 2.654 sec
>> [junit unit tests] Test org.webiyo.examples.viewjava.ViewJavaTest FAILED
>> [junit unit tests] Running org.webiyo.util.MultiMapTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.015 sec
>> [junit unit tests] Running org.webiyo.util.test.dtds.ResolverTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.219 sec
>> [junit unit tests] Running org.webiyo.web.LinkTest
>> [junit unit tests] Tests run: 11, Failures: 0, Errors: 0, Time elapsed:
>> 0.05 sec
>> [junit unit tests] Running org.webiyo.web.LocationTest
>> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
>> 0.033 sec
>> [junit unit tests] Running org.webiyo.xml.XmlWriterTest
>> [junit unit tests] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
>> 0.273 sec
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> webiyo-developers mailing list
>> web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webiyo-developers
>>
>>
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> webiyo-developers mailing list
> web...@li...
> https://lists.sourceforge.net/lists/listinfo/webiyo-developers

Re: [Webiyo-developers] Failing tests

[Brian S. <br...@sl...>]

Hi Tony,

I hate to say it, but if you're pressed for time, you might be better
off ignoring the example code and its tests.  Adding new HTML tags and
attributes should be fairly straightforward and the tests in the
example package have little to do with what you're working on.

In retrospect, the way I did unit testing was not so great.=20
Everything in the "example" package is actually testing sample code,
some of which is fairly tricky (including rendering the Webiyo
website), and the core Webiyo library is only being tested indirectly.

If you do want to look into it:

I suspect the Linux failures have to do with CVS.  As part of building
the Webiyo website, the code runs "cvs log" to generate a changelog.=20
There are also tests that start up another java process, just because
there's no way to change the current directory from inside Java.  So
you might get a failure if the java or cvs commands aren't in your
path.

It looks like I never enabled logging of the individual test failures
in the junit task in the ant build file, so that's probably your first
step.  That will give us a better idea of what's going on.  Or run
them from your IDE if you know how to do that.

I've never tried building on Windows so it's unsurprising that you've
discovered problems there.  Hopefully they won't be too hard to fix.=20
(I have access to a Windows box here and maybe I'll get to it.)

- Brian

On 12/20/05, Tony Fardella <to...@ta...> wrote:
> Hi,
>
> I've been working with William on a project that uses Webiyo. I'm
> finally getting around to posting my problem as he suggested long ago.
>
> I would like to add support for more HTML tags and attributes that I
> need for the project but I'm having problems getting the tests to pass
> when building the project. Since this project has a Windows desktop
> component my preference it to work on my Windows system. There are about
> 10 tests that fail. Most of these look like they're related to building
> the Webiyo site. I also tried building under Linux without luck (though
> a few more tests passed).
>
> If this is related to tests related to building the Webiyo website is
> there a directory structure that needs to be setup to make this work?
> Alternatively, is there an easy way to separate the website tests from
> the rest of the tests?
>
> Thanks!
>
> Tony Fardella
> to...@ta...
>
>
> Below are the test results for Windows and Linux.
>
>
> Windows Build Results
> ---------------------
> [junit unit tests] Running org.webiyo.examples.cheese.CheeseTest
> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
> 0.015 sec
> [junit unit tests] Test org.webiyo.examples.cheese.CheeseTest FAILED
> [junit unit tests] Running org.webiyo.examples.hello.HelloTest
> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
> 0.016 sec
> [junit unit tests] Test org.webiyo.examples.hello.HelloTest FAILED
> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogPageT=
est
> [junit unit tests] Tests run: 3, Failures: 0, Errors: 3, Time elapsed:
> 0.125 sec
> [junit unit tests] Test
> org.webiyo.examples.sourceforge.ChangeLogPageTest FAILED
> [junit unit tests] Running
> org.webiyo.examples.sourceforge.ChangeLogReaderTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.047 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.047 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.HomePageTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 1, Time elapsed:
> 0.187 sec
> [junit unit tests] Test org.webiyo.examples.sourceforge.HomePageTest FAIL=
ED
> [junit unit tests] Running org.webiyo.examples.sourceforge.NewsTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.141 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.ProjectTest
> [junit unit tests] Tests run: 2, Failures: 0, Errors: 1, Time elapsed:
> 0.031 sec
> [junit unit tests] Test org.webiyo.examples.sourceforge.ProjectTest FAILE=
D
> [junit unit tests] Running org.webiyo.examples.sourceforge.PublishWebiyoT=
est
> [junit unit tests] Tests run: 2, Failures: 1, Errors: 1, Time elapsed:
> 0.235 sec
> [junit unit tests] Test
> org.webiyo.examples.sourceforge.PublishWebiyoTest FAILED
> [junit unit tests] Running
> org.webiyo.examples.sourceforge.ViewSourcePageTest
> [junit unit tests] Tests run: 2, Failures: 2, Errors: 0, Time elapsed:
> 0.016 sec
> [junit unit tests] Test
> org.webiyo.examples.sourceforge.ViewSourcePageTest FAILED
> [junit unit tests] Running org.webiyo.examples.viewjava.LexerTest
> [junit unit tests] Tests run: 3, Failures: 0, Errors: 0, Time elapsed:
> 0.016 sec
> [junit unit tests] Running org.webiyo.examples.viewjava.SourceIndexTest
> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
> 0.016 sec
> [junit unit tests] Test org.webiyo.examples.viewjava.SourceIndexTest FAIL=
ED
> [junit unit tests] Running org.webiyo.examples.viewjava.SourceTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.031 sec
> [junit unit tests] Running org.webiyo.examples.viewjava.SourceViewTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.188 sec
> [junit unit tests] Running org.webiyo.examples.viewjava.ViewJavaTest
> [junit unit tests] Tests run: 2, Failures: 0, Errors: 2, Time elapsed:
> 0.156 sec
> [junit unit tests] Test org.webiyo.examples.viewjava.ViewJavaTest FAILED
> [junit unit tests] Running org.webiyo.util.MultiMapTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 =
sec
> [junit unit tests] Running org.webiyo.util.test.dtds.ResolverTest
> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
> 0.063 sec
> [junit unit tests] Test org.webiyo.util.test.dtds.ResolverTest FAILED
> [junit unit tests] Running org.webiyo.web.LinkTest
> [junit unit tests] Tests run: 11, Failures: 0, Errors: 0, Time elapsed:
> 0.015 sec
> [junit unit tests] Running org.webiyo.web.LocationTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.016 sec
> [junit unit tests] Running org.webiyo.xml.XmlWriterTest
> [junit unit tests] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
> 0.078 sec
>
>
> Linux Build Results
> ---------------------------------------
> [junit unit tests] Running org.webiyo.examples.cheese.CheeseTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 2.441 sec
> [junit unit tests] Running org.webiyo.examples.hello.HelloTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.4 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogPageT=
est
> [junit unit tests] Tests run: 3, Failures: 0, Errors: 3, Time elapsed:
> 0.308 sec
> [junit unit tests] Test
> org.webiyo.examples.sourceforge.ChangeLogPageTest FAILED
> [junit unit tests] Running
> org.webiyo.examples.sourceforge.ChangeLogReaderTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.134 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.15 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.HomePageTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 1, Time elapsed:
> 0.639 sec
> [junit unit tests] Test org.webiyo.examples.sourceforge.HomePageTest FAIL=
ED
> [junit unit tests] Running org.webiyo.examples.sourceforge.NewsTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.57 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.ProjectTest
> [junit unit tests] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
> 0.893 sec
> [junit unit tests] Running org.webiyo.examples.sourceforge.PublishWebiyoT=
est
> [junit unit tests] Tests run: 2, Failures: 1, Errors: 0, Time elapsed:
> 9.575 sec
> [junit unit tests] Test
> org.webiyo.examples.sourceforge.PublishWebiyoTest FAILED
> [junit unit tests] Running
> org.webiyo.examples.sourceforge.ViewSourcePageTest
> [junit unit tests] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
> 2.806 sec
> [junit unit tests] Running org.webiyo.examples.viewjava.LexerTest
> [junit unit tests] Tests run: 3, Failures: 0, Errors: 0, Time elapsed:
> 0.031 sec
> [junit unit tests] Running org.webiyo.examples.viewjava.SourceIndexTest
> [junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed:
> 0.064 sec
> [junit unit tests] Test org.webiyo.examples.viewjava.SourceIndexTest FAIL=
ED
> [junit unit tests] Running org.webiyo.examples.viewjava.SourceTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.052 sec
> [junit unit tests] Running org.webiyo.examples.viewjava.SourceViewTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.671 sec
> [junit unit tests] Running org.webiyo.examples.viewjava.ViewJavaTest
> [junit unit tests] Tests run: 2, Failures: 1, Errors: 0, Time elapsed:
> 2.654 sec
> [junit unit tests] Test org.webiyo.examples.viewjava.ViewJavaTest FAILED
> [junit unit tests] Running org.webiyo.util.MultiMapTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.015 sec
> [junit unit tests] Running org.webiyo.util.test.dtds.ResolverTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.219 sec
> [junit unit tests] Running org.webiyo.web.LinkTest
> [junit unit tests] Tests run: 11, Failures: 0, Errors: 0, Time elapsed:
> 0.05 sec
> [junit unit tests] Running org.webiyo.web.LocationTest
> [junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.033 sec
> [junit unit tests] Running org.webiyo.xml.XmlWriterTest
> [junit unit tests] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
> 0.273 sec
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> webiyo-developers mailing list
> web...@li...
> https://lists.sourceforge.net/lists/listinfo/webiyo-developers
>
>

[Webiyo-developers] Failing tests

[Tony F. <to...@ta...>]

Hi,

I've been working with William on a project that uses Webiyo. I'm 
finally getting around to posting my problem as he suggested long ago.

I would like to add support for more HTML tags and attributes that I 
need for the project but I'm having problems getting the tests to pass 
when building the project. Since this project has a Windows desktop 
component my preference it to work on my Windows system. There are about 
10 tests that fail. Most of these look like they're related to building 
the Webiyo site. I also tried building under Linux without luck (though 
a few more tests passed).

If this is related to tests related to building the Webiyo website is 
there a directory structure that needs to be setup to make this work? 
Alternatively, is there an easy way to separate the website tests from 
the rest of the tests?

Thanks!

Tony Fardella
to...@ta...


Below are the test results for Windows and Linux.


Windows Build Results
---------------------
[junit unit tests] Running org.webiyo.examples.cheese.CheeseTest
[junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 
0.015 sec
[junit unit tests] Test org.webiyo.examples.cheese.CheeseTest FAILED
[junit unit tests] Running org.webiyo.examples.hello.HelloTest
[junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 
0.016 sec
[junit unit tests] Test org.webiyo.examples.hello.HelloTest FAILED
[junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogPageTest
[junit unit tests] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 
0.125 sec
[junit unit tests] Test 
org.webiyo.examples.sourceforge.ChangeLogPageTest FAILED
[junit unit tests] Running 
org.webiyo.examples.sourceforge.ChangeLogReaderTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.047 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.047 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.HomePageTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 
0.187 sec
[junit unit tests] Test org.webiyo.examples.sourceforge.HomePageTest FAILED
[junit unit tests] Running org.webiyo.examples.sourceforge.NewsTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.141 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.ProjectTest
[junit unit tests] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 
0.031 sec
[junit unit tests] Test org.webiyo.examples.sourceforge.ProjectTest FAILED
[junit unit tests] Running org.webiyo.examples.sourceforge.PublishWebiyoTest
[junit unit tests] Tests run: 2, Failures: 1, Errors: 1, Time elapsed: 
0.235 sec
[junit unit tests] Test 
org.webiyo.examples.sourceforge.PublishWebiyoTest FAILED
[junit unit tests] Running 
org.webiyo.examples.sourceforge.ViewSourcePageTest
[junit unit tests] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 
0.016 sec
[junit unit tests] Test 
org.webiyo.examples.sourceforge.ViewSourcePageTest FAILED
[junit unit tests] Running org.webiyo.examples.viewjava.LexerTest
[junit unit tests] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 
0.016 sec
[junit unit tests] Running org.webiyo.examples.viewjava.SourceIndexTest
[junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 
0.016 sec
[junit unit tests] Test org.webiyo.examples.viewjava.SourceIndexTest FAILED
[junit unit tests] Running org.webiyo.examples.viewjava.SourceTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.031 sec
[junit unit tests] Running org.webiyo.examples.viewjava.SourceViewTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.188 sec
[junit unit tests] Running org.webiyo.examples.viewjava.ViewJavaTest
[junit unit tests] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 
0.156 sec
[junit unit tests] Test org.webiyo.examples.viewjava.ViewJavaTest FAILED
[junit unit tests] Running org.webiyo.util.MultiMapTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 sec
[junit unit tests] Running org.webiyo.util.test.dtds.ResolverTest
[junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 
0.063 sec
[junit unit tests] Test org.webiyo.util.test.dtds.ResolverTest FAILED
[junit unit tests] Running org.webiyo.web.LinkTest
[junit unit tests] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 
0.015 sec
[junit unit tests] Running org.webiyo.web.LocationTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.016 sec
[junit unit tests] Running org.webiyo.xml.XmlWriterTest
[junit unit tests] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 
0.078 sec


Linux Build Results
---------------------------------------
[junit unit tests] Running org.webiyo.examples.cheese.CheeseTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
2.441 sec
[junit unit tests] Running org.webiyo.examples.hello.HelloTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.4 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogPageTest
[junit unit tests] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 
0.308 sec
[junit unit tests] Test 
org.webiyo.examples.sourceforge.ChangeLogPageTest FAILED
[junit unit tests] Running 
org.webiyo.examples.sourceforge.ChangeLogReaderTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.134 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.ChangeLogTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.15 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.HomePageTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 
0.639 sec
[junit unit tests] Test org.webiyo.examples.sourceforge.HomePageTest FAILED
[junit unit tests] Running org.webiyo.examples.sourceforge.NewsTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.57 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.ProjectTest
[junit unit tests] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 
0.893 sec
[junit unit tests] Running org.webiyo.examples.sourceforge.PublishWebiyoTest
[junit unit tests] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 
9.575 sec
[junit unit tests] Test 
org.webiyo.examples.sourceforge.PublishWebiyoTest FAILED
[junit unit tests] Running 
org.webiyo.examples.sourceforge.ViewSourcePageTest
[junit unit tests] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 
2.806 sec
[junit unit tests] Running org.webiyo.examples.viewjava.LexerTest
[junit unit tests] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 
0.031 sec
[junit unit tests] Running org.webiyo.examples.viewjava.SourceIndexTest
[junit unit tests] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 
0.064 sec
[junit unit tests] Test org.webiyo.examples.viewjava.SourceIndexTest FAILED
[junit unit tests] Running org.webiyo.examples.viewjava.SourceTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.052 sec
[junit unit tests] Running org.webiyo.examples.viewjava.SourceViewTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.671 sec
[junit unit tests] Running org.webiyo.examples.viewjava.ViewJavaTest
[junit unit tests] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 
2.654 sec
[junit unit tests] Test org.webiyo.examples.viewjava.ViewJavaTest FAILED
[junit unit tests] Running org.webiyo.util.MultiMapTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.015 sec
[junit unit tests] Running org.webiyo.util.test.dtds.ResolverTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.219 sec
[junit unit tests] Running org.webiyo.web.LinkTest
[junit unit tests] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 
0.05 sec
[junit unit tests] Running org.webiyo.web.LocationTest
[junit unit tests] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 
0.033 sec
[junit unit tests] Running org.webiyo.xml.XmlWriterTest
[junit unit tests] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 
0.273 sec