xmlwiki-developers Mailing List for xmlWiki (Page 6)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

http://c2.com/cgi/wiki?TestDrivenProgramming
http://extremeprogramming.org/rules/functionaltests.html
http://extremeprogramming.org/rules/testfirst.html
http://c2.com/cgi/wiki?CodeUnitTestFirst

Test

When a page is loaded the user is presented with a well formed XHTML
document that contains a wiki page. This page must have the following
links that provide the basic functionality of the page :

A Title that leads to a links to a search engine that provides a list of
all pages where the title is referenced.

An Edit Text link that directs the user to the Edit form

-----------

For all test the automation can be done using :

HttpUnit
http://httpunit.sourceforge.net/

It is up to the developers to write the acceptance test.

We all follow Test First Design (TFD) 
http://c2.com/cgi/wiki?TestFirstDesign

so have fun coding. We haven't done the CRC session but that is OK. The 
goal here is to have some of the functional tests framework done or at 
least thought about by the time we do the CRC session and to get you 
familiar with the testing framework. One quick way of doing this is 
spiking you story. Remember Write Test, Code, Run Test.

-H

Test

When a user clicks on the Save button in the Preview page then the 
content of the page is saved in XML document.

----------------------

Test

The user is shown the page with the new edits.

The user is given the option of re-editing the page by going to the edit 
  theme page.

The user can go ahead and save the current edits.

---------------------------------

Test

A user is redirected to the Edit Theme/Page from any page that is 
browsable and that has a unlinked and syntatically correct wikiName.

----------------------

Test

Only authenticated users may access this page.

The user is able to enter text, wiki notation and other markup into a form.

This form must be linked to a preview of the page.

The page will not go to preview if the the text edited is not well formed.

--------------------------

http://www.cetus-links.org/oo_ooa_ood_methods.html#oo_methods_crc

Class : XmlWikiServlet

Responsobilites :

Be the main entry point to the application via HTTP by implementing the 
GET and POST http calls to the application.

Checks that the users is authenticated and if not then redirects the 
user to the login/authentication mechanism.

Redirect the control flow to the appropiate wiki function requested by 
the authenticated user.

Collaborators :

?????

---------------------

When a page is loaded the user is presented with a well formed XHTML 
document that contains a wiki page. This page must have the following 
links that provide the basic functionality of the page :

A Title that leads to a links to a search engine that provides a list of 
  all pages where the title is referenced.

An Edit Text link that directs the user to the Edit form.

-----------------

> --- Jim Kalafut <ka...@ie...> wrote:

>>
>>Tomcat - The main reason I recommended 3.2.3 is simplicity on the part of
>>linux.  To move to 4.0 will require significant effort on my part which may
>>not result in a more useful platform (for the project, that is).  The
>>problem is that 4.0 comes only as source and RPM, not Debian packages.  To
>>build the source requires a later version of java than the standard Debian
>>package.  Getting THAT to run requires getting libstdc++ libraries working
>>at the right version,... and on it goes.  A lot of companies customize
>>things for Redhat these days instead of linux in general.  The important
>>question is (and I can't answer is), will we need to make use of the newer
>>API features? If so, I have no problem with biting the bullet and getting it
>>all going.  If not, I'd rather devote my time to coding as opposed to
>>installing right now.  Though I'm surprised I'm saying this, it's
>>unfortunate that the setup isn't as convenient as Windows (ie. download and
>>go).

The big problem with Tomcat 3.2.3 is that is comes with the wrong versions of jars for doing the XSLT that we will be doing.

This is the fix for it :

1) Remove jaxp.jar and parser.jar form the $TOMCAT_HOME/lib directory.
2) Install the following files from the JAXP 1.1 distribution into the $TOMCAT_HOME/lib directory: jaxp.jar, crimson.jar, and xalan.jar.

BUT IF

elhugo@gump:~$ java -version
java version "1.1.8"
elhugo@gump:~$ 

then we really have problems...

1) You have to install the support for collections.
2) Some of the tools that we will use such as Ant and Junit may not work  properly. (Something to be tested especially Junit)
3) This version of Java is really, really, really slow.
4) Dealing with the $CLASSPATH is a problem since there is no /ext.
4) a lot of other stuff that is too long to mention.

Did you do the Sun JDK download? I noticed /tmp/jdk1.3.1_01/ and ran the bin. :(

Did you try the blackdown dist?

ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/JDK-1.3.1/i386/FCS/README-j2re
but be aware that :

3) Under i386, should I download glibc or libc5?

   The glibc stands for GNU C Library, and corresponds to newer
   systems such as RedHat 5.x and Debian 2.x, which are based on
   "libc6." Check with your Linux distribution's documentation to 
   be sure. 

   As of the JDK-1.2, libc5 is no longer officially support by the
   blackdown JDK. It is suggested you install an out of the box 
   solution, such as Redhat 6.1. Please visit the FAQ at 
   http://www.blackdown.org for more information. 

see : 

ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/README.ftp

IF blackdown works then I wonder if you could use the bin dist of Tomcat  4.0? see:

http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.1/

OR

you could compile Tomcat 4.0 from scratch.

ALSO 

IF blackdown works then you don't have to compile or istall J2EE on the linux. All you need is to install the correct servlet.jar in $JAVA_HOME/jre/lib/ext

-H

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Everyone

If you have any suggestions about the objects that we are going to use I 
would like to request that you reformat them in CRC notation.

-H

Hey

I figure we can do the CRC session on Wend and start doing the real code.

-H

Hey gang

Now that the realese plan is done. The next step is to break down the 
user stories into enginering tasks and to the plan for the first 
iteration. (Monday)

http://www.extremeprogramming.org/rules/iterationplanning.html

http://c2.com/cgi/wiki?EngineeringTask

-H

Hey Jim:

How do you plan to do the tracking?

http://www.extremeprogramming.org/rules/velocity.html

-H

Tomcat - The main reason I recommended 3.2.3 is simplicity on the part of
linux.  To move to 4.0 will require significant effort on my part which may
not result in a more useful platform (for the project, that is).  The
problem is that 4.0 comes only as source and RPM, not Debian packages.  To
build the source requires a later version of java than the standard Debian
package.  Getting THAT to run requires getting libstdc++ libraries working
at the right version,... and on it goes.  A lot of companies customize
things for Redhat these days instead of linux in general.  The important
question is (and I can't answer is), will we need to make use of the newer
API features? If so, I have no problem with biting the bullet and getting it
all going.  If not, I'd rather devote my time to coding as opposed to
installing right now.  Though I'm surprised I'm saying this, it's
unfortunate that the setup isn't as convenient as Windows (ie. download and
go).

Foundation classes -

> >>WikiPage   -  Encapsulates one page, however that is represented, and
will
> >>be passed around from the database, parser, HTML generator, etc...

> So the responsibility of this class is to get encapsulate the a page.
> Would it be responsible in setting it's own state or would its state be
> set by another entity?

WikiPage objects will have both open an restricted aspects.  The data will
be changeable by the public, but fields like ID and such will be managed
either at construction or by authorized parties (ie a database).  This class
will lean very much toward the data side of the spectrum.  It is almost like
a struct, a but a few methods will probably be involved to keep track of
things like versions, last update time, etc.  I was more interested in
wrapping up a String so we have something more flexible to pass around until
we know exactly what we want.

> >>WikiContext   -  This would be a singleton which would contain common
> >>configuration information.  Users typically call getInstance() on it,
and
> >>then use that object to learn about the environment, policies/setting,
and
> >>get references to other objects.
>
> Which objects interarct with this one?
>
Everyone who wants to know global information.  ie. there will be one WikiDB
for the
system, and WikiContext  would be the class to give it to you.  Any class
that needs to write or read pages will
probably need this.  I would think that future semaphoric concerns might
involve
this class too.

> >>WikiDB  -  Abstracts the database functions.  One would probably call
> >>getLocalDB() on a WikiContext object to get a reference, and then this
> >>class would handle page creation/deletion/retrieval/update.  I would
expect
> >>that most of the functions would be passing WikiPage references.  The
guts
> >>of this class would then attach to a production DB, text file interface,
> >>etc.
> >>
> So, this is the class responsible in managing the connections to the
> page repository? Who would call the getLocalDB()?
>
Yes.  Again the Browse, Edit, Preview classes (many others, probably) would
need a reference
to the main DB interface.

Debbie and I got the basics of those three classes written today.  We'll
finish the comments and
check things into CVS within a couple of days.  As we have it now, anyone
can get a reference
to the database which will let them create, retrieve, and update simple
WikiPage objects by name.
The underlying storage scheme, as implemented by WikiDB, is probably
temporary (it's not portable,
that's for sure), but all of that mess is well out of sight from the users.

Regards,
Jim

> --- Deborah Hinkley <deb...@ho...> wrote:

>>We are working on the create theme. When a clicks on "create" -

So when a user clicks something on a wikiPage that looks like 
ThisIsANewPage? then that user is directed to the edit page.

She us presented with a form where with a textarea where she can add 
content.

>>1) a) Would they create the initial contents of that page in wiki notation, 
>>save it in wikinotation/xml/html?

Well if we stick to standard convention then the user can use XHTML 
and/or wiki notation in creating the page.

>>
>>if that is the case, then the create story requires a wiki translator.

... and a verifier that the XHTML is well formed. Fortunately, we can 
just plug-in JTidy into the picture ( http://lempinen.net/sami/jtidy/ )
which is based upon HTML Tidy ( http://www.w3.org/People/Raggett/tidy/ )

>>
>>   or b) would the user simply specify the format without specifying any 
>>content in the first place? then the page would not need any wiki notation 
>>right off. we could create a form of some sort, then save the content in 
>>html/xml and the user could add content by pressing edit.

no specifying of format but the page would be saved in XML form.

These are my comments.

>>
>>Class   -   Description
>>
>>WikiPage   -  Encapsulates one page, however that is represented, and will
>>be passed around from the database, parser, HTML generator, etc...

So the responsibility of this class is to get encapsulate the a page. 
Would it be responsible in setting it's own state or would its state be 
set by another entity?

>>
>>WikiContext   -  This would be a singleton which would contain common
>>configuration information.  Users typically call getInstance() on it, and
>>then use that object to learn about the environment, policies/setting, and
>>get references to other objects.

Which objects interarct with this one?

>>
>>WikiDB  -  Abstracts the database functions.  One would probably call
>>getLocalDB() on a WikiContext object to get a reference, and then this
>>class would handle page creation/deletion/retrieval/update.  I would expect
>>that most of the functions would be passing WikiPage references.  The guts
>>of this class would then attach to a production DB, text file interface,
>>etc.
>>

So, this is the class responsible in managing the connections to the 
page repository? Who would call the getLocalDB()?

-H

 >>Unit Testing---I've used JUnit and SUnit quite a bit with good 
results, but
 >>for servlet and other web work we'll need something to augment those test
 >>fixtures.  On the Apache site I saw references to both HTTPUnit and
 >>something called 'Cactus', and I wanted to know if anyone has experience
 >>with those or other test setups that accommodate web development.

For unit testing it is best if we use Cactus to unit test ( 
http://jakarta.apache.org/cactus/index.html ) and HTTPUnit for the 
Aceptance Test ( http://httpunit.sourceforge.net/ ). These two tools 
provide for a very robust testing environment.

If you need to learn about unit testing with Junit ( http://junit.org/ ) 
(the framework upon which Cactus is built upon) then I stongly suggest 
that you work your way through the Junit Cookbook at 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm

-H

Hi

Please download Tomcat 4.0.

If you use Tomcat 3.2.3 then you will be out of synch with the latest 
Java 2EE version. Tomcat 3.2.3 uses the Servlet 2.2 and JSP 1.1 
specifications while the J2EE 1.3_01 uses the Servlet 2.3 and JSP 1.2.

-H

this will be my new email address from now on.

please update your address books.

-H

Wow.  That was a long meeting, and we got a lot done.
-We decided to meet twice a week, Mondays and Thursdays, at 8PM CST, =
since we're behind.
-We decided that there would be 2 iterations in each release, but in =
accordance with the XP goal of delivering things to the customer early, =
we're going to try to beat that.
-Developer estimates of user stories:
    -Browse theme - 2 weeks.
    -Edit Theme - 3 weeks.
    -Create Theme - 1 week
    -Preview theme - 1 week
    -Save in a DB Theme - 2 weeks
    -Big Editor Story - 2 weeks
    -Backup Theme - 1 week
    -Security Theme - 1 week
    -International Theme - 4 weeks
-Customer priorities:
    -First Priority - Create, Edit, Preview, Save, Browse
    -Second Priority - Security, Backup, International
    -Third priority - Big Editor
-Temporary Programming Partners:
    -Bola/Arnaldo - Editor Story
    -Chris/Hugo - Browse Story
    -Jim/Deb - Create/Save to text DB
    -Radu/Abe - Preview/Save to a DB
-Items for us all to study:
    -If you can, take a look at some of the open source wikis out there. =
 No particular one that we're going to try to emulate, but we can no =
doubt learn a lot from seeing what's out there.
    -XML
    -XHTML
    -If anyone needs to, HTML
    -Hugo has helped by posting=20
So, we'll meet on Monday.

Any questions, comments, corrections, let me know.

Here are some thoughts I had concerning really basic classes that everyone
will use.  These are just my thoughts, not the result of pair work, so they
are just suggestions at this point.

Class   -   Description

WikiPage   -  Encapsulates one page, however that is represented, and will
be passed around from the database, parser, HTML generator, etc...

WikiContext   -  This would be a singleton which would contain common
configuration information.  Users typically call getInstance() on it, and
then use that object to learn about the environment, policies/setting, and
get references to other objects.

WikiDB  -  Abstracts the database functions.  One would probably call
getLocalDB() on a WikiContext object to get a reference, and then this
class would handle page creation/deletion/retrieval/update.  I would expect
that most of the functions would be passing WikiPage references.  The guts
of this class would then attach to a production DB, text file interface,
etc.

Those are just some ideas, and I think that the Create/Save work will use
all of those concepts.  Let me know if I'm out in right field compared to
your perspectives of the foundation classes.

Unit Testing---I've used JUnit and SUnit quite a bit with good results, but
for servlet and other web work we'll need something to augment those test
fixtures.  On the Apache site I saw references to both HTTPUnit and
something called 'Cactus', and I wanted to know if anyone has experience
with those or other test setups that accommodate web development.

Regards,
Jim Kalafut

I've made progress on a few fronts, though I've been tardy with informing
you all.

1.  You should all have accounts at 24.178.71.65.  Use SSH to connect with
your chosen username, (from last chat, plus 'elhugo') using your username
again as the password (you can change in from the shell prompt without
confusing SSH).  There nothing much of interest there right this second, so
this should be just a proof-of-connectivity.

2.  Tomcat was successfully set up on both my Windows box and on the Linux
side.  The process is simple once you know exactly what to do, but getting
there is a pain (and different between the platforms).  I suggest everybody
download Tomcat 3.2.3 (latest stable version) from www.apache.org and try to
get it running on your own machines.  I can help you get it going if you
have problems.  You'll need something to do your servlet development on, and
then we can put the latest 'public' version of the code on the Linux box for
all to see and evaluate.

3.  Deborah and I met earlier this week to do some programming, though this
more to meet each other (we both live in Peoria), get familiar with Tomcat
and servlets, etc.  We did end up writing a very, very small version of a
wiki though!  It weighs in at 2 files and about 50 total lines, but it lets
you view and edit a single page.  I hope to move it to Linux box before or
around our meeting.  BTW, the choice of a wiki program was just out of
interest and the code doesn't imply any direction for our real project.
Just treat it as a servlet example like Chris requested.

See you at eight!

Regards,
Jim

All,
    Items on the agenda for tonight are:
    - strategies for catching up now that we're behind
    - configuring Tomcat(maybe Hugo can help us if he has any =
experience)
    - getting our accounts on Jim's box( in case we install Tomcat on =
his machine)
    - other open source code's role (or lack of a role) in the project
    - Finalize decisions on a)length of each release, and b) estimates =
for each user story.
    - After this, we should be able to proceed with the release planning =
meeting (http://www.extremeprogramming.org/rules/planninggame.html). =20
    - First iteration planning meeting? =
(http://www.extremeprogramming.org/rules/iterationplanning.html).
    - assigning initial partners for pair programming
--Arnaldo

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (5)	Oct (77)	Nov (48)	Dec (50)
2002	Jan (16)	Feb (10)	Mar (1)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

xmlwiki-developers Mailing List for xmlWiki (Page 6)

xmlwiki-developers — xmlWiki developers list