webwork-user — WebWork users mailing list

[Webwork-user] WebWork and Jive

[Edwin D. <ede...@ja...>]

Folks,
Can anyone jump in on this thread on the Jive Bulletin Board.  They are
talking about WebWork, Struts, etc.  Encourage them to work on WebWork .....
http://209.221.164.135/jive/forums/skins/jivesite/viewThread.jsp?forum=2&thr
ead=662

Regards,
Edwin.

[Webwork-user] WebWork 0.7 - Struts example, input validation

[Rickard <ri...@jb...>]

WebWork 0.7 is available in CVS

I have just uploaded the last pieces of WebWork 0.7 to CVS (SourceForge
FTP is full so I will do the zip upload later).

There is a new ValidationEditorSupport base class available. This is
useful for creating PropertyEditors that perform validation of input
parameters, which can now be *completely externalized from the Actions*.
This is a very important feature. This means that your Actions does not
have to deal with validating the input, even if the input is strings
that should simply conform to some given pattern. Instead you should
create a BeanInfo object that describes what JavaBean PropertyEditors
should be used for each attribute, and then the standard JavaBeans API
will be used to interact with them for validation. If something goes
wrong you can use the ValidationAware interface to get the exceptions,
and as outlined in earlier post the ActionFormSupport base action does
this so that the error messages are available to be used in, for
example, generic JSP controls.

This is also important if you want to reuse Actions in different
projects, where the only difference between the projects are the
requirements on the input parameters (not uncommon scenario). Then, all
you have to do is make a new set of PropertyEditors, and make sure the
BeanInfo about the Action uses them. No changes to the Actions
themselves would be needed.

In addition, the recent Struts example from JavaWorld has been fully
converted to WebWork, and now uses the above validation techniques. The
code is *very* clean and simple, and truly shows how WebWork makes it
effortless to create web apps. Thor (the original author) is in CC of
this post, and it would be great if you could comment on what you think
about the adaptation from an implementation/design point of view.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] jsp:include

[Rickard <ri...@jb...>]

Hi!

Andrius Juozapaitis wrote:
> it seems that jsp:include is a pretty expensive operation, therefore the
> idea of having includable components is nice, but results in heavy runtime
> penalties. any ideas on how to minimize/avoid this (except for having
> everything needed by the page statically linked into it)?

Yes, I noticed this too. I have made an include tag in WebWork, but I'm
not sure if it helps. 

And I think this is the biggest problem with WebWork. From a design
point of view it is just bloody marvellous, but I'm still unsure about
performance. 
Now, when I say "unsure" I mean just that: I don't know what the
performance of it will be. Not good, not bad, just don't know yet.

What about Struts that uses tags? Is that more or less costly?

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] jsp:include

[Andrius J. <an...@li...>]

hi all,

it seems that jsp:include is a pretty expensive operation, therefore the
idea of having includable components is nice, but results in heavy runtime
penalties. any ideas on how to minimize/avoid this (except for having
everything needed by the page statically linked into it)?

regards,
--andrius

Re: [Webwork-user] Name collision

[Rickard <ri...@jb...>]

(Maurice, gotta send emails to webwork-user, not me personally ;-)

"Maurice C . Parker" wrote:
> > I think the above allows arbitrary scoping. And it also allow included
> > pages to refer to any attribute of any property in parent page (without
> > this scoping the child included pages can only refer to attributes in
> > the result!).
> >
> 
> I think that being able to refer to parent pages is *very* important.  I'm glad that this may be coming soon.  Just to clarify, you would be referring to the parent action and not the parent view, right?

Yes. But you can do this today, as we do it all the time with the
generic controls. Of course. But there's no way currently to reference
beans from iterator, property, bean or similar tags.

> > Any flaws with? Pros/cons?
> 
> Would the id parameter do the upward search the same way that the name parameter does today?  If so, we could potentially still have name collisions, this time on the id parameter instead of the name parameter.

The "id" attribute is just a way to place a tag value into the page
context under a name.

E.g.:
<webwork:iterator id="foo">
  <%=pageContext.getAttribute("foo")%>
</webwork>

If you use included pages you need to make sure that the parent page
doesn't use an id name that is going to be overwritten by the child
page.

> Since we are dealing hierarchial data maybe taking a look at some of the XML syntaxes isn't such a bad idea.  Maybe X-Path or XSLT?  These technologies have had to deal with problem already and may have some good ideas.
> 
> The @ syntax is confusing me.  Using the hierarchy below:
> 
> Main.action
>   |
>   +--name
>   +--address (iterator)
>   |   |
>   |   +--name
>   |   +--street
>   |   +--city
>   |
> (main.jsp)
>   |
>   +--Message.action
>   |   |
>   |   +--name
>   |   +--subject
>   |   +--text
>   |   |
>   | (message.jsp)
>   |   |
>   |   +--Message.action
>   |   |   |
>   |   |   +--name
>   |   |   +--subject
>   |   |   +--text
>   |   |   |
>   |   | (message.jsp)
>   |   |   |
>   |   +--Message.action
>   |   |   |   |
>   .   .   .   .
>   .   .   .   .
>   .   .   .   .
> 
> How to I address the name element of the Main.action while using address as an iterator?  This example is the same problem as the original control problem.

You would use "result@name" for Main.name "address@name" for the address
iterator elements (if you use the id="address" attribute on the iterator
tag that is), and so on.

> Inside the Message.action recursion, is it possible to access the parent actions elements?  

Yes. The parent is bound to "parent.result" attribute.

> Inside of these, would it be possible to specify the name on the first address?

Yes, see above.

> Pretty harsh (but hopefully not unfair) examples.  I don't just don't want to see us get locked into a syntax that can't be flexible as the rest of Webwork has so far proven to be.

Same here :-)

Let's think about this some more. Test with more tricky examples, etc.
But so far it seems ok.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

(forw) Re: [Webwork-user] Name collision

[Maurice C . P. <Ma...@Vi...>]

* Rickard Öberg (ri...@jb...) wrote:
> 
> I think the above allows arbitrary scoping. And it also allow included
> pages to refer to any attribute of any property in parent page (without
> this scoping the child included pages can only refer to attributes in
> the result!).
> 

I think that being able to refer to parent pages is *very* important.  I'm glad that this may be coming soon.  Just to clarify, you would be referring to the parent action and not the parent view, right?

> Seems ok.
> 
> Any flaws with? Pros/cons?

Would the id parameter do the upward search the same way that the name parameter does today?  If so, we could potentially still have name collisions, this time on the id parameter instead of the name parameter.

Since we are dealing hierarchial data maybe taking a look at some of the XML syntaxes isn't such a bad idea.  Maybe X-Path or XSLT?  These technologies have had to deal with problem already and may have some good ideas.

The @ syntax is confusing me.  Using the hierarchy below:

Main.action
  |
  +--name
  +--address (iterator)
  |   |
  |   +--name
  |   +--street
  |   +--city
  |
(main.jsp)
  |
  +--Message.action
  |   |
  |   +--name
  |   +--subject
  |   +--text
  |   |
  | (message.jsp)
  |   |
  |   +--Message.action
  |   |   |
  |   |   +--name
  |   |   +--subject
  |   |   +--text
  |   |   |
  |   | (message.jsp)
  |   |   |
  |   +--Message.action
  |   |   |   |
  .   .   .   .
  .   .   .   .
  .   .   .   .


How to I address the name element of the Main.action while using address as an iterator?  This example is the same problem as the original control problem.

Inside the Message.action recursion, is it possible to access the parent actions elements?  Inside of these, would it be possible to specify the name on the first address?

Pretty harsh (but hopefully not unfair) examples.  I don't just don't want to see us get locked into a syntax that can't be flexible as the rest of Webwork has so far proven to be.

Later,

Maurice

Re: [Webwork-user] WebWork vs Struts

[Rickard <ri...@jb...>]

Edwin DeSouza wrote:
> Anyone want to create WebWork example that does the stuff in this Article
> about Struts ?
> http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts_p.html

Done, in CVS :-) (New record I think, WebWork is indeed very efficient
and fast to work with)

The example mapped pretty well to WebWork, and it was especially nice to
see the generic controls in action! Worked perfectly!

One thing that was missing from WebWork was some validation callback
with properties whose values could not be set (string->int conversion
failed for example). I added an IllegalArgumentAware interface which has
"addIllegalArgumentException(field, exception)". If the WebWork
dispatcher gets an IAE from a propertyeditor when it tries to convert
the input string to the property's type, it will be propagated to the
action if IAA is implemented. ActionFormSupport has been changed to
implement this interface, and the default implementation is to add the
IAE message as a field error message (VERY CONVENIENT!). So, if you have
a custom property editor for each property you wont have to do any
validation AT ALL in your action, since the property editor will do the
validation, propagate any error to ActionFormSupport, which in turn will
propagate the error to a generic control. Very very nice.

Is this cool or what? :-)))

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] com.telkel.*

[Rickard <ri...@jb...>]

Hi!

Andrius Juozapaitis wrote:
> afaik com.telkel.* package is no longer in use, maybe it  could be a good
> idea to remove it from cvs?

Yes! And I have tried! But it doesn't seem possible to remove them...
:-( 

I will probably have to notify the SourceForge people to get it away..

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] com.telkel.*

[Andrius J. <an...@li...>]

hi,

afaik com.telkel.* package is no longer in use, maybe it  could be a good
idea to remove it from cvs?

regards,
--andrius

[Webwork-user] i18n example updated, new tags

[Rickard <ri...@jb...>]

All,

The i18n example has been changed. The Shop action has been split into
several smaller actions. The Shop is now a base class. The result is
much easier to read code, and the subclass actions actually doesn't even
import WebWork classes. Neat. 

Two new tags: exists and notexists. They check whether a particular
property is available. This was necessary for the form controls, since
they used ActionFormSupport error messages. It should be possible to use
the plain ActionSupport, but then the controls broke. The exists tag now
checks first if there is a error message list at all before doing that
logic.

Stuff is in CVS. I'm waiting with a new file release.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Update to Template Controls now in CVS

[Rickard <ri...@jb...>]

Hey

"Maurice C . Parker" wrote:
> A new control, selectmap.jsp, has been added.  

R U sure? I can't find it, and FormTest fails. I think you forgot to add
it.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Name collision

[Rickard <ri...@jb...>]

Hi!

"Maurice C . Parker" wrote:
> To try and explain this clearer I will denote jsp params by enclosing them in *'ss.
<snip>

Very good question. How to solve? 

Here's one idea: 
results can be bound to request attributes (by using the "id" tag
attribute). It would be possible to use a scoping notation to explicitly
refer to an entry point:

<webwork:property name="hasBar" id="foo">
  <webwork:property name="xyzzy:hasBar" id="xyzzy">
    <webwork:property name="foo@bar"/> <!-- explicitly get the bar from
foo, even though the normal scoping rules would have stopped at xyzzy
-->
  </webwork:property>
</webwork:property>

Seems ok? This can be used with params too I think:

<webwork:property name="hasBar" id="foo">
<jsp:include page="FooListElementsHasBar.action?list.jsp" flush="true">
  <jsp:param name="name" value="xyzzy"/>
  <jsp:param name="label" value="foo@bar"/>
  <jsp:param name="value" value="bar"/>
</jsp:include>
</webwork:property>

list.jsp
--- 
<!-- xyzzy is iterator attribute of FooList. Elements have "bar"
attribute, so we need to scope ->
<webwork:iterator name="xyzzy">
  <!-- Show value of foo@bar, and also print out xyzzy elements' bar
value -->
  <webwork:property name="$label"/>:<webwork:property name="$value"/>
</webwork:iterator>
---

I think the above allows arbitrary scoping. And it also allow included
pages to refer to any attribute of any property in parent page (without
this scoping the child included pages can only refer to attributes in
the result!).

Seems ok.

Any flaws with? Pros/cons?

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] WebWork vs Struts

[Edwin D. <ede...@ja...>]

Anyone want to create WebWork example that does the stuff in this Article
about Struts ?
http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-struts_p.html

[Webwork-user] Update to Template Controls now in CVS

[Maurice C . P. <Ma...@Vi...>]

All,

I have updated the template controls in CVS.  The controls now have their parameters documented inside the code of the controls inside of JSP comment tags.  This is probably the best place to look for now if you are wanting to see how to use the controls.

A new control, selectmap.jsp, has been added.  It and all the other *map.jsp controls now require you to explicitly state what the attribute names of the key and value are.  Check out formtest.jsp to see how this works.

Also new are optional parameters to specify SIZE and MAXLENGTH on text and password fields.

You may also now move the label to above the control instead of to the left of by using the optional parameter labelposition using the value "top".  This is true of all labels except the checkbox.jsp, which uses a diffent formatting scheme.

Later,

Maurice

[Webwork-user] Developing XML Solutions with JSP Technology

[Edwin D. <ede...@ja...>]

Rickard,
Another topic to tackle at some point...  If you do a Example, remember to
link to this article for "background"

http://java.sun.com/products/jsp/html/JSPXML.html

Regards,
Edwin

[Webwork-user] Name collision

[Maurice C . P. <Ma...@Vi...>]

Rickard, 

To try and explain this clearer I will denote jsp params by enclosing them in *'ss.

I am having some problems implementing selectmap.jsp using *key* and *value* as variables.  The problem is when the *key* has the same name as *name*.  This causes every option to be CHECKED.  This is because I can't figure out a way to explicitly access a parent property while at a child level.  The only way I know how is to cause the name to miss at the child level.

What I'm looking for is something like <webwork:property name="../$name"/> or <webwork:property name="/$name">.  IIRC, this is how its done in XSLT.

I was able to change one of the attribute names to get the example to work, but it may be an issue with with others.

Following is the actual code that is causing the problem:



I have added this class to test a collection with selectmap.jsp that looks like this:

===========================================================

/*
 * WebWork, Web Application Framework
 *
 * Distributable under LGPL license.
 * See terms of license at opensource.org
 */
package webwork.test;

import java.util.List;
import java.util.ArrayList;
import java.util.StringTokenizer;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.BufferedReader;
import java.io.IOException;

import webwork.ActionSupport;

/**
 *	A list of books
 *      
 *	@see <related>
 *	@author <firstname> <lastname> (<email>)
 *	@version $Revision: 1.2 $
 */
public class BookList
   extends ActionSupport
{
   // Attributes ----------------------------------------------------
   static List books;
   
   static
   {
      // This never changes, so we do it once only
      books = new ArrayList();
      
   class Book
   {
	   String title;
	   String author;
	   String publisher;

	   public String getTitle()
	   {
	      return title;
	   }

	   public void setTitle(String title)
	   {
	      this.title = title;
	   }

	   public String getAuthor()
	   {
	      return author;
	   }

	   public void setAuthor(String author)
	   {
	      this.author = author;
	   }

	   public String getPublisher()
	   {
	      return publisher;
	   }

	   public void setPublisher(String publisher)
	   {
	      this.publisher = publisher;
	   }
   }

      // We read the values from a file so that it is easy to change
      try
      {
         InputStream resource = BookList.class.getResourceAsStream("books.txt");
         BufferedReader in = new BufferedReader(new InputStreamReader(resource));
         String bookInfo;
         while ((bookInfo = in.readLine()) != null)
         {
            StringTokenizer tokens = new StringTokenizer(bookInfo, ",");
            Book book = new Book();
            book.setTitle(tokens.nextToken());
            book.setAuthor(tokens.nextToken());
            book.setPublisher(tokens.nextToken());
            books.add(book);
         }
         in.close();   
      } catch (IOException e)
      {
         e.printStackTrace(System.err);
         System.err.println("Could not read list of books");
      }
   }
   
   // Public --------------------------------------------------------
   public List getBooks()
   {
      return books;
   }

}

===========================================================

I also added setAuthor() and getAuthor() to FormTestForm but didn't include them here (obvious implemention).  

===========================================================

<%@ taglib uri="webwork" prefix="webwork" %>

<jsp:include page="/template/standard/controlheader.jsp" flush="true"/>

		<select name="<%=request.getParameter("name")%>">
			<webwork:iterator name="$list">
				<option  
						 value="<webwork:property name="$key"/>"
				         <webwork:equals name="$key" value="$name">SELECTED</webwork:equals> >
						<webwork:property name="$value"/>
				</option>
			</webwork:iterator>
		</select>

<jsp:include page="/template/standard/controlfooter.jsp" flush="true"/>

===========================================================

Added this to formtest.jsp:

===========================================================

	<jsp:include page="BookList.action?result=/template/standard/selectmap.jsp" flush="true">
	  <jsp:param name="label" value="Book:"/>
	  <jsp:param name="name" value="author"/>
	  <jsp:param name="list" value="books"/>
	  <jsp:param name="key" value="author"/>
	  <jsp:param name="value" value="title"/>
	</jsp:include>


Later,

Maurice

Re: [Webwork-user] I18n and more

[Rickard <ri...@jb...>]

Hi!

"Maurice C . Parker" wrote:
> I think a lot of people are going to see the i18n example out of the context of the article and not understand why the Shop action being used as a dispatcher.  It through me off for a while, because I didn't read the article.
> 
> To include the i18n example in its current form with the Webwork distribution could be seen as an endorsement for this style of programming.  Slap a disclaimer on it, do it the "Webwork way", or do both and distribute both.

Hm.. very true..I'll probably change it. "Don't show people how *not* to
do things" is a good rule.

> BTW in checkout.jsp:
> 
> <body bgcolor='<webwork:property name="texts:checkout.bgcolor"/>%>'>
>                                                                 ^
>                                                                 |
>                                                                oops

Fixed.

> Did the original article use blue as the background?  The first thing I did was change the background color of the demo so that I could try it without damaging my retinas.  %-)  Try a neutral color like white, light gray, or beige.

I have changed nothing in the way it looks or works. I agree with you.
But will keep it like that, for reference.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] I18n and more

[Rickard <ri...@jb...>]

"Maurice C . Parker" wrote:
> > Or what did you have in mind?
> >
> Right, after thinking it over some more I came to the same conclusion.
> 
> My original line of thinking had been that since it was so trivial to implement i18n error messages in the Support classes, maybe it should be the default behavior for Webwork error messages.
> 
> Then I slept on it and realized that this may be a little confusing to a newer programmer trying to learn Webwork.  "How do these crazy error messages work?  I don't need i18n for my corporate intranet application!"
> 
> A better solution would be to include subclasses of the Support classes in the i18n example, just to show i18n error messages being used.  Then put a note in the Best Practices that it is often desirable to create a personalized version of the Support classes for more feature rich applications.

Indeed. The problem is just that in the i18n there is only one Action,
which does everything (the "Shop"). Now, this is not how I would have
designed this functionality, but in order to keep it as similar to the
original article as possible I kept it this way. And with only one
action it is a bit silly to do support classes.

So, should I do the right thing and split it up into several distinct
actions, or keep it this way to be more similar to the original article
(which makes it easier to compare too)?

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] I18n and more

[Maurice C . P. <Ma...@Vi...>]

Hey,

* Rickard Öberg (ri...@jb...) wrote:
> Hi!
> 
> "Maurice C . Parker" wrote:
> > Since we are on the subject of i18n, I have notice that I am hard coding a lot of English error messages in my actions.  Of course I could use a resource bundle, but I was thinking that doing an i18n error message lookup by default in ActionSupport and ActionFormSupport would be more convenient.
> 
> Hm, well, I don't think this needs to be in the base support classes.
> It's very simple to do in an application base class, or in each action
> if you want to.
> 
> protected ResourceBundle getMessages()
> {
>   return ResourceBundle.getBundle("myaction", getLocale());
> }
> 
> public object execute()
> {
>   // Validation
>   if (.. error detected ..)
>   {
>     addErrorMessage(messages.getString("error.occurred")); // Get
> localized message
>   }
> }
> 
> Or what did you have in mind?
> 
Right, after thinking it over some more I came to the same conclusion.  

My original line of thinking had been that since it was so trivial to implement i18n error messages in the Support classes, maybe it should be the default behavior for Webwork error messages.

Then I slept on it and realized that this may be a little confusing to a newer programmer trying to learn Webwork.  "How do these crazy error messages work?  I don't need i18n for my corporate intranet application!"

A better solution would be to include subclasses of the Support classes in the i18n example, just to show i18n error messages being used.  Then put a note in the Best Practices that it is often desirable to create a personalized version of the Support classes for more feature rich applications.

Later,

Maurice

Re: [Webwork-user] I18n and more

[Rickard <ri...@jb...>]

Hi!

"Maurice C . Parker" wrote:
> Since we are on the subject of i18n, I have notice that I am hard coding a lot of English error messages in my actions.  Of course I could use a resource bundle, but I was thinking that doing an i18n error message lookup by default in ActionSupport and ActionFormSupport would be more convenient.

Hm, well, I don't think this needs to be in the base support classes.
It's very simple to do in an application base class, or in each action
if you want to.

protected ResourceBundle getMessages()
{
  return ResourceBundle.getBundle("myaction", getLocale());
}

public object execute()
{
  // Validation
  if (.. error detected ..)
  {
    addErrorMessage(messages.getString("error.occurred")); // Get
localized message
  }
}

Or what did you have in mind?

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

(forw) Re: [Webwork-user] Interactive documentation

[Maurice C . P. <Ma...@Vi...>]

Hey,

* Andrius Juozapaitis (an...@li...) wrote:
> hi all,
> 
> one nice way of building interactive documentation is implemented in
> http://www.php.net/manual/ - you can add comments and remarcs to the help
> topics. such a thing would really make support easier later on - and it is

Interesting concept.  Looks like a job for Jive.  This actually on something that I'm working on right now.  I am using Webwork to embed Jive into portals.  A side effect of this should be the ability to use Jive forums as a component of a larger framework.  Possibilities include documentations systems or ecommerce applications (I'm thinking about Amazon user comments here).

> good place to share experience, etc. btw, I am almost done with documenting
> the ebs-like architecture, will post the final draft sometime next week.
> 
> --andrius
> 

Maurice

Re: [Webwork-user] I18n and more

[Maurice C . P. <Ma...@Vi...>]

Hello,

Since we are on the subject of i18n, I have notice that I am hard coding a lot of English error messages in my actions.  Of course I could use a resource bundle, but I was thinking that doing an i18n error message lookup by default in ActionSupport and ActionFormSupport would be more convenient.

Later,

Maurice

Re: [Webwork-user] Interactive documentation

[Andrius J. <an...@li...>]

hola,

this exact functionality is actually a piece of cake to implement, ie. with
the same jboss + tomcat + webmacro combo. anyway there should be some
responsible person that monitors, groups and sorts the posts, but the good
thing about it would be that contributions would have been made easy. the
problem is if we could find a runtime environment for that - so far I don't
know any servers doing this, though I can try to organize some low-bandwidth
access (at least temporarily) here (512 kbps). if somebody's interested, let
me know.

regards,
--andrius


--andrius
----- Original Message -----
From: "Maurice C . Parker" <Ma...@Vi...>
To: "Andrius Juozapaitis" <an...@li...>
Sent: Wednesday, December 06, 2000 1:17 AM
Subject: Re: [Webwork-user] Interactive documentation


: Hey,
:
: * Andrius Juozapaitis (an...@li...) wrote:
: > hi all,
: >
: > one nice way of building interactive documentation is implemented in
: > http://www.php.net/manual/ - you can add comments and remarcs to the
help
: > topics. such a thing would really make support easier later on - and it
is
:
: Interesting concept.  Looks like a job for Jive.  This actually on
something that I'm working on right now.  I am using Webwork to embed Jive
into portals.  A side effect of this should be the ability to use Jive
forums as a component of a larger framework.  Possibilities include
documentations systems or ecommerce applications (I'm thinking about Amazon
user comments here).
:
: > good place to share experience, etc. btw, I am almost done with
documenting
: > the ebs-like architecture, will post the final draft sometime next week.
: >
: > --andrius
: >
:

Re: [Webwork-user] Interactive documentation

[Andrius J. <an...@li...>]

hi all,

one nice way of building interactive documentation is implemented in
http://www.php.net/manual/ - you can add comments and remarcs to the help
topics. such a thing would really make support easier later on - and it is
good place to share experience, etc. btw, I am almost done with documenting
the ebs-like architecture, will post the final draft sometime next week.

--andrius

----- Original Message -----
From: "Maurice C . Parker" <Ma...@vi...>
To: <web...@li...>
Sent: Tuesday, December 05, 2000 5:43 PM
Subject: [Webwork-user] Interactive documentation


: All,
:
: I was just about to begin documenting the template controls and was
wondering if there were any documentation standards that should be followed.
Is everything to be done plaintext, HTML, Docbook, or something else?
:
: I was going to put links next to the controls on the form test page to go
to a page that had the control on it, show the code used to include it, and
document the required and optionional parameters.  This would be similar to
how Tomcat's documentation is merged with it's demo system.  Then I noticed
that there was already a doc directory, and some standard maybe should be
followed.
:
: Suggestions?
:
: Maurice
: _______________________________________________
: Webwork-user mailing list
: Web...@li...
: http://lists.sourceforge.net/mailman/listinfo/webwork-user
:

[Webwork-user] WebWork 0.6

[Rickard <ri...@jb...>]

WebWork 0.6 is in CVS

I have now finished the i18n example, which is an adaptation of the
JavaWorld article on i18n in JSP by Govind Seshadri. The stuff is in all
/i18n directories (code+jsp+resources). Pretty cool.

Two new tags: 
The "include" tag is basically the same as jsp:include, but the param
tag can take its value from the body instead of only from its "value"
attribute. 
The "bean" tag is used to create a bean which is available during the
execution of its body. Useful for small functionality. set methods can
be called by using param tags, and get methods are called the usual way
(i.e. use the webwork:property tag).
Both tags are used in the i18n example, so see that for more info. 

I'll send more info on this later. :-)

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...