1. opensymphony
  2. webwork


tm_jee  committed 162cce5

add wikidocs for webwork 2.2.7 release

git-svn-id: http://svn.opensymphony.com/svn/webwork/trunk@3003573baa09-0c28-0410-bef9-dab3c582ae83

  • Participants
  • Parent commits e4f9cbc
  • Branches master

Comments (0)

Files changed (563)

File docs/wikidocs/06-01-2005 AJAX.html

View file
  • Ignore whitespace
+    <head>
+        <title>WebWork - 
+        06-01-2005 AJAX
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h1><a name="06-01-2005AJAX-Transcript"></a>Transcript</h1>
+<div class="preformatted"><div class="preformattedContent">
+<pre>	PSquad33	my biggest concerns are making sure we don't bite off more than we can chew and that we keep WebWork... WebWork
+	jcarreira	Have you looked at Cameron's stuff?
+	iroughley	what were your thoughts on Camerons checkins?
+	PSquad33	i'm not interested in becoming a vehicle for distributing dojo
+	iroughley	yes
+	jcarreira	I wanted to talk to him about contributing his stuff back to dojo
+	PSquad33	all the javascript widget stuff sounds like it is getting a little too far away from webwork. but still, it is interesting
+	PSquad33	anyway, i'll be on and off
+	iroughley	I like dojo as the transport, but as soon as you get too far into JS I am concerned abouot browser compatibility
+	jcarreira	I like the idea of making the components dojo widgets, but I want the JSP tags to write out the dojo widgets... that way we can maintain server-side state
+	jcarreira	yeah, that's a good reason to put it in dojo... more people using it = more compatibility testing
+	iroughley	exactly
+	PSquad33	are we going to support dojo entirely, or will this be optional stuff? i just don't want to divert focus
+	PSquad33	maybe we should make an seperate project or something. do my concerns make sense?
+	jcarreira	well, I think we should have an Ajax theme
+	iroughley	I like using it as the transport, and the event stuff is good.
+	jcarreira	I don't know... I think it's important to have rich widgets as part of the framework...
+	PSquad33	sure -- but we can't abandon our base either
+	jcarreira	...and they're going to do drag-n-drop, etc.
+	PSquad33	people still use the plain old XHTML theme
+	PSquad33	i want to keep the goals in sync
+	PSquad33	anyway, my big concern is that I feel a bit left out of the loop -- and if I do, our users defintiely will
+	iroughley	I guess my underlying issue with the code that cameron added, was that it had no dependency with webwork
+	PSquad33	so you guys need to really hold my hand on this if you think this is the right direction to go
+	PSquad33	show me the vision in simple to understand terms
+	PSquad33	ian: exactly
+	PSquad33	ian: that is exactly my concern -- we're going to fragment the user base at this rate
+	jcarreira	yeah.. I don't want to get into the biz of maintaining add-ons to dojo
+	iroughley	it could be used with or without webwork, and then we are developing for someone else
+	jcarreira	I wanted to talk to him about contributing the JS stuff back to dojo, and we just use it
+	jcarreira	I've been trying to think through if we need the server-side events too
+	iroughley	so then move in the direction that I think we are going - tag libs around the attributes for the dojo elements
+	jcarreira	yep
+	iroughley	so that we can link into server side state
+	jcarreira	Should we just maintain UI widget dependencies on the client-side?
+	jcarreira	or should we try to implement a real MVC style where the model changes cause the correct view components to update?
+	iroughley	this is a urious question
+	iroughley	i like loose dependencies on the client, via topics
+	iroughley	so far, for what I am doing it works well
+	jcarreira	so the UI components just know to listen to topics and refresh themselves?
+	iroughley	yes
+	jcarreira	in that case it can just be a UI component theme
+	iroughley	the caveat is that the components have a known grnularity, that is understood by the developer
+	iroughley	yes
+	jcarreira	except for the extra JSP attributes
+	iroughley	and changed per theme
+	jcarreira	what do you mean about the granularity?
+	iroughley	you have to know that a remote div (for example) might get a list from the server, or render a domain object
+	jcarreira	I was thinking the remote div would just get HTML and set its innerHtml
+	iroughley	so when you call that div to refresh itself you are doing work to obtain the information
+	jcarreira	that way it's just like a ww:action tag...
+	iroughley	yes
+	iroughley	the action does the work
+	jcarreira	and if you have it like this:
+	jcarreira	&lt;ww:remotediv action="foo"/&gt;
+	jcarreira	actually...
+	jcarreira	this could just be a theme for the ww:action tag...
+	jcarreira	...except it's not a UI tag
+	iroughley	true
+	jcarreira	but it could wrap a ww:action tag and delegate calls to it
+	jcarreira	but maybe that's limiting its reusability
+	jcarreira	&lt;ww:remotediv href="foo.action"&gt;&lt;ww:action name="foo"/&gt;&lt;/ww:remotediv&gt;
+	jcarreira	the contents of the ww:remotediv would be the original content (no need for a separate call to load the content), then the href would be used when it refreshes
+	iroughley	that's a good idea
+	iroughley	i haven't had a chance to implement the initial content yet (as per your suggestion last week)
+	jcarreira	what are the params to the remotediv tag?
+	iroughley	so, i guess that the UI doesn't need to maintain dependencies on the client, just make calls via remote div's (or other components) and let the actions determine the state
+	jcarreira	yeah
+	jcarreira	but we need things like select boxes which can populate
+	|&lt;--	PSquad33 has left efnet (Read error: Connection reset by peer)
+	iroughley	is, url, updateFreq, loadingText, reloadingText, errortext, showErrorTransportText, topicName
+	jcarreira	for example, if I'm shopping and I select a catalog, it should populate the product categories in a select list automatically
+	jcarreira	...I'd also like to be able to have a lazy-loading tree widget
+	iroughley	i agree
+	jcarreira	the loadingText can go away.. just make it the body enclosed by the tag
+	iroughley	that was my plan
+	jcarreira	we need a way to tell it to load immediately... then the default text would be there while it loads the first time
+	iroughley	:)
+	iroughley	my idea exactly
+	iroughley	monday I hope it will be done
+	jcarreira	cool
+	iroughley	could the select tag and tree tag use topics to refresh state from the server
+	jcarreira	what do you mean?
+	iroughley	then use DWR or dojo to obtain JS to refresh themselves
+	jcarreira	ah
+	--&gt;|	PSquad33 (~PSquad32@c-67-160-147-93.hsd1.or.comcast.net) has joined #webwork
+	PSquad33	back
+	PSquad33	sorry about that
+	PSquad33	you guys still talking about stuff
+	jcarreira	but where do they call to get the stuff to refresh themselves?
+	PSquad33	?
+	jcarreira	yep
+	iroughley	yeah
+	jcarreira	you need to bind something to DWR to populate the list, right?
+	iroughley	the data has to be sourced from somewhere originally, right?
+	iroughley	yep
+	jcarreira	yeah... originally it might be in the action
+	iroughley	exactly
+	PSquad33	let me know when you guys are ready to talk strategy. i don't have much to add technically, but i want to make sure we are absolutely clear on our strategy and market perception.
+	jcarreira	would we want to populate the data on the client?
+	iroughley	what do you mean?
+	jcarreira	pre-populate a data structure and select from there...
+	|&lt;--	PSquad33 has left efnet (Remote host closed the connection)
+	iroughley	personally I wouldn't - if you are using ajax the assumption is that the data may change, and should be refreshed from the server
+	iroughley	that doesn;t mean that we shouldn't have a static tree widget
+	jcarreira	I guess I don't know how DWR works... how do you tell it what to call? Can it load data from the session?
+	iroughley	DWR (i think) makes a call to a method on a serverside object - like a spring BO
+	jcarreira	can it access the session to get its data?
+	iroughley	i would think that you could have it access a WW action, and return the session information from there
+	iroughley	i haven't looked at it lately
+	jcarreira	I'm asking Patrick... he keeps getting kicked off
+	iroughley	do you want to try another IRC server?
+	jcarreira	nah, it's his client
+	jcarreira	he's got a cheesy shareware one for mac
+	iroughley	ok - so if anyone changes the select list they update an element in the session - then the select list uses DWR to call an action with a list name (?) which obtains a refreshed (possibly) list from the session
+	jcarreira	I was using an onChange() call... it uses bind() to call and set something into the session
+	iroughley	that would work
+	jcarreira	we need a way to make it easy for users to bind onChange to a call to the server
+	jcarreira	You shouldn't have to write a JS function everytime
+	--&gt;|	PSquad32_ (~chatzilla@c-67-160-147-93.hsd1.or.comcast.net) has joined #webwork
+	PSquad32_	yo yo
+	PSquad32_	chatzilla to the rescue
+	jcarreira	ok, Patrick was just explaining DWR to me
+	iroughley	but it's more complex than that, as it might not be the same element - it may be a different one
+	iroughley	ok
+	jcarreira	no, it shouldn't change anything client-side
+	PSquad32_	so yeah, lemme know when you are ready to talk strategy. dojo doesn't seem to line up with what webwork is about at all, so i'm a bit worried
+	jcarreira	it should make a call to the server, set some session state, then return and send a client-side topic message
+	iroughley	ok - yes
+	jcarreira	it's maybe a little more chatty, but it's simple to understand and model
+	jcarreira	and very loosely coupled
+	iroughley	could we set up each of the UI tags to define whether they send or update, and then wire it up for the users?
+	iroughley	more chatty, but the calls are going to be very small
+	jcarreira	what do you mean?
+	jcarreira	I think each UI component should be able to be given a URL to hit with the new value onChange()
+	jcarreira	and a topic to publish to
+	iroughley	agreed
+	iroughley	so that call will be small (not alot of data in the URL)
+	jcarreira	and also have a topic to listen to that would load the value... so that would need a url to get the list
+	iroughley	yes
+	iroughley	and that call is going to be returning just the list, and not a complete HTML page - do the data being sent back to the client will be small
+	jcarreira	yep.. but in what form does it return the list?
+	jcarreira	...patrick, we're almost done with the Js stuff....
+	iroughley	innerHTML?
+	jcarreira	what does it mean if you set the innerHtml of a select tag? what do you set it to?
+	iroughley	it's easy and whatever is called on the server to get the data out of the session can format it to html
+	iroughley	I would think that any tag can be gotten by id, and then html set in it
+	iroughley	so &lt;OPTION&gt;one&lt;/OPTION&gt; etc.
+	PSquad32_	i'm going to play a game of halo -- be back in a few :)
+	jcarreira	yes, but what do you set into the innerHtml of a select tag to populate it? is it just the &lt;options&gt;?
+	iroughley	i think so
+	iroughley	haven't tried it, but it makes sense
+	jcarreira	ok, so for the tree... it needs to get javascript back, probably, or some data structure... should we support both?
+	Fracture	Hi
+	jcarreira	Hi Fracture...
+	Fracture	i'm going to read the log to catch up
+	iroughley	i think that depends on the core tree widget that we use and augment for the implementation
+	jcarreira	true... I've been playing with dtree for a while... it's pretty easy
+	jcarreira	Fracture, I'm not sure who you are IRL...
+	iroughley	do you think that returning JS or HTML would be easier with dtree?
+	jcarreira	JS
+	iroughley	i think that's fine then - the action/object that obtains the data from the session can modify it to JS to return to the browser
+	jcarreira	This is how I add things to the tree:
+	jcarreira	&lt;ww:iterator value="categories"&gt;
+	jcarreira	tree.add(&lt;ww:property value="id"/&gt;,&lt;ww:property value="(parentCategory == null)?0:parentCategory.id"/&gt;,'&lt;ww:property value="name"/&gt;','javascript:changeCategory(&lt;ww:property value="id"/&gt;);','&lt;ww:property value="name"/&gt;','_top','/img/folder.gif','/img/folderopen.gif');
+	jcarreira	&lt;/ww:iterator&gt;
+	jcarreira	then you add it to the page like this:
+	jcarreira	document.write(tree);
+	iroughley	cool
+	iroughley	we could even use JS for the select - just an implementation detail, as it will be hidden from teh end user
+	jcarreira	but I think we can get to that later... I'm ok hardwiring this one together for now.. but we should make it easy to create components that send changes to the server to update server state and then send update events on topics
+	Fracture	is Cameron :)
+	jcarreira	ahh.. ok...
+	=-=	Fracture is now known as Cameron-
+	jcarreira	Cameron, let us know when you're caught up
+	Cameron-	shall do .. half way there.
+	iroughley	i would agree with that
+	iroughley	while we are handwiring, we should also start thinking about a naming convention for the topics
+	jcarreira	categoryChange, userChange, etc?
+	iroughley	yes - I have been using topic_{html id}_event - i.e. topic_myRemoteDivId_refresh
+	iroughley	but they can easily change
+	jcarreira	I think we should make it easy to type and remember... users will end up needing to do some wiring themselves at some point
+	iroughley	makes sense
+	iroughley	on some of the elements i added a topic to publish to - perhaps I should go ahead and add this to them all
+	jcarreira	where would we be defining topics?
+	iroughley	at the moment I autowire some, and give the user the option of specifying them on some
+	jcarreira	well, we should talk through that with Patrick... how we're going to position this Ajax stuff... if we're going to add attributes to the taglibs, etc.
+	jcarreira	which are autowired?
+	jcarreira	brb
+	iroughley	from memory I think the autowired ones are - remotediv sends a "refesh", tab header sends a "tab selected"
+	iroughley	remote div can specify a topic to listen to and refrsh itself - i think that might be the only one for now
+	Cameron-	ok - I agree that these dojo widgets that I have created really belong in dojo - or a separate project. I was just demonstrating that rather than us write javascript code (that the ww components use) we write them as dojo widgets, and use the components to bind data to them. When using more interactive client controls - webwork more becomes a controller for marshaling data. I do think that we need to bundle a dojo build with w
+	iroughley	oh - the remote link / &lt;a href&gt; is autowired to send a "refresh"
+	Cameron-	and also allow our users to use a different profile build - if they meet our dependencies
+	PSquad32_	cameron: this whole dependency on dojo widgets is very un-webwork-ish
+	PSquad32_	i _really_ think it is not the right direction
+	Cameron-	we depend on DRW, we depend on XmlHttpRequest..
+	Cameron-	we have to have dependencies
+	PSquad32_	but we're depending on a framework
+	PSquad32_	the others are libraries
+	PSquad32_	dojo is a framework
+	PSquad32_	think about it from user's perspective. when they upgrade to 2.2, what are they going to see?
+	PSquad32_	what is the "webwork message"?
+	PSquad32_	what is our story? we can't have 4 different versions of the same story
+	jcarreira	well, that's where we need to decide if this is a theme
+	jcarreira	I think this is the Ajax theme
+	jcarreira	and it requires dojo
+	jcarreira	I think we bundle a dojo profile with the example app
+	PSquad32_	i think that is fine (a lot of this is marketing more than anything)
+	iroughley	are there cases where you might needs to utilize multiple themes for a single compnent?
+	jcarreira	yes
+	iroughley	i.e. 2 different styles of lists or tabbed controls on the same page
+	iroughley	so each of these would then need to be developed from teh core ajax theme
+	jcarreira	sometimes I end up using the "simple" theme because the layout requires I can't put it in the table
+	jcarreira	what do you mean?
+	iroughley	it's late - i think i just confused myself :)
+	jcarreira	what's our status with JSP 2?
+	jcarreira	with JSP 2 you can just add more attributes without having to put them in the TLD, right?
+	PSquad32_	i am fine iwth requiring jsp 2
+	jcarreira	I don't really know the features of JSP 2 :-)
+	jcarreira	but requiring JSP 2 is requiring J2EE 1.4 and J2SE 1.4, right?
+	jcarreira	which means no WebSphere 4.x or 5.0
+	PSquad32_	websphere 5 is JDK 1.4
+	jcarreira	5.1 is
+	iroughley	if that is the case i would opt not to exclude those markets
+	PSquad32_	that's fine
+	PSquad32_	we don't need JSP 2 features
+	PSquad32_	ww:param works
+	PSquad32_	i have to run
+	PSquad32_	let's keep thinking about what the webwork story is -- how all this fits in
+	PSquad32_	we can't just say the old stuff doens't matter or isn't supported
+	Cameron-	so Pat - what is the wework story ?
+	PSquad32_	well, i think we all need to work on that
+	PSquad32_	i'll draft up some thoughts -- maybe you guys can too
+	jcarreira	ok, so if not JSP2, then we need to pull those attributes out and use ww:param to parameterize the tag for this specific theme
+	PSquad32_	my main concern is that you guys understand what i'm saying :)
+	PSquad32_	anyway, i have to run
+	PSquad32_	see ya
+	jcarreira	later
+	Cameron-	bye
+	iroughley	later
+	jcarreira	so if this is going to be a theme, we can't add theme-specific attributes
+	iroughley	for the remote div that cameron added - right?
+	Cameron-	you can - using ww:param no ?
+	jcarreira	right, I mean attributes to the TLD
+	Cameron-	you could probably add optional ones, and document them as 'only used for xxx theme'
+	jcarreira	Hmm... could be.... as long as it's very clear... I don't want to be answering questions about why the topic isn't being used with the xhtml theme
+	Cameron-	true
+	jcarreira	speaking of which, does anyone know if someone actually build a real XHTML theme using div's and CSS instead of tables?
+	jcarreira	built
+	iroughley	no idea
+	Cameron-	no idea
+	iroughley	a while back i thought cloves and pat were talking about doing it
+	Cameron-	yeah - I rememer hearing that.
+	iroughley	so the plan is to move forward with a dojo/ajax theme?
+	jcarreira	yes
+	jcarreira	who wants to take what?
+	Cameron-	with regards to your 'topics' ... are they for use client side .. or do these events get routed to an action too ?
+	jcarreira	Cameron, you're going to talk to the dojo guys about contributing the remote div, remote link, and remote submit stuff to dojo?
+	jcarreira	they're the dojo.event.Topic stuff that lets you do publish/subscribe in JS
+	Cameron-	yep - i'll do that.
+	iroughley	we will also require theme specific tags then, right?
+	Cameron-	so you use topics for inter widget communication ?
+	iroughley	remote div for example
+	jcarreira	I built it as a wrapper around their event stuff
+	iroughley	yes - mainly for server side refreshes at the moment
+	jcarreira	I think let's keep the theme specific attributes for now
+	jcarreira	the idea is for a component to update its server state then publish a message on a topic
+	Cameron-	so something emits an event, a widget is triggered, which then refreshes itself ?
+	Cameron-	sure
+	jcarreira	yep, the developer specifies with the tags which topic(s) a component listens to to refresh itself
+	iroughley	or parts of itself - like the drop down list elements
+	jcarreira	and which topic a component publishes on when it is changed
+	jcarreira	so they are loosely coupled and the developer specifies which thing listens to the others
+	Cameron-	cool.
+	jcarreira	so about dojo and source
+	iroughley	so - there are 3 parts as i see it - 1. the dojo UI widgets, 2. the events/topics, and 3. the WW tag/component that combines them all
+	Cameron-	yep
+	iroughley	go ahead jason
+	jcarreira	should we just bundle the __package__.js?
+	Cameron-	we also need the other 'non bundled' files.. like html templates, css files and other widget resources (gif/jpg)
+	jcarreira	yeah, the tags generate JS to use the dojo widgets and JS to wire them to topics
+	jcarreira	ok
+	jcarreira	where do those come from?
+	Cameron-	I setup an ant target dojo-profile that causes dojo to build a __package__.js and copy it and other non bundled resources into the os/static/dojo package
+	Cameron-	where do those come from ? dunno what you mean
+	jcarreira	Well, I don't know about bundling the sources to dojo into webwork's CVS
+	jcarreira	I think we should just bundle the final built product, like we do with other libraries
+	iroughley	also, if they are in webwork.static, can the end user override the images easily if they wanted?
+	Cameron-	that depends on how the widet is authored
+	Cameron-	authored
+	jcarreira	how does one specify the images to be used?
+	jcarreira	can it be done so that the template could be edited to change where they come from?
+	Cameron-	the widget can take a img= attribute and use it in the building of the rendered widget.
+	iroughley	ok - so it doesn't need to be in ww.static
+	jcarreira	well, the defaults can be
+	Cameron-	doesn't have to be.. however .. defaults may be packaged there
+	iroughley	ok - makes sense
+	jcarreira	ok, so the order of things:
+	jcarreira	1) Cameron, you're going to try to get this stuff into dojo
+	jcarreira	2) we build a profiles of dojo with the widgets
+	jcarreira	3) we edit the JSP templates to use the dojo widgets
+	jcarreira	sound good?
+	jcarreira	anything i'm missing?
+	iroughley	sounds good
+	Cameron-	with the remote div.. why do we need a jsp template ?
+	jcarreira	because we want to wire it to topics
+	Cameron-	why not have a &lt;dojo:topic&gt; widget ?
+	jcarreira	and it can take the body contents as the default content of the div
+	Cameron-	the body content can be done &lt;dojo:remotediv attribs...&gt;&lt;ww:action name='foo'/&gt;&lt;/dojo:remotediv&gt;
+	jcarreira	what would the dojo:topic do?
+	Cameron-	the dojo:topic would 'install' the topic 'bus' into the page
+	jcarreira	well, I'd like to keep things consistent... using ww: tags and auto-wiring them to topics
+	iroughley	can th edojo:topic tag specify the topic to listen to and the topic to publish to when an event ocurrs?
+	iroughley	it's also going to be more code for developers to type
+	jcarreira	&lt;ww:remotediv listenTopic="itemSelected"&gt; creates JS to wire the div to refresh when it gets a message on that topic
+	jcarreira	yeah, we want to make this dead-simple
+	Cameron-	dojo:remotediv listenTopic='itemSelected'&gt; can do the same thing.. without a jsp template
+	jcarreira	...and it doesn't hurt to wrap dojo in case something else comes along and we replace the JS library
+	Cameron-	I think we only need to use a jsp tag when we need to access action context from the tag
+	jcarreira	I don't want to make users know anything about dojo
+	Cameron-	ok.. well. I think we have two different approaches.
+	iroughley	if we don't wrap it, it won't really be a theme - wil it?
+	jcarreira	yeah, the JSP template can just call the dojo stuff, so you can just use the dojo stuff directly, too
+	iroughley	it will be something else to use with ww
+	Cameron-	ok
+	jcarreira	well... maybe we should just make this a ww:div tag
+	iroughley	makes sense
+	jcarreira	and in the Ajax theme it can become a remote div
+	iroughley	then we also need a &lt;ww:a&gt;
+	iroughley	:)
+	jcarreira	yeah... we should do that
+	jcarreira	it can use the URLTag code
+	Cameron-	sounds good
+	jcarreira	ok, Ian, do you want to take those?
+	iroughley	sure
+	jcarreira	cool
+	iroughley	we also need dojo components for the existing elements - remote div, remote a link, tabbed panel - right?
+	jcarreira	yeah... not sure how hard it is to do the tabbed panel... that's a more complicated one
+	iroughley	tonight we also talked about a select list and tree element
+	iroughley	it might be easy - just use &lt;ww:div&gt; and it will just not update - events will be the only issue
+	jcarreira	...and I still want them to build a nice menuing system :-)
+	iroughley	the only other thing I was thinking about is a paginated list
+	jcarreira	let's get the ones we've got now using the new architecture
+	jcarreira	JSP tag -&gt; template -&gt; dojo widget
+	iroughley	cameron - you up for building the dojo components?
+	Cameron-	yeah
+	jcarreira	ok, I'll fill Patrick in with where we're heading and maybe we can schedule another chat to talk about the WebWork message, etc
+	Cameron-	ok
+	iroughley	ok - then I will start on the remote div tag/template from teh dojo component next monday
+	Cameron-	we need a wiki page to list the ajax theme components
+	Cameron-	(so I know what to build)
+	iroughley	let me know as new ones come down the pipe
+	iroughley	the current tutorial list all the ones i've done - localhost/webwork/tutorial/ajax/...
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>

File docs/wikidocs/06-15-2005 Documentation.html

View file
  • Ignore whitespace
+    <head>
+        <title>WebWork - 
+        06-15-2005 Documentation
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h1><a name="06-15-2005Documentation-Attendees"></a>Attendees</h1>
+	<li>Erik Beeson</li>
+	<li>Simon Stewart</li>
+	<li>Jason Carriera</li>
+	<li>Patrick Lightbody</li>
+	<li>Jay Bose</li>
+	<li>Vitor Souza</li>
+	<li>Grégory Joseph</li>
+<h1><a name="06-15-2005Documentation-Outcome"></a>Outcome</h1>
+	<li>Team agrees that the three main guidelines should be:
+	<ul>
+		<li>Documentation and code must be kept in sync</li>
+		<li>Major sections should be focussed on different types of users: tutorials ("getting started"), reference, cookbook, general docs</li>
+		<li>WebWork documentation should be core focus, with XWork documentation being included in the WebWork docs where possible.</li>
+	</ul>
+	</li>
+	<li>Implementation strategies for these guidelines are:
+	<ul>
+		<li>Code/docs sync: utilize the Confluence <a href="http://confluence.atlassian.com/display/CONFEXT/Snippet+Macro+Library" title="Visit page outside Confluence">snippet macro</a>. We may need Atlassian to help get this macro in to shape.</li>
+		<li>Sections: each person in the meeting will write their own TOC and present it next week - see <a href="06-15-2005 TOC Homework.html" title="06-15-2005 TOC Homework">06&#45;15&#45;2005 TOC Homework</a></li>
+		<li>Standaline WebWork docs: we will utilize the {include} macro to include whole XWork pages when possible, but we will avoid linking to the XWork docs.</li>
+	</ul>
+	</li>
+<h1><a name="06-15-2005Documentation-Transcript"></a>Transcript</h1>
+<div class="preformatted"><div class="preformattedContent">
+<pre>	Patrick_	hey
+	shs96c	G;day
+	greg--	hi
+	Patrick_	jason should be on soon i imagine -- just saw him get on AIM
+	shs96c	Fair enough.
+	Patrick_	who do we have here? Rainer, Cameron, and who is Greg?
+	shs96c	I'm Simon
+	greg--	i'm sorry guys I was just passing by; badly need some sleep, it's 3 am here.. just saw the thread and thought i'd drop by
+	greg--	I'm Grégory Joseph
+	--&gt;|	jcarreira (~chatzilla@cpe-66-66-7-68.rochester.res.rr.com) has joined #webwork
+	greg--	being noisy on the lists from time to time
+	shs96c	Not a bad thing :)
+	greg--	sent a couple of patches, and overall happy user of ww ;)
+	Patrick_	ok, cool
+	Patrick_	Greg: get some rest -- we'll post the transcript
+	greg--	thanks ;)
+	Patrick_	unfortunately, I wanted to have a rough TOC for the new docs that we could all start with, but I didn't get around to it
+	greg--	am waiting for a maven build to finish... it's moving at its own pace :/
+	jcarreira	serves you right for using maven :-)
+	Patrick_	Jason: could you maybe take lead on this meeting? I want to finish the build refactoring I've been doing all day. Also, are we waiting for Jay, or do you want to get started?
+	shs96c	I'm happy to wait for Jay
+	jcarreira	let's wait a couple more minutes
+	Patrick_	ok. while we're waiting, i have some good news: the XWork build is the first official project to be based on the OpenSymphony Common Build system
+	Patrick_	WebWork is being updated now. Part of that update involves making sub-projects in WW. The first such subproject will be the example web app
+	shs96c	Patrick: What's the "common build system"?
+	shs96c	Is it in CVS yet?
+	Patrick_	http://ivyrep.opensymphony.com/opensymphony/ is where builds that use the OpenSymphony Common Build drop their artifacts. This allows you to keep up to date if you use Ivy
+	Patrick_	yes, it is
+	Patrick_	let me get you a URL
+	Patrick_	https://xwork.dev.java.net/source/browse/xwork/build.xml?rev=1.30&amp;view=auto&amp;content-type=text/vnd.viewcvs-markup
+	Patrick_	and:
+	Patrick_	https://opensymphony.dev.java.net/source/browse/opensymphony/common/osbuild.xml
+	Patrick_	a couple changes came from this:
+	Patrick_	1) you must have ../opensymphony/common available
+	shs96c	I was just about to ask about that
+	Patrick_	(or you can redefine the location via ${common.build}
+	shs96c	Can it be a jar?
+	shs96c	Or is it the full source tree?
+	Patrick_	it is just an ant build file
+	Patrick_	it can't be a jar
+	Patrick_	2) in XWork, I'm not currently building the editor. I can set this up as a sub project, but I'm not sure if it is even worth it. Is the editor still maintained, or should we focus our energy onConductor/EclipseWork/ etc?
+	--&gt;|	vitorsouz (~vitorsouz@ has joined #webwork
+	shs96c	I've never used the editor, so not too stressed either way
+	vitorsouz	Hi, there. Sorry I'm late.
+	Patrick_	vitor: no worries, we haven't started yet.
+	shs96c	NP
+	Patrick_	Jason: maybe we should start now w/o Jay?
+	vitorsouz	I wasn't sure if Eastern was DST or not. Is it 9:15 or 10:15 there now?
+	Patrick_	it is 9:15 EST
+	shs96c	11:15AM in Sydney. A very civil time to arrange a meeting on IRC for :)
+	vitorsouz	10:15PM in Brazil. Not that different.
+	Patrick_	ok, well let's start
+	Patrick_	i'd like to start off with a couple thoughts, and then i'll open it up
+	jcarreira	oops, back
+	Patrick_	Recently, Matt Raible pointed me to the WebWork 1.0 Release Announcement on TheServerSide
+	Patrick_	more than a couple comments mentioned how good the documentation was
+	jcarreira	LOL
+	shs96c	:)
+	Patrick_	whether it is just PR or reality, the fact is: WebWork suffers from an image of bad documentation
+	shs96c	Agreed
+	Patrick_	the goal should be to fix that for WebWork 2.2
+	jcarreira	yep
+	Patrick_	in order to do that, I think we should establish some general guidelines, and then once we agree on those, put together a TOC and divvy out the work
+	jcarreira	ok
+	vitorsouz	Ok.
+	Patrick_	guidelines might be, for example, that the WebWork docs are "self contained", meaning they don't refer to the XWork docs. Or, they might mean that all example code must be verified to work and reproduced in the example app. Whatever.
+	shs96c	Sounds reasonable
+	Patrick_	I think for this meeting, we should establish those guidelines and put together a rough TOC
+	Patrick_	Jason, anything to add? Otherwise, I'm ready to open it up to discussion of guidelines
+	greg--	(you might want to use the snippet macro for confluence, to make sure sample code in docs matches buildable reality - i.e. extract that code in the doc right out of cvs)
+	jcarreira	well, I'd say another guideline should be that tutorials on the example app should be documented in the doc
+	jcarreira	greg, any idea what happens with that when you export that page?
+	Patrick_	ok, sounds like greg and jason are sort of pointing to the same goal: keep the code and docs in sync
+	jcarreira	will it pull the latest code and include it?
+	greg--	jcarreira: i guess like any macro, it just exports whatever is rendered, i.e. the code as it is on cvs at the moment you export/publish
+	jcarreira	I'd also say I think we need to think about who the audience is and have a couple (at least) sets of docs... like a 5 minute quick start vs. tutorials / example app vs. reference
+	greg--	never verified that myself though
+	shs96c	Jason: the most important docs are those aimed at beginners
+	shs96c	Those are the people who need the most support
+	Patrick_	OK, i'm going to keep a list of ideas being posted here. If I don't summarize it properly, let me know.
+	Patrick_	So far:
+	Patrick_	- Keep docs and code in sync
+	jcarreira	shs96c: well, that's one important set, but a complete and up-to-date reference is important for current users (or even me)
+	Patrick_	- Partition the docs properly: getting started, advanced users, etc
+	shs96c	Agreed, but if there were holes in the docos for advanced users it would be understandable
+	vitorsouz	I think that WW docs should read more like a book, starting with the easy stuff and incrementing gradually, showing examples and explaining. This is the best approach for begginners, I guess.
+	vitorsouz	That's what I tried with the tutorial, a long time ago, and then didn't have the time to improve it (*sigh*).
+	jcarreira	vitor, that's important, but I spend a lot of time on the boards pointing people to the reference on the tags
+	jcarreira	Jay IM'd me and he's having a hard time getting into EFNET
+	vitorsouz	Ok. Reference is also desirable, as well as a cookbook: advanced tasks.
+	vitorsouz	Jason: I got into irc.ca.efnet.info with no problem.
+	shs96c	vitorsouz: sounds like how I'd expect the docs to be structured
+	Patrick_	ok, so i'm hearing needs for: reference, tutorials, getting started, and a cookbook (which is just tips and tricks, right?)
+	vitorsouz	Right. Gettint started and tutorial could be the same thing.
+	Patrick_	what about keeping the docs self-contained by not linking out to XWork?
+	shs96c	A reasonable level of self-containment would be good
+	vitorsouz	Self-contained: I think it's a good idea. Referencing to XWork gives an idea of incompleteness.
+	jcarreira	Well, I agree in general... but maybe we could use the Confluence stuff to pull in parts from XWork?
+	shs96c	Allows people commuting and reading offline to get the most out of it
+	greg--	Patrick_ that's a good point, but on the other you don't want to duplicate stuff.. there's currently some duplication and confusion, for instance with the i18n or validation docs that are both in ww and xw
+	Patrick_	Jason: I agree, if we can find ways to re-use, that is great. But I think the final result should be self-contained
+	shs96c	Perhaps a quick glossing over of some of the important XW topics would be beneficial with links to the official XW docs
+	Patrick_	so, related to that question: do you guys think WebWork docs should get the majority of the focus, with XWork as an afterthought?
+	jcarreira	shs, that doesn't help when we export the docs and include them in the distro
+	vitorsouz	Patrick: yes.
+	shs96c	jcarreira: agreed, but it's enough for someone to keep reading
+	vitorsouz	XWork is more targeted to developers, I guess. They can read the source code. ;)
+	shs96c	Not so sure about that.
+	vitorsouz	(just kidding)
+	shs96c	:P
+	Patrick_	ok, any other guidelines? we have three right now:
+	Patrick_	- Keep docs and code in sync
+	greg--	it would maybe hide xwork even more. as of now, it's not obvious what you do with xw WITHOUT ww, and maybe you guys also want to stress that?
+	Patrick_	- Break up in to main sections: tutorials (getting started, etc), reference, cookbook
+	Patrick_	- WebWork docs core focus, XWork docs not important and kept separate
+	jcarreira	well, I'm not sure about that last one
+	shs96c	I'm with Jason on this one
+	Patrick_	ok, what do you suggest?
+	shs96c	I'd like the XW docs to be "the source of truth" for XW things
+	jcarreira	I think we should look at the ability to keep the XWork docs up to date and use Confluence to include them in WebWork
+	vitorsouz	Here's another option: both XWork and WebWork (and maybe future projects derived from XWork) have the same docs.
+	Patrick_	I agree, but not at the expense of the WebWork documentation experience
+	shs96c	I'd be happy to see some high level discussion of how the XW elements affect WW2 in the WW2 docs
+	--&gt;|	nightfal (~nightfal@c-67-180-134-149.hsd1.ca.comcast.net) has joined #webwork
+	--&gt;|	jaybose (~chatzilla@CPE-65-27-76-47.mn.res.rr.com) has joined #webwork
+	jaybose	sorry i'm late
+	vitorsouz	Welcome Jay and nightfal.
+	Patrick_	Jay, Erik, welcome
+	shs96c	We're talking about documentation
+	jcarreira	ok, guidelines so far:
+	Patrick_	read here to catch up: http://wiki.opensymphony.com/display/WW/Temp+chat
+	Patrick_	let's nail down these three guidelines and then move on the TOC
+	jcarreira	- Keep docs and code in sync
+	jcarreira	to do that let's look at the stuff that pulls from CVS
+	jcarreira	- Break up in to main sections: tutorials (getting started, etc), reference, cookbook
+	jcarreira	I think what we have now is mostly reference, but not so well structured
+	nightfal	I agree
+	greg--	jcarreira : http://confluence.atlassian.com/display/CONFEXT/Snippet+Macro+Library
+	jcarreira	Now the one we're not so much in agreement on: - WebWork docs core focus, XWork docs not important and kept separate
+	shs96c	nod
+	jcarreira	greg, cool.. I'll take a look...
+	shs96c	That's the one I'm feeling a little uncomfortable about
+	Patrick_	well, here's my two concerns:
+	jcarreira	I'd like to keep XWork up to date, and I think Confluence can bring it all together
+	nightfal	obviously it gets tricky because *most* of the use that xwork sees is from webwork, so separating them just confuses new webwork users
+	Patrick_	1) I don't want our focus on XWork docs, since 99% of users will never download XWork
+	shs96c	Except as part of WebWork.
+	shs96c	:)
+	Patrick_	2) I want the WebWork docs to always be correctly "versioned" -- meaning that when you download WebWork 2.2 and the docs point out to XWork, they can't point to the wiki
+	Patrick_	because the wiki would be "latest", not necessarily the docs that we meant to link to at the time 2.2 was released
+	jcarreira	right, agreed
+	shs96c	We could always export the XWork and WebWork spaces together for the WebWork docs
+	jcarreira	greg, do you know the macros to pull in pieces of other pages?
+	jaybose	There are things that would better be explained under the XWork section
+	vitorsouz	What about the idea of both sharing the same docs? I got no comments on the idea (maybe because it's very very bad... :)).
+	Patrick_	I don't want users to get fragemented in to thinking about XWork and WebWork. I want them to download WebWork and just use it. That means I don't want them to have to read an XWork Reference and a WebWork Reference
+	Patrick_	vitor: i don't like that for the reasons above
+	shs96c	Then we're heading towards Vitor's idea....
+	nightfal	I agree that separate is poor
+	nightfal	is exporting both sets of docs for the ww dist an option?
+	Patrick_	I'm open to finding a way to include parts of the XWork docs in the WebWork docs via Confluence. But the end result would be *standalone* WebWork docs when exported
+	jcarreira	yeah, I think what makes sense is to pull in the parts of the xwork docs that are needed and add to them in the corresponding webwork docs page
+	Patrick_	is everyone else cool with that?
+	nightfal	I'm stepping away for a minute, I just wanted to lurk
+	nightfal	lurks
+	shs96c	Standalone is fine by me, because I like to read offline
+	Patrick_	ok, speak now or forever hold your peace :)
+	Patrick_	going once... twice...
+	jaybose	so the plan is to just reference parts of the Xwork docs?
+	vitorsouz	Wait...
+	Patrick_	waiting :)
+	jaybose	but to keep sep?
+	greg--	jcarreira : you mean {include} i believe ?
+	vitorsouz	What about not mentioning XWork in the Getting Started (Tutorial) and referencing it in the reference and cookbook.
+	vitorsouz	That way begginners wouldn't feel confused.
+	jaybose	i like that idea
+	jcarreira	yes, I think that's a good idea
+	shs96c	Beginners often think of WW2 and XW as one and the same thing...
+	Patrick_	vitor: i'm fine with referencing it as long as the _content_ that is exported appears as a standalone document. The way we would do that is by using {include} (I think)
+	vitorsouz	Ok. I'm fine with include.
+	Patrick_	So, just so we're all absolutely clear, an example of this in action might be:
+	vitorsouz	I'm more concerned with the end result for the reader, because I don't know Confluence and its features that well.
+	Patrick_	XWork/Documentation/Interceptors/Overview might talk about interceptors in general
+	greg--	i zlso it's better to mention it right away, than letting users discover the existence of xw once they think they're up to speed with ww
+	Patrick_	WebWork/Documentation/Interceptors/Overview might link to WebWork/Documentation/Interceptors/XWorkOverview
+	Patrick_	and then WebWork/Documentation/Interceptors/XWorkOverview would _include_ XWork/Documentation/Interceptors/Overview
+	greg--	mind that {include} includes a complete page, not portions of it
+	vitorsouz	Greg: we could mention it in the begginning of the tutorial, just to let the reader know, but saying they shouldn't worry about it for now.
+	Patrick_	ok. say "wait" in the next 5 seconds or we're moving on
+	greg--	vitorsouz true :)
+	jcarreira	link?
+	vitorsouz	I'm cool with that last resolution.
+	jcarreira	you mean it links now and now we want to make it include?
+	greg--	jcarreira http://docs.codehaus.org/renderer/notationhelp.action?section=confluence ?
+	Patrick_	ok, great. so now the next step is TOC -- or maybe more specifically, how do we implement these gaols.
+	Patrick_	let's start with the first one:
+	Patrick_	it appears that Simon and Jason are on to something that might help
+	Patrick_	what I've been doing is making the example app an actual tutorial, with the tutorials _in_ the app
+	Patrick_	it hasn't turned out too hot so far though :(
+	jcarreira	yes, we need to use the snippet macro... what do we have to do to enable the snippet macro?
+	shs96c	Sounds hard to do nicely
+	jcarreira	well, it just needs the docs written, I think
+	vitorsouz	Patrick: maybe more thought is to be given to which examples are interesting. But that's not the point right now, I guess. The point is the means of syncing, right?
+	jcarreira	the code can't stand alone for someone trying to learn
+	Patrick_	well, wait -- do we need to do te snippet macro? What about just saying that parts of the docs (say, "tutorials") are in the example app and the reference and cookbook are static?
+	Patrick_	or would that fragment things too much b/c then you wouldn't be authoring all the docs in confluence?
+	jcarreira	Hmm... so just do the tutorials completely in the example app?
+	Patrick_	maybe, i'm just tossing out ideas at this point. i don't feel strongly either way
+	vitorsouz	So the tutorial page in confluence would be just a single one, pointing to the example app in the distribution?
+	Patrick_	possibly. would that work?
+	Patrick_	how does {snippet} work?
+	greg--	jcarreira : enabling the snippet macro = dropping the jar in confluence/WEB-INF/lib and praying it works with your confluence version.
+	shs96c	I'm not keen on that idea
+	jaybose	yes, all tutorials via the example app
+	shs96c	Maybe I've grabbed the wrong end of the stick here
+	vitorsouz	I prefer the automatically syncing idea, but not sure it's feasible or easy.
+	shs96c	If we're talking about including snippets from the example app in the tutorials, that's cool
+	jcarreira	the problem there is that to update the tutorial you'd have to be a webwork developer with CVS write access
+	Patrick_	jason: good point
+	greg--	Patrick_ http://confluence.atlassian.com/display/CONFEXT/Snippet+Macro+Library : it grabs contents of your cvs repo through a cvsview, between given markers (like START SNIPPET FOO, END SNIPPET FOO)
+	Patrick_	though, we could provide "Documentation" access to webwork/tutorial in CVS
+	Patrick_	java.net does support that
+	jaybose	is that really necessary?
+	jcarreira	but that only gives access to the /web directory, doesn't it?
+	Patrick_	hmm, the snippet macro looks like it can pull parts of the content. I like it.
+	greg--	Patrick_ it can indeed
+	jaybose	is copy and paste that error-prone?
+	vitorsouz	About the snippet thing: it guarantees automatically updating existing code, but if I write a new code in the example app I have to write a new page for it and use the snippet-tag, is that correct?
+	Patrick_	jason: well, after tonight, webwork/tutorial will have all the source, libs, etc. it'll be it's own project
+	Patrick_	vitor: yes
+	jcarreira	jay, copy and paste doesn't keep things up to date
+	Patrick_	i actually really like the snippet idea
+	Patrick_	what are potential "gotchas" with it?
+	greg--	xml
+	greg--	maybe there's been a new version but last time i tried
+	greg--	few month agos
+	greg--	an xml snippet wouldn't render corretly
+	vitorsouz	I'm thinking that bugs in the snippet tag are the only concern. If it works well, no worries.
+	greg--	i mean, it was readable, but the xml colouring was messed up
+	Patrick_	we could get Atlassian to fix that I bet
+	Patrick_	or even make a copy for ourselves
+	Patrick_	that works :)
+	greg--	hmm it's not maintained by them
+	Patrick_	any other showstoppers? so far i've heard:
+	Patrick_	- new tutorials in CVS will need to have the wiki get updated
+	Patrick_	- snippet macro could be buggy
+	greg--	(mind that maybe with conf1.4 it'd work, they've rewritten the renderer)
+	Patrick_	we're running on 1.4.1
+	greg--	i can't really tell, we're still on 1.3.x at work
+	Patrick_	ok, anything else to say about? any other suggestions? say "wait" in the next 5 seconds or I'll assume we're agreed to use the snippet tag
+	Patrick_	ok, done. (trying to keep this meeting plodding right along)
+	vitorsouz	Right.
+	Patrick_	next up: sections
+	Patrick_	so we've talked about tutorials, reference, and cookbook
+	Patrick_	where would something like the general description of WW's architecture go?
+	jaybose	what goes in the three
+	Patrick_	three?
+	jaybose	we need guidelines for that
+	jaybose	three sections.
+	Patrick_	i'm not following
+	Patrick_	you mean it would be in the cookbook?
+	jaybose	ok, what would go in the cookbook, and not in the tutorials
+	vitorsouz	I think the docs should start with general information and architecture. Then explain the three sections above: Tutorials for new users, Reference for quick ref and Cookbook for advanced users looking for advanced ideas.
+	Patrick_	well, i see tutorials as things like:
+	jcarreira	the tutorials are really 2 sections: getting started and tutorials
+	shs96c	Things like injecting services into validators using Spring....\
+	Patrick_	- Getting Started, Using Validation, etc
+	Patrick_	the cookbook would b emore like:
+	Patrick_	- How to override the default XHTML templates
+	Patrick_	- Writing your own ServletDispatcher
+	Patrick_	etc
+	vitorsouz	I see the tutorials as something that starts with installation and "Hello, World" and slowly increment things until we have a complete but simple example app.
+	jaybose	getting started should be part of the ref manula
+	shs96c	vitorsouz: I like that idea
+	Patrick_	see, i think we're missing something: general documentation
+	jcarreira	yeah
+	Patrick_	i think we need a "setting up webwork" in the general docs
+	Patrick_	and then in the tutorials, a "getting started"
+	Patrick_	there is a difference:
+	jcarreira	ok docs:
+	Patrick_	in "setting up webwork", you're told what configs are needed, files, etc
+	Patrick_	in "getting started", it is a step by step hand-holding guide
+	vitorsouz	Gettint Started is in the tutorials, Setting up WebWork is in the reference.
+	jcarreira	let's start at the top level and then break each one down
+	jcarreira	we need: Getting started (includes a hello world starter app and tutorials)
+	vitorsouz	Just to further explain my point of view, once the user finishes the tutorial he/she could go to the Cookbook and check random advanced ideas, meaning that cookbook "mini-tutorials" do not depend on one another, but depend on know what's in the tutorial.
+	Patrick_	ok, let's look at a couple things:
+	jcarreira	General Documentation: includes architecture guide, what is MVC, reference
+	Patrick_	WebWork 1.x docs: http://www.opensymphony.com/webwork_old/
+	shs96c	Something like: http://wiki.rubyonrails.com/rails/show/UnderstandingRails
+	shs96c	?
+	Patrick_	WebWork 2.x docs: http://www.opensymphony.com/webwork/wikidocs/Documentation.html
+	[ERROR]	Connection to irc://efnet/ (irc://irc.prison.net/) reset.
+	=-=	User mode for Patrick__ is now +i
+	--&gt;|	YOU (Patrick__) have joined #webwork
+	|&lt;--	Patrick_ has left efnet (Read error 54: Connection reset by peer)
+	Patrick__	sorry, got booted
+	=-=	YOU are now known as Patrick_
+	Patrick_	ok, looking at our existing TOC, i think we're not too far from where we want to be
+	Patrick_	I think the real problem is this:
+	vitorsouz	"Understanding Rails" is nice.
+	Patrick_	http://www.opensymphony.com/webwork/wikidocs/Interceptors.html
+	Patrick_	you click on Interceptors
+	Patrick_	but now you can't get any useful info on the "prepare" interceptor, for example
+	Patrick_	http://www.opensymphony.com/webwork/wikidocs/ExecuteAndWaitInterceptor.html is what we need to aim for for every reference page
+	Patrick_	something more detailed
+	Patrick_	notice that XW has more info on some of the items:
+	Patrick_	http://wiki.opensymphony.com//display/XW/Interceptors
+	Patrick_	ok, it's getting late for everyone, I think we should wrap this up rather than letting this go on for another hour. can someone volunteer to write a new TOC that at least shows examples of drilling down to the details needed in the reference?
+	jcarreira	Yes, some of the WebWork pages for interceptors may ONLY have an include of the XWork page
+	vitorsouz	Sorry to return to the XWork/WebWork docs issue, in this case, we would have a XWork Interceptors section including XWork docs and then a WebWork-specific Interceptors section with WW stuff?
+	greg--	i'll be the 1st to leave - darn .. 4pm :d
+	jcarreira	ok, thanks for the help greg!
+	greg--	ur welcome :)
+	Patrick_	vitor: there would be a page, for example, in WebWork called PrepareInterceptor
+	greg--	bye everyone
+	|&lt;--	greg-- has left efnet ()
+	Patrick_	and it may simply just include XWork's PrepareInterceptor page
+	Patrick_	the key is that it includes it rather than linking to it
+	|&lt;--	jaybose has left efnet (Ping timeout: no data for 247 seconds)
+	vitorsouz	Hmmmm... Ok.
+	Patrick_	we have to be careful about links in the XWork docs though
+	--&gt;|	jaybose_ (~chatzilla@CPE-65-27-76-47.mn.res.rr.com) has joined #webwork
+	=-=	jaybose_ is now known as jaybose
+	Patrick_	however, I think that we can sort of think of these things after the initial docs are there
+	Patrick_	Jay, i'll update the chat log
+	vitorsouz	I'd volunteer to write the TOC, but I'm going out of town tomorrow, only returning Sunday. If you guys don't mind waiting for some time next week...
+	jcarreira	Jay, do you have time to work on the TOC?
+	jaybose	yes
+	jcarreira	Ok, you can put it under the WebWork 2.2 page on the wiki... it doesn't have to link to anything yet
+	Patrick_	http://wiki.opensymphony.com/display/WW/Temp+chat
+	vitorsouz	Seems like some people have different ideas in general for the doc structure, how about we schedule the next meeting and everyone writes a TOC exemplifying his own ideas and sends it to Patrick to put online for discussion?
+	Patrick_	vitor: i like that idea. and those who don't write one don't get as much of a say :)
+	jcarreira	:-)
+	vitorsouz	:)
+	shs96c	:)
+	jcarreira	ok, when are you back from your trip Vitor?
+	vitorsouz	Late saturday night. I could work on this sunday.
+	Patrick_	haha, sounds like we have a winner then. Let's schedule the next meeting time and call it a day
+	shs96c	Same time on Sunday?
+	Patrick_	Sunday is too early
+	shs96c	OK
+	Patrick_	i'd opt for sometime after Tuesday next week.
+	jcarreira	next wed?
+	Patrick_	same time next week?
+	nightfal	Same bat time, same bat channel?
+	shs96c	Fine by me
+	vitorsouz	Alright. Wednesday 9PM Eastern.
+	jcarreira	yep, sounds like a plan
+	nightfal	TOC == Table of Contents, yes?
+	Patrick_	yes
+	vitorsouz	Yes.
+	Patrick_	great! good work guys. this was a perfect meeting too -- 60 minutes and done :)
+	Patrick_	so next week we'll nail down the TOC and divide up responsibilities
+	jcarreira	yep
+	vitorsouz	Okidoki.
+	Patrick_	i'll post the final chat log and send out a note in the forums for people interested
+	Patrick_	see ya. good meeting
+	jcarreira	ok, sounds good
+	|&lt;--	jaybose has left efnet (Chatzilla [Netscape 7.2/20040804])
+	vitorsouz	Good idea. Great work, everyone.
+	jcarreira	later
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>

File docs/wikidocs/06-15-2005 TOC Homework.html

View file
  • Ignore whitespace
+    <head>
+        <title>WebWork - 
+        06-15-2005 TOC Homework
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h1><a name="06-15-2005TOCHomework-DocTeamSuggestions"></a>Doc Team Suggestions</h1>
+<h2><a name="06-15-2005TOCHomework-DocumentationStyle"></a>Documentation Style</h2>
+<p><a href="Style Guide.html" title="Style Guide">Click here</a> for the suggestions on documentation style.</p>
+<h2><a name="06-15-2005TOCHomework-Documentation%3A"></a>Documentation:</h2>
+<p>One-paragraph description of what is WebWork. And then, an explanation of how the documentation is divided:</p>
+<p><cite>If you're new to WebWork, please read the <b>Overview</b> and proceed to the <b>Tutorial</b> to get started. Experienced users can refer to the <b>Cookbook</b> for advanced topics. Use the <b>Reference</b> on an as-needed basis for more specific details. For detailed information about WebWork project, read the section <b>Project Information</b>. Information about many projects related to WebWork can be found in <b>Related Projects</b></cite></p>
+<p><cite>If you have any questions, you can ask them at the user forum/mailing list. Please be sure to read the <b>FAQ</b> before asking any questions.</cite></p>
+	<li>Overview</li>
+	<li>Project Information</li>
+	<li>FAQ</li>
+	<li>Tutorial</li>
+	<li>Cookbook</li>
+	<li>Reference</li>
+	<li>Related Projects</li>
+<p><em>(details on each of the above follows)</em></p>
+<h3><a name="06-15-2005TOCHomework-Overview"></a>Overview</h3>
+	<li>What is WebWork</li>
+	<li>Comparison to Struts (Tapestry, JSF, etc.?) &#8211; <em>current material and links to existing articles</em></li>
+	<li>Articles and press about WebWork</li>
+	<li>Projects using WebWork / Testimonials</li>
+<h3><a name="06-15-2005TOCHomework-ProjectInformation"></a>Project Information</h3>
+	<li>License</li>
+	<li>Deployment notes</li>
+	<li>WebWork versions
+	<ul>
+		<li>Current release</li>
+		<li>Previous releases</li>
+		<li>Migrating from WebWork 1.x;</li>
+	</ul>
+	</li>
+	<li>Dependencies</li>
+	<li>WebWork Team</li>
+	<li>WebWork community
+	<ul>
+		<li>Mailing lists / Forum</li>
+		<li>Bug tracker</li>
+		<li>Wiki</li>
+		<li>How to contribute?</li>
+	</ul>
+	</li>
+<h3><a name="06-15-2005TOCHomework-FAQ"></a>FAQ</h3>
+	<li>Category 1</li>
+	<li>Category 2</li>
+	<li>Etc.</li>
+<p><em>The questions included in the FAQ should be extracted from the User Forum/Mailing List. Someone could review recent messages and find out which questions are asked the most. After that, separate the questions into categories to form the subsections.</em></p>
+<h3><a name="06-15-2005TOCHomework-Tutorial"></a>Tutorial</h3>
+	<li>Downloading and installing WebWork</li>
+	<li>Setting up the test environment (to test tutorial source code)</li>
+	<li>Basic configuration and your first action (Hello WebWorld)</li>
+	<li>Understanding actions</li>
+	<li>Understanding results</li>
+	<li>Meet WebWork tag library <em>(would also explain a little bit of OGNL)</em></li>
+	<li>Evaluating other view options: Velocity</li>
+	<li>Evaluating other view options: FreeMarker</li>
+	<li>Understanding interceptors</li>
+	<li>Performing validation</li>
+	<li>Performing dependency injection (IoC) through components</li>
+	<li>Going i18n (internationalization)</li>
+	<li>Retrieving data without a full request using XHR/Ajax</li>
+<p><em>This should be in conformance to Patrick's example app. Vitor will talk to Patrick to get his opinions on the sequence of lessons suggested above and how to make the tutorial conformant to the example app.</em></p>
+<h3><a name="06-15-2005TOCHomework-Cookbook"></a>Cookbook</h3>
+	<li>Tips and tricks on Application Servers <em>(this was in "Overview")</em></li>
+	<li>Stuff from the current <a href="Cookbook.html" title="Cookbook">Cookbook</a>...</li>
+<p><em>All the tips in the <a href="Cookbook.html" title="Cookbook">Cookbook</a> should be revised. Some of them could belong to the tutorial instead (basic stuff). 3rd party integration tips could be separated from the rest. Also, it would be good if all of them also followed the same structure, kind of like a tutorial lesson, but on advanced topics. The differences between the Tutorial and the Cookbook would be:</em></p>
+<table class='confluenceTable'><tbody>
+<th class='confluenceTh'>&nbsp;</th>
+<th class='confluenceTh'> Tutorial </th>
+<th class='confluenceTh'> Cookbook </th>
+<td class='confluenceTd'> User level required: </td>
+<td class='confluenceTd'> Begginner </td>
+<td class='confluenceTd'> Intermediate </td>
+<td class='confluenceTd'> Availability of Source code: </td>
+<td class='confluenceTd'> In the documentation and in the <tt>src</tt> folder of the distribution (ready for deploy and test). </td>
+<td class='confluenceTd'> Only in the documentation, and may not be <em>complete</em>. </td>
+<td class='confluenceTd'> Should be read in sequence? </td>
+<td class='confluenceTd'> Yes. </td>
+<td class='confluenceTd'> No. </td>
+<p><em>A question that arised in the TOC discussion was: what's the difference between the Cookbook and the FAQ? Well, some of the items in the Cookbook are also FAQs (people ask about them a lot), so they would also be included in the FAQ, with links to the Cookbook. The FAQ should have quick answers or link to longer answers, such as the Cookbook. The Cookbook is tutorial-style, a collection of mini HOW-TOs.</em></p>
+<h3><a name="06-15-2005TOCHomework-Reference"></a>Reference</h3>
+	<li>Introduction &#8211; <em>This will have parts of Overview in it, rather than forwarding them to Overview altogether.</em></li>
+	<li>Architecture</li>
+	<li>Configuration</li>
+	<li>Interceptors</li>
+	<li>Action Chaining</li>
+	<li>IOC / Dependency Injection</li>
+	<li>UI Components - JSP, Velocity, Freemarker, JavaScript validation and DWR support</li>
+	<li>Result Types</li>
+	<li>Type Conversion</li>
+	<li>Validation</li>
+	<li>OGNL / Object Graph Navigation Language</li>
+	<li>Internationalization</li>
+	<li>3rd Party Integration - Sitemesh, Spring, Pico, Hibernate, JUnit, Quartz, etc.</li>
+<p><em>An important thing about the reference is that it should be written in book-style (or hibernate-reference-style) so a PDF version would be generated and people could print it, pass it around the office or read it while working out or relaxing in bed. <img class="emoticon" src="./icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/> Therefore, Confluence's PDF features play a big part in this. Some questions that came up during the discussions:</em></p>
+	<li><em>The reference could link to other pages in some situations. Links in confluence do not reference URLs, but the page's names. Does Confluence convert them to the URL before writing the PDF? If not, should the Reference not link to any pages outside it?</em></li>
+	<li><em>Can we select which pages are converted into PDF? If we want to convert only the Reference to PDF, can we do that? How does that work?</em></li>
+<h3><a name="06-15-2005TOCHomework-RelatedProjects"></a>Related Projects</h3>
+	<li>WebFlow (graphical chart tool)</li>
+	<li>EclipseWork (Eclipse Plugin)</li>
+	<li>IDEA Plugin</li>
+	<li>WebWork Optional</li>
+	<li>Etc. ?</li>
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>

File docs/wikidocs/07-04-2005 Documentation.html

View file
  • Ignore whitespace
+    <head>
+        <title>WebWork - 
+        07-04-2005 Documentation
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h1><a name="07-04-2005Documentation-Attendees"></a>Attendees</h1>
+	<li>Vitor Souza</li>
+	<li>Jay Bose</li>
+	<li>Alexandru</li>
+<h1><a name="07-04-2005Documentation-Outcome"></a>Outcome</h1>
+<p>Look to this updated page: <a href="http://wiki.opensymphony.com/pages/viewpage.action?pageId=4795" title="Visit page outside Confluence">http://wiki.opensymphony.com/pages/viewpage.action?pageId=4795</a></p>
+<h1><a name="07-04-2005Documentation-Transcript"></a>Transcript</h1>
+<div class="preformatted"><div class="preformattedContent">
+<pre>[7/4/2005 5:17 PM] &lt;jaybose&gt; forget it, i am.
+[7/4/2005 5:17 PM] &lt;the_mind&gt; what do you mean by recording?
+[7/4/2005 5:17 PM] &lt;jaybose&gt; logging
+[7/4/2005 5:17 PM] &lt;jaybose&gt; so others can view it lat4er
+[7/4/2005 5:18 PM] &lt;the_mind&gt; i thought i can copy and paste it :"&gt;
+[7/4/2005 5:18 PM] &lt;jaybose&gt; you can do that too
+[7/4/2005 5:18 PM] &lt;jaybose&gt; :-)
+[7/4/2005 5:18 PM] &lt;jaybose&gt; hey, did you read his page?
+[7/4/2005 5:18 PM] &lt;the_mind&gt; sorry to ask: who are you nightfal?
+[7/4/2005 5:18 PM] &lt;the_mind&gt; whose page?
+[7/4/2005 5:20 PM] &lt;jaybose&gt; Vitor made a page: http://wiki.opensymphony.com/pages/viewpage.action?pageId=4795
+[7/4/2005 5:20 PM] &lt;jaybose&gt; that's what we'll be working off of
+[7/4/2005 5:20 PM] &lt;jaybose&gt; the main purpose of this meeting is to nail down a TOC
+[7/4/2005 5:20 PM] &lt;the_mind&gt; yep... i just wanted to see if anything else comes out
+[7/4/2005 5:20 PM] &lt;jaybose&gt; and then get the dev team in general to clear it
+[7/4/2005 5:21 PM] &lt;jaybose&gt; dev team really meaning Patrick and Jason
+[7/4/2005 5:21 PM] --&gt;| vitor (c91d085c@chat.efnet.org) has joined #webwork
+[7/4/2005 5:21 PM] &lt;jaybose&gt; hey Vitor
+[7/4/2005 5:21 PM] &lt;jaybose&gt; ready to go?
+[7/4/2005 5:22 PM] &lt;the_mind&gt; from my pov yes (... almost falling asleep :-( )
+[7/4/2005 5:22 PM] &lt;jaybose&gt; haha
+[7/4/2005 5:22 PM] &lt;vitor&gt; Hey. Sorry, I'm struggling with this webchat.
+[7/4/2005 5:22 PM] &lt;jaybose&gt; np
+[7/4/2005 5:23 PM] --&gt;| vitorsouz (~vircuser@ has joined #webwork
+[7/4/2005 5:23 PM] &lt;vitorsouz&gt; This is much better. Using vIRC now.
+[7/4/2005 5:23 PM] |&lt;-- vitor has left efnet (Remote host closed the connection)
+[7/4/2005 5:23 PM] &lt;vitorsouz&gt; Don't know what happened. mIRC couldn't connect. I even got a D-Lined message! ouch!
+[7/4/2005 5:23 PM] &lt;jaybose&gt; hmm
+[7/4/2005 5:23 PM] &lt;vitorsouz&gt; Sorry for this big mess... Ready to go now.
+[7/4/2005 5:24 PM] &lt;jaybose&gt; ok, cool
+[7/4/2005 5:24 PM] &lt;jaybose&gt; umm forst off
+[7/4/2005 5:24 PM] &lt;jaybose&gt; looking at your page
+[7/4/2005 5:24 PM] &lt;jaybose&gt; we want an overview
+[7/4/2005 5:24 PM] &lt;vitorsouz&gt;  Ok. Let me open it here too
+[7/4/2005 5:25 PM] &lt;vitorsouz&gt; Meaning you want me to explain what I'm thinking?
+[7/4/2005 5:25 PM] &lt;jaybose&gt; kind of, what should the overview way about WW?
+[7/4/2005 5:25 PM] &lt;jaybose&gt; say*
+[7/4/2005 5:26 PM] &lt;jaybose&gt; I noted what WW is, and what it is not
+[7/4/2005 5:26 PM] &lt;vitorsouz&gt; Ok.
+[7/4/2005 5:26 PM] &lt;jaybose&gt; so that would mean a MVS web framework built on XWork
+[7/4/2005 5:26 PM] &lt;jaybose&gt; maybe say waht XWork is brielfy
+[7/4/2005 5:26 PM] &lt;jaybose&gt; MVC*
+[7/4/2005 5:27 PM] &lt;vitorsouz&gt; Good.
+[7/4/2005 5:28 PM] &lt;vitorsouz&gt; I think the overview should briefly describe the software and bring other information that's interesting to people that are thinking of evaluating it.
+[7/4/2005 5:28 PM] &lt;jaybose&gt; like?
+[7/4/2005 5:28 PM] &lt;the_mind&gt; i think that articles and press and testimonials is a very good way to introduce WW
+[7/4/2005 5:28 PM] &lt;vitorsouz&gt; So I placed: what is WebWork (could include what it is not), comparison to Struts and others, something about the community, articles and testimonials.
+[7/4/2005 5:29 PM] &lt;jaybose&gt; ok
+[7/4/2005 5:29 PM] &lt;the_mind&gt; a comparison to other solution cannot be very detailed so the user may be lost already
+[7/4/2005 5:29 PM] &lt;vitorsouz&gt; It should not teach WW to anyone. That's the reference and the tutorial's jobs.
+[7/4/2005 5:29 PM] &lt;jaybose&gt; great.
+[7/4/2005 5:29 PM] &lt;vitorsouz&gt; themind: I think the reference is for experienced users only.
+[7/4/2005 5:29 PM] &lt;vitorsouz&gt; I mean, comparison.
+[7/4/2005 5:29 PM] &lt;vitorsouz&gt; The comparison is for experienced users. People that know another framework.
+[7/4/2005 5:30 PM] &lt;the_mind&gt; yep but you want this put into the overview
+[7/4/2005 5:30 PM] &lt;jaybose&gt; evaluators will find a comparison helpful
+[7/4/2005 5:30 PM] &lt;vitorsouz&gt; It's a section of the overview. I don't think the overview is meant for sequential reading.
+[7/4/2005 5:30 PM] &lt;the_mind&gt; if i am a new user i would like to read this from an independent way... so pointing to articles
+[7/4/2005 5:30 PM] &lt;jaybose&gt; and they will definitely look in the overview.
+[7/4/2005 5:31 PM] &lt;vitorsouz&gt; We could call it an "Appendix" of the overview, to stress that it's not essential for the newbie. But I'm not sure this is really needed.
+[7/4/2005 5:32 PM] &lt;the_mind&gt; moreover spending time to do a full cycle comparison - when these are already available is no use... just my 2c
+[7/4/2005 5:32 PM] &lt;vitorsouz&gt; You're right about that: it should be mostly pointers to other people's evaluations, eg. Matt Raible's.
+[7/4/2005 5:32 PM] &lt;jaybose&gt; we already have one
+[7/4/2005 5:32 PM] &lt;jaybose&gt; it
+[7/4/2005 5:32 PM] &lt;jaybose&gt; it's a matter of placement
+[7/4/2005 5:33 PM] &lt;the_mind&gt; excellent vitor
+[7/4/2005 5:33 PM] &lt;vitorsouz&gt; That's another thing: the developers already wrote technical differences between WW and Struts.
+[7/4/2005 5:33 PM] &lt;vitorsouz&gt; So we would place that there and pointers to other articles.
+[7/4/2005 5:33 PM] &lt;the_mind&gt; exactly
+[7/4/2005 5:33 PM] &lt;the_mind&gt; or it can be a part of the FAQ
+[7/4/2005 5:33 PM] &lt;the_mind&gt; i usually see this comparison included in FAQs
+[7/4/2005 5:34 PM] &lt;vitorsouz&gt; Ok. Just so I'm not completely lost in the process here. Are we starting from my suggestions? From Jay's suggestions? How is this discussion working?
+[7/4/2005 5:34 PM] &lt;the_mind&gt; but this is not important for me (the placement)
+[7/4/2005 5:34 PM] &lt;jaybose&gt; I am pulling things from your suggestions
+[7/4/2005 5:34 PM] &lt;vitorsouz&gt; Okay.
+[7/4/2005 5:34 PM] &lt;the_mind&gt; i was reading this http://wiki.opensymphony.com/pages/viewpage.action?pageId=4795
+[7/4/2005 5:35 PM] &lt;the_mind&gt; and commenting around - nothing more :-(
+[7/4/2005 5:35 PM] &lt;vitorsouz&gt; That's alright. Sounds good to me. :)
+[7/4/2005 5:35 PM] &lt;jaybose&gt; Ok, anymore on Overview, or move on to Project Information?
+[7/4/2005 5:35 PM] &lt;vitorsouz&gt; That would be my question, exactly.
+[7/4/2005 5:35 PM] &lt;the_mind&gt; from my pov i can move on
+[7/4/2005 5:36 PM] &lt;jaybose&gt; ok so Prj Info, what do we want in here?
+[7/4/2005 5:36 PM] &lt;vitorsouz&gt; Just to wrap up, then: I'll add "(What WW is not)" to the side of "What is WebWork", just to emphasize.
+[7/4/2005 5:36 PM] &lt;the_mind&gt; quite clear and complete imo
+[7/4/2005 5:37 PM] &lt;jaybose&gt; ehhh
+[7/4/2005 5:37 PM] &lt;jaybose&gt; i'm not for that
+[7/4/2005 5:37 PM] &lt;jaybose&gt; anymore
+[7/4/2005 5:37 PM] &lt;the_mind&gt; go on
+[7/4/2005 5:37 PM] &lt;the_mind&gt; hit it
+[7/4/2005 5:37 PM] &lt;jaybose&gt; let the reader figure it out
+[7/4/2005 5:37 PM] &lt;vitorsouz&gt; Sorry. I'm lost again.
+[7/4/2005 5:37 PM] &lt;vitorsouz&gt; You're not for "What WW is not"?
+[7/4/2005 5:38 PM] &lt;jaybose&gt; by saying it's a web based MVC, that should be enough
+[7/4/2005 5:38 PM] &lt;jaybose&gt; yeah.
+[7/4/2005 5:38 PM] &lt;vitorsouz&gt; Ok.
+[7/4/2005 5:38 PM] &lt;the_mind&gt; i would say about WW what is already said
+[7/4/2005 5:38 PM] &lt;vitorsouz&gt; I'll add a note saying that.
+[7/4/2005 5:38 PM] &lt;the_mind&gt; a MVC based on XWork (a command .... ) and that's it
+[7/4/2005 5:39 PM] &lt;jaybose&gt; I'm taking a bunch of notes, i can add them to the page after the meeting
+[7/4/2005 5:39 PM] &lt;vitorsouz&gt; Ok. That's better than. I won't bother doing it too.
+[7/4/2005 5:39 PM] &lt;jaybose&gt; Project Information: ...