I was thinking about the rant last week by Cedric Beust about Agile
proponents not "getting it", and it occured to me that I've got a real
world example that's bigger than the usual workshop examples and
neither so big that it's out of range for a workshop discussion nor is
it proprietary.
It's also a good example where some anciliary documentation of the
issues in the design space might be quite useful to supplement the
tests and code in the (eventual) implementation.
The issue starts off with a problem I noted in the original FIT
distribution, and which was exascerbated by some features in
FitLibrary. Since I'm the maintainer of the Python FIT port, it's of
some concern to me, although it's an issue with all versions of FIT.
Without further ado, here are the three user stories:
1. The fixture writer should be able to access all files referenced in
table cells by img or link (a) tags. This should work for FileRunner
(batch), FitServer (FitNesse online) and TestRunner (FitNesse batch).
2. The fixture writer should be able to update existing files or
create new files to be referenced in img or link tags in table cells.
This should work for FileRunner, FitServer and TestRunner.
3. The person viewing test results should be able to see files
referenced by img or link tags wherever they occur in the HTML file,
and regardless of whether they were original files or files created or
updated by the fixtures. This should work for FileRunner, FitServer
and TestRunner created test results, and should work regardless of
where the test result is located relative to the original. For
TestRunner created results it should work regardless of whether the
creating FitNesse server is accessable.
In looking at them, it's clear we could break them down further if we
needed to for either estimating or priority reasons. However, I'm
going to go directly to an analysis document. I wrote this originally
to get my head around the environmental issues that had to be dealt
with. It doesn't deal at all with issues of actual design; that is,
classes, API and so forth.
You may need to save this message to disk and look at what follows in
an editor that supports fixed width fonts.
FIT - external file handling for HTML documents
John Roth
2005-11-29
Handling external files in HTML documents is a problem. It's needed
for external CSS style sheets and also for various Fit Library
extensions. It's exascerbated by the differences between FitNesse and
batch.
This proposal centers around the following tabular analysis. The first
two columns involve use of existing and new files by fixtures, the
other two columns involve the use of external files by the source and
result HTML.
The first row is batch, the second row is FitNesse tests executed from
the server. The final two rows are FitNesse TestRunner with either a
local or remote FitNesse server.
The table looks best if displayed with a fixed width font.
Fixtures HTML
Existing Creating Source[5] Result
Batch Relative to Relative to Relative to
Relative to
source HTML result HTML source HTML
Result HTML
[1] [3] [6]
FitServer Access from in FitNesseRoot/ Access from
Access from
Server or fs files directories Server Server
[2] [4] [7]
TestRunner Access from Relative to Access from
Relative to
Local Server or fs result HTML Server
Result HTML
[2] [3] [6]
TestRunner Access from Relative to Access from
Relative to
Remote Server only result HTML Server
Result HTML
[2!] [3] [6]
[1] FireFox has problems with absolute paths. It won't use them unless
you open up serious security holes. IE will display files that FireFox
won't touch.
[2] This could also be accessed by using the path to FitNesseRoot/files
from the installation. However, this doesn't work for TestRunner
execution from a remote server, and it requires that the location
of the FitNesse installation be supplied.
[3] Source directories may not be in the same relative location for
the result HTML. They may not even be accessable if the file is
moved for any reason.
[4] This is the major unsolved problem: the FitNesseRoot/files directory
may not be accessable, and it may be under source control in a
variant version of FitNesse. The security mechanism on the existing
request to store a file makes its use difficult / impossible from FIT.
[5] Properly formed HTML should be able to display in any browser.
However, if the HTML is moved, it may no longer be displayable.
[6] Source files must be moved to somewhere they can be accessed. This
is the second major problem: the files must be located in the source
HTML, copied to a result directory, and the HTML must be changed to
reflect this.
[7] This works transparently as long as [4] is solved.
Design notes.
[1] is fairly easy: just temporarily change the current directory
when accessing the file.
[2] requires that the file be accessed using an HTTP request. All
the factors should be present since the file is being executed
from the FitNesse server anyway. Files are accessed the same
way a browser would do it.
[3] seems to require creating an auxiliary directory for each
output file and putting the result files in there. Then the
directory can be moved with the HTML file. There are ways of
making this easy under Windows, and I think there may be a neat
solution on Mac S X (I'm not a Mac expert) but otherwise it's
going to be two pieces to keep track of.
[4] The only really clean solution is some way of communicating
the new file directly to FitNesse and having it store it in
the appropriate place. possibility is a new responder
that would handle the security issues, another is an extension
to the communication protocol so that FIT could send files
back.
[6] The additional issue here is a parse issue - we need to be
able to reliably locate the files and rewrite the URLs after
moving them.
John Roth
Python FIT
To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com
To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*To visit your group on the web, go to:
<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com
<*Your use of Yahoo! Groups is subject to:

Looking at what came through Yahoo's message destruction
process, the HTML version is unreadable both in email and
on the web version. The text portion in the mail
is _almost_ fine except that it's been wrapped at 72
characters which makes it a bit of a pain to read.

I'm putting it in the file section. The name is:

Fit-ExternalFileHandling.txt

John Roth

Message
From: "jhrothjr" <yahoogroups.at.jhrothjr.com (AT) yahoogroups (DOT) at.jhrothjr.com>
To: "extremeprogramming (AT) yahoogroups (DOT) com"
<@yahoogroups.at.jhrothjr.com>
Sent: Friday, June 16, 2006 10:47 AM
Subject: [XP] Real World Example

I was thinking about the rant last week by Cedric Beust about Agile
proponents not "getting it", and it occured to me that I've got a real
world example that's bigger than the usual workshop examples and
neither so big that it's out of range for a workshop discussion nor is
it proprietary.

It's also a good example where some anciliary documentation of the
issues in the design space might be quite useful to supplement the
tests and code in the (eventual) implementation.

The issue starts off with a problem I noted in the original FIT
distribution, and which was exascerbated by some features in
FitLibrary. Since I'm the maintainer of the Python FIT port, it's of
some concern to me, although it's an issue with all versions of FIT.

Without further ado, here are the three user stories:

1. The fixture writer should be able to access all files referenced in
table cells by img or link (a) tags. This should work for FileRunner
(batch), FitServer (FitNesse online) and TestRunner (FitNesse batch).

2. The fixture writer should be able to update existing files or
create new files to be referenced in img or link tags in table cells.
This should work for FileRunner, FitServer and TestRunner.

3. The person viewing test results should be able to see files
referenced by img or link tags wherever they occur in the HTML file,
and regardless of whether they were original files or files created or
updated by the fixtures. This should work for FileRunner, FitServer
and TestRunner created test results, and should work regardless of
where the test result is located relative to the original. For
TestRunner created results it should work regardless of whether the
creating FitNesse server is accessable.

In looking at them, it's clear we could break them down further if we
needed to for either estimating or priority reasons. However, I'm
going to go directly to an analysis document. I wrote this originally
to get my head around the environmental issues that had to be dealt
with. It doesn't deal at all with issues of actual design; that is,
classes, API and so forth.

You may need to save this message to disk and look at what follows in
an editor that supports fixed width fonts.

FIT - external file handling for HTML documents
John Roth
2005-11-29

Handling external files in HTML documents is a problem. It's needed
for external CSS style sheets and also for various Fit Library
extensions. It's exascerbated by the differences between FitNesse and
batch.

This proposal centers around the following tabular analysis. The first
two columns involve use of existing and new files by fixtures, the
other two columns involve the use of external files by the source and
result HTML.

The first row is batch, the second row is FitNesse tests executed from
the server. The final two rows are FitNesse TestRunner with either a
local or remote FitNesse server.

The table looks best if displayed with a fixed width font.

Fixtures HTML
Existing Creating Source[5] Result

Batch Relative to Relative to Relative to
Relative to
source HTML result HTML source HTML
Result HTML
[1] [3] [6]

FitServer Access from in FitNesseRoot/ Access from
Access from
Server or fs files directories Server Server
[2] [4] [7]

TestRunner Access from Relative to Access from
Relative to
Local Server or fs result HTML Server
Result HTML
[2] [3] [6]

TestRunner Access from Relative to Access from
Relative to
Remote Server only result HTML Server
Result HTML
[2!] [3] [6]

[1] FireFox has problems with absolute paths. It won't use them unless
you open up serious security holes. IE will display files that FireFox
won't touch.

[2] This could also be accessed by using the path to FitNesseRoot/files
from the installation. However, this doesn't work for TestRunner
execution from a remote server, and it requires that the location
of the FitNesse installation be supplied.

[3] Source directories may not be in the same relative location for
the result HTML. They may not even be accessable if the file is
moved for any reason.

[4] This is the major unsolved problem: the FitNesseRoot/files directory
may not be accessable, and it may be under source control in a
variant version of FitNesse. The security mechanism on the existing
request to store a file makes its use difficult / impossible from FIT.

[5] Properly formed HTML should be able to display in any browser.
However, if the HTML is moved, it may no longer be displayable.

[6] Source files must be moved to somewhere they can be accessed. This
is the second major problem: the files must be located in the source
HTML, copied to a result directory, and the HTML must be changed to
reflect this.

[7] This works transparently as long as [4] is solved.

Design notes.

[1] is fairly easy: just temporarily change the current directory
when accessing the file.

[2] requires that the file be accessed using an HTTP request. All
the factors should be present since the file is being executed
from the FitNesse server anyway. Files are accessed the same
way a browser would do it.

[3] seems to require creating an auxiliary directory for each
output file and putting the result files in there. Then the
directory can be moved with the HTML file. There are ways of
making this easy under Windows, and I think there may be a neat
solution on Mac S X (I'm not a Mac expert) but otherwise it's
going to be two pieces to keep track of.

[4] The only really clean solution is some way of communicating
the new file directly to FitNesse and having it store it in
the appropriate place. possibility is a new responder
that would handle the security issues, another is an extension
to the communication protocol so that FIT could send files
back.

[6] The additional issue here is a parse issue - we need to be
able to reliably locate the files and rewrite the URLs after
moving them.

John Roth
Python FIT

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to: