webwork-devel Mailing List for WebWork (Page 31)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/webwork/webwork/src/resources/web
In directory usw-pr-cvs1:/tmp/cvs-serv30554

Modified Files:
	formtest.jsp 
Log Message:
added multi select

Update of /cvsroot/webwork/webwork/src/resources/web/template/css
In directory usw-pr-cvs1:/tmp/cvs-serv30510

Modified Files:
	select.jsp selectgroupmap.jsp selectmap.jsp 
Log Message:
added multi select

Update of /cvsroot/webwork/webwork/src/resources/web/template/standard
In directory usw-pr-cvs1:/tmp/cvs-serv30482

Modified Files:
	select.jsp selectgroupmap.jsp selectmap.jsp 
Log Message:
added multi select

Update of /cvsroot/webwork/webwork/src/resources/web/WEB-INF/classes/META-INF
In directory usw-pr-cvs1:/tmp/cvs-serv30409

Modified Files:
	taglib.tld 
Log Message:
added multi select

Update of /cvsroot/webwork/webwork/src/resources/web
In directory usw-pr-cvs1:/tmp/cvs-serv11311

Modified Files:
	index.jsp 
Log Message:
fixed for example/

Cross post:

------- Start of forwarded message -------

To: web...@li...
Subject: [Webwork-user] logo
From: ma...@sm...
Date: 22 Feb 2002 06:35:09 -0800

I twisted a graphic artist's arm to design a logo based on the previous design while maintaining the sacred pyramid. Attached is a few concepts she came up with. Since she did this free, I assured her that we would give her appropriate credit. Here is what she came up with. If needed, I can ask her for one more revision if we come to a consensus on what we would like to see given these as a start.

-Matt

------- End of forwarded message -------

Update of /cvsroot/webwork/webwork/src/resources/web
In directory usw-pr-cvs1:/tmp/cvs-serv22519

Modified Files:
	index.jsp 
Log Message:
fixed for example 

Hello,

Kjetil Paulsen wrote:
> 
> Hi
> 
> Questions:
> 
> * Strictly speaking, Velocity and Xslt support, are addons to the WW core - IMO. Anyone?
> * Should this be moved? (to f.ex src/addon lib/addon)
>   - this would make container compliance even easier

If I understand you correctly, I don't think it's necessary (see below).

> Someone said something about out of date Velocity, the -dep-1.2-rc3.jar is in CVS and I guess there are a 1.2 release out there.
> * Is there a reason NOT to get the 1.2 release into CVS?

Can't think of one.  I've been using the -dep-1.2 against the current WW
CVS recently without issues.

> * Should we use the -dep- file or not
>   - if not we have to include commons from jakarta (I guess ?)
>      - THIS should at least not be part of the core!

The -dep .jar includes Avalon LogKit which Velocity will use by default. 
By using the velocity.jar + commons .jar, it might require configuring
Velocity to use Log4J.  This should be done anyway but probably not for
1.0.  This is explained in the WHY_TWO_JARS.txt file in the dist root. 
I'll try and test this later today.

> * The documentation states that the later is the way to go - we should be consistent

Agreed.  Actually, the documentation should state that either approach is
valid.

> This would make 3 builds
> - core

No Velocity or XSLT support included.
Maybe web.xml does not include Velocity or XSLT support?

> - core-with-addon
> - examples-with-addon

Velocity and XSLT support in lib just as now.
web.xml is the same as now.

Also, I think the examples-with-addon build should also include the
current Log4J .jar so you can deploy the .war and use it without any other
downloads.  This makes for a much better user experience for anyone
investigating WW ... just deploy and run.

-Bill

Update of /cvsroot/webwork/webwork/src/lib
In directory usw-pr-cvs1:/tmp/cvs-serv25097

Added Files:
	velocity-dep-1.2.jar 
Log Message:
Updated Velocity from rc3 to release 1.2

Update of /cvsroot/webwork/webwork/src/lib
In directory usw-pr-cvs1:/tmp/cvs-serv24909

Removed Files:
	velocity-dep-1.2-rc3.jar 
Log Message:
no message

Hi

Questions:

* Strictly speaking, Velocity and Xslt support, are addons to the WW =
core - IMO. Anyone?
* Should this be moved? (to f.ex src/addon lib/addon)
  - this would make container compliance even easier

Someone said something about out of date Velocity, the -dep-1.2-rc3.jar =
is in CVS and I guess there are a 1.2 release out there.=20
* Is there a reason NOT to get the 1.2 release into CVS?
* Should we use the -dep- file or not
  - if not we have to include commons from jakarta (I guess ?)=20
     - THIS should at least not be part of the core!
* The documentation states that the later is the way to go - we should =
be consistent

This would make 3 builds
- core
- core-with-addon
- examples-with-addon

/kjetilhp

......mogul.technology..............................................
 mogul technology as > kjetil h.paulsen - senior software architect
 drammensveien 134, NO-0277 oslo, norway
 cell +47 93060327, tel +4724114300, fax +4724114399
 kje...@mo..., http://www.mogul.com
 PGP fingerprint: DA54 A106 1989 FEF0 294F  63A4 9FC6 0F8E 21AD 0180
 ICQ -> 66288365
..............................................mogul.technology......

Hi Victor,

Victor Salaman wrote:
> 
> My changes have 0 impact on compatibility. I just don't feel like adding
> stuff inside the release cycle.

Right, because there's almost nothing to be incompatible with yet :) .

Okay.  I won't work on this further and wait for your commit after 1.0 is
released.

> /V

-Bill

> >From: "Bill Burton" <bi...@pr...>
> >To: Victor Salaman <vsa...@ho...>
> >CC: web...@li...
> >Subject: Re: [Webwork-devel] Adding i18n and text support to Velocity
> >Date: Wed, 20 Feb 2002 16:50:11 -0500
> >
> >Hello Victor,
> >
> >Victor Salaman wrote:
> > >
> > > They say that waiting is a good thing :)
> > >
> > > I have all that done  for velocity, including:
> > >
> > > new wwvelocityservlet featuring a context Toolbox
> > > ui templates
> > > common tools such as i18n,url,etc...
> > > integration to sitemesh for decoration
> > >
> > > But I can't commit until we release 1.0 :(
> >
> >Yes, your changes seem fairly extensive.
> >
> >I was trying to implement something minimal that could make it into 1.0
> >since not having the i18n and text support at all for Velocity for the 1.0
> >release is rather bad IMHO.  The UI stuff is nice-to-have but not a core
> >feature like i18n and text are which is why I think at least a minimal
> >solution needs to be in 1.0.
> >
> >Have figured out a way of implementing a subset of i18n and text support
> >entirely within Velocity macros.  However I think minimal text support (no
> >parameters) and i18n would be better as a simple methods within
> >WebWorkUtil with a simple macro wrapper for i18n.   The changes are quite
> >simple and would not be destabilizing.
> >
> >If there are no objections, I'd still like to do this but in a manner
> >that's forward compatible with your implementation.  Or maybe a subset of
> >your changes for i18n and text support would be acceptable for inclusion
> >into 1.0?
> >
> > > So I'm stuck here... If you'd like a preview come to Efnet #java (irc)
> >and
> > > look for me :)
> >
> >Will need to get an IRC client first ...
> >
> >Is there anything you could send me that describes how your version if the
> >i18n and text stuff is called?
> >
> > > /V
> >
> >This webwork-devel list is really slow.  I still haven't seen your message
> >from the list yet.
> >
> >-Bill
> >
> > > >From: "Bill Burton" <bi...@pr...>
> > > >To: WebWork Developers <web...@li...>
> > > >Subject: [Webwork-devel] Adding i18n and text support to Velocity
> > > >Date: Wed, 20 Feb 2002 00:18:21 -0500
> > > >
> > > >Hello,
> > > >
> > > >I've been looking into the best way to add support for the equivalent
> >of
> > > >the ww:i18n and ww:text JSP tags to Velocity.
> > > >
> > > >One thing that seems apparent is that the ValueStack needs to be
> >exposed
> > > >to Velocity templates in some manner.  This is at least true to get the
> > > >i18n functionality to work and may be necessary in other cases as well.
> > > >
> > > >I'm planning on adding the ValueStack to the VelocityContext so it can
> >be
> > > >accessed via the key $valuestack.  However, most usage will be wrapped
> >in
> > > >macros like #pushvalue() and #popvalue() so users won't access
> >$valuestack
> > > >directly.  For user visible methods such as findValue() and test(),
> >I've
> > > >modified WebWorkUtil adding these methods to the delegate to the same
> > > >ValueStack methods.  This will allow these methods can be called using
> >the
> > > >syntax $webwork.methodName().  In the case of findValue() that will
> > > >probably be available as $webwork.value(...).
> > > >
> > > >In the case of i18n support there would be an i18n macro that would be
> > > >called like this:
> > > >     #i18n("webwork.action.test.i18n.Shop")
> > > >
> > > >By definition it would push the specified ResourceBundle on the
> >ValueStack
> > > >thereby allowing the text support to use that ResourceBundle instead of
> > > >the default.  However, because this macro isn't a block tag, there
> >needs
> > > >to be some way of popping the ResourceBundle off the ValueStack.  To do
> > > >this, I was going to expose the ValueStack popValue() method within a
> > > >macro:
> > > >     #popvalue()
> > > >Which would be implemented as $valuestack.popValue().
> > > >
> > > >In like manner there are times when an Action or Bean needs to be
> >pushed
> > > >onto the stack.  For instance:
> > > >     #action("i18n.Shop", $shop)
> > > >     #pushvalue($shop)
> > > >     ...
> > > >     #execute($shop)
> > > >     ...
> > > >     #popvalue()
> > > >
> > > >I'm also looking into making an i18n block directive which would scope
> >the
> > > >ResourceBundle instance as in:
> > > >     #i18n("webwork.action.test.i18n.Shop")
> > > >     ...
> > > >     #end
> > > >
> > > >If I can get that to work, the popValue will be implied at the #end.
> > > >
> > > >As far as support for text goes, I'm planning on adding a several
> >text()
> > > >methods to WebWorkUtil.  As a result, they'll be available via the
> > > >$webwork context name.
> > > >     $webwork.text(key)
> > > >     $webwork.text(key, param0)
> > > >     etc.
> > > >
> > > >In order to implement the parameter support, I'll copy the TextTag
> >class
> > > >into the .velocity package and rework it with more appropriate API's
> >for
> > > >Velocity.  After the 1.0 release, these two classes could be refactored
> >so
> > > >they call a common class in .util.
> > > >
> > > >Thanks for any feedback,
> > > >-Bill
> > > >

Update of /cvsroot/webwork/webwork/src/resources/web/WEB-INF/classes/META-INF
In directory usw-pr-cvs1:/tmp/cvs-serv12780

Modified Files:
	taglib.tld 
Log Message:
Commented 'show' attribute as it's not implemented in the class. Workaround 
to make this work on Weblogic.

Hello Victor,

Victor Salaman wrote:
> 
> They say that waiting is a good thing :)
> 
> I have all that done  for velocity, including:
> 
> new wwvelocityservlet featuring a context Toolbox
> ui templates
> common tools such as i18n,url,etc...
> integration to sitemesh for decoration
> 
> But I can't commit until we release 1.0 :(

Yes, your changes seem fairly extensive.

I was trying to implement something minimal that could make it into 1.0
since not having the i18n and text support at all for Velocity for the 1.0
release is rather bad IMHO.  The UI stuff is nice-to-have but not a core
feature like i18n and text are which is why I think at least a minimal
solution needs to be in 1.0.

Have figured out a way of implementing a subset of i18n and text support
entirely within Velocity macros.  However I think minimal text support (no
parameters) and i18n would be better as a simple methods within
WebWorkUtil with a simple macro wrapper for i18n.   The changes are quite
simple and would not be destabilizing.

If there are no objections, I'd still like to do this but in a manner
that's forward compatible with your implementation.  Or maybe a subset of
your changes for i18n and text support would be acceptable for inclusion
into 1.0?

> So I'm stuck here... If you'd like a preview come to Efnet #java (irc) and
> look for me :)

Will need to get an IRC client first ...

Is there anything you could send me that describes how your version if the
i18n and text stuff is called?

> /V

This webwork-devel list is really slow.  I still haven't seen your message
from the list yet.

-Bill

> >From: "Bill Burton" <bi...@pr...>
> >To: WebWork Developers <web...@li...>
> >Subject: [Webwork-devel] Adding i18n and text support to Velocity
> >Date: Wed, 20 Feb 2002 00:18:21 -0500
> >
> >Hello,
> >
> >I've been looking into the best way to add support for the equivalent of
> >the ww:i18n and ww:text JSP tags to Velocity.
> >
> >One thing that seems apparent is that the ValueStack needs to be exposed
> >to Velocity templates in some manner.  This is at least true to get the
> >i18n functionality to work and may be necessary in other cases as well.
> >
> >I'm planning on adding the ValueStack to the VelocityContext so it can be
> >accessed via the key $valuestack.  However, most usage will be wrapped in
> >macros like #pushvalue() and #popvalue() so users won't access $valuestack
> >directly.  For user visible methods such as findValue() and test(), I've
> >modified WebWorkUtil adding these methods to the delegate to the same
> >ValueStack methods.  This will allow these methods can be called using the
> >syntax $webwork.methodName().  In the case of findValue() that will
> >probably be available as $webwork.value(...).
> >
> >In the case of i18n support there would be an i18n macro that would be
> >called like this:
> >     #i18n("webwork.action.test.i18n.Shop")
> >
> >By definition it would push the specified ResourceBundle on the ValueStack
> >thereby allowing the text support to use that ResourceBundle instead of
> >the default.  However, because this macro isn't a block tag, there needs
> >to be some way of popping the ResourceBundle off the ValueStack.  To do
> >this, I was going to expose the ValueStack popValue() method within a
> >macro:
> >     #popvalue()
> >Which would be implemented as $valuestack.popValue().
> >
> >In like manner there are times when an Action or Bean needs to be pushed
> >onto the stack.  For instance:
> >     #action("i18n.Shop", $shop)
> >     #pushvalue($shop)
> >     ...
> >     #execute($shop)
> >     ...
> >     #popvalue()
> >
> >I'm also looking into making an i18n block directive which would scope the
> >ResourceBundle instance as in:
> >     #i18n("webwork.action.test.i18n.Shop")
> >     ...
> >     #end
> >
> >If I can get that to work, the popValue will be implied at the #end.
> >
> >As far as support for text goes, I'm planning on adding a several text()
> >methods to WebWorkUtil.  As a result, they'll be available via the
> >$webwork context name.
> >     $webwork.text(key)
> >     $webwork.text(key, param0)
> >     etc.
> >
> >In order to implement the parameter support, I'll copy the TextTag class
> >into the .velocity package and rework it with more appropriate API's for
> >Velocity.  After the 1.0 release, these two classes could be refactored so
> >they call a common class in .util.
> >
> >Thanks for any feedback,
> >-Bill
> >

Under lib/docbook we seem to have docbook-xsl 1.45.
Was there any manipulation after extracting the distribution available from
SourceForge?

Many Thanks,
___________________________
François Beauregard, b.ing.
Vice-président
Recherche et développement
Pyxis Technologies
www.pyxis-tech.com

T : (450) 681-9094, poste 102
F : (450) 681-5758
fbe...@py...

My changes have 0 impact on compatibility. I just don't feel like adding 
stuff inside the release cycle.

/V

>From: "Bill Burton" <bi...@pr...>
>To: Victor Salaman <vsa...@ho...>
>CC: web...@li...
>Subject: Re: [Webwork-devel] Adding i18n and text support to Velocity
>Date: Wed, 20 Feb 2002 16:50:11 -0500
>
>Hello Victor,
>
>Victor Salaman wrote:
> >
> > They say that waiting is a good thing :)
> >
> > I have all that done  for velocity, including:
> >
> > new wwvelocityservlet featuring a context Toolbox
> > ui templates
> > common tools such as i18n,url,etc...
> > integration to sitemesh for decoration
> >
> > But I can't commit until we release 1.0 :(
>
>Yes, your changes seem fairly extensive.
>
>I was trying to implement something minimal that could make it into 1.0
>since not having the i18n and text support at all for Velocity for the 1.0
>release is rather bad IMHO.  The UI stuff is nice-to-have but not a core
>feature like i18n and text are which is why I think at least a minimal
>solution needs to be in 1.0.
>
>Have figured out a way of implementing a subset of i18n and text support
>entirely within Velocity macros.  However I think minimal text support (no
>parameters) and i18n would be better as a simple methods within
>WebWorkUtil with a simple macro wrapper for i18n.   The changes are quite
>simple and would not be destabilizing.
>
>If there are no objections, I'd still like to do this but in a manner
>that's forward compatible with your implementation.  Or maybe a subset of
>your changes for i18n and text support would be acceptable for inclusion
>into 1.0?
>
> > So I'm stuck here... If you'd like a preview come to Efnet #java (irc) 
>and
> > look for me :)
>
>Will need to get an IRC client first ...
>
>Is there anything you could send me that describes how your version if the
>i18n and text stuff is called?
>
> > /V
>
>This webwork-devel list is really slow.  I still haven't seen your message
>from the list yet.
>
>-Bill
>
> > >From: "Bill Burton" <bi...@pr...>
> > >To: WebWork Developers <web...@li...>
> > >Subject: [Webwork-devel] Adding i18n and text support to Velocity
> > >Date: Wed, 20 Feb 2002 00:18:21 -0500
> > >
> > >Hello,
> > >
> > >I've been looking into the best way to add support for the equivalent 
>of
> > >the ww:i18n and ww:text JSP tags to Velocity.
> > >
> > >One thing that seems apparent is that the ValueStack needs to be 
>exposed
> > >to Velocity templates in some manner.  This is at least true to get the
> > >i18n functionality to work and may be necessary in other cases as well.
> > >
> > >I'm planning on adding the ValueStack to the VelocityContext so it can 
>be
> > >accessed via the key $valuestack.  However, most usage will be wrapped 
>in
> > >macros like #pushvalue() and #popvalue() so users won't access 
>$valuestack
> > >directly.  For user visible methods such as findValue() and test(), 
>I've
> > >modified WebWorkUtil adding these methods to the delegate to the same
> > >ValueStack methods.  This will allow these methods can be called using 
>the
> > >syntax $webwork.methodName().  In the case of findValue() that will
> > >probably be available as $webwork.value(...).
> > >
> > >In the case of i18n support there would be an i18n macro that would be
> > >called like this:
> > >     #i18n("webwork.action.test.i18n.Shop")
> > >
> > >By definition it would push the specified ResourceBundle on the 
>ValueStack
> > >thereby allowing the text support to use that ResourceBundle instead of
> > >the default.  However, because this macro isn't a block tag, there 
>needs
> > >to be some way of popping the ResourceBundle off the ValueStack.  To do
> > >this, I was going to expose the ValueStack popValue() method within a
> > >macro:
> > >     #popvalue()
> > >Which would be implemented as $valuestack.popValue().
> > >
> > >In like manner there are times when an Action or Bean needs to be 
>pushed
> > >onto the stack.  For instance:
> > >     #action("i18n.Shop", $shop)
> > >     #pushvalue($shop)
> > >     ...
> > >     #execute($shop)
> > >     ...
> > >     #popvalue()
> > >
> > >I'm also looking into making an i18n block directive which would scope 
>the
> > >ResourceBundle instance as in:
> > >     #i18n("webwork.action.test.i18n.Shop")
> > >     ...
> > >     #end
> > >
> > >If I can get that to work, the popValue will be implied at the #end.
> > >
> > >As far as support for text goes, I'm planning on adding a several 
>text()
> > >methods to WebWorkUtil.  As a result, they'll be available via the
> > >$webwork context name.
> > >     $webwork.text(key)
> > >     $webwork.text(key, param0)
> > >     etc.
> > >
> > >In order to implement the parameter support, I'll copy the TextTag 
>class
> > >into the .velocity package and rework it with more appropriate API's 
>for
> > >Velocity.  After the 1.0 release, these two classes could be refactored 
>so
> > >they call a common class in .util.
> > >
> > >Thanks for any feedback,
> > >-Bill
> > >

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Rickard are attending BEA eWorld right now so he left me with some stuff =
to do before release

* Further seperate examples and core by
	- move 3rd party libs to src/lib/examples
	- move example code to src/examples
* Make build scripts so we get this separated
* Publish the docs to webwork.sourceforge.net

hope to get this fixed by tomorrow...

/kjetilhp

......mogul.technology..............................................
 mogul technology as > kjetil h.paulsen - senior software architect
 drammensveien 134, NO-0277 oslo, norway
 cell +47 93060327, tel +4724114300, fax +4724114399
 kje...@mo..., http://www.mogul.com
 PGP fingerprint: DA54 A106 1989 FEF0 294F  63A4 9FC6 0F8E 21AD 0180
 ICQ -> 66288365
..............................................mogul.technology......

They say that waiting is a good thing :)

I have all that done  for velocity, including:

new wwvelocityservlet featuring a context Toolbox
ui templates
common tools such as i18n,url,etc...
integration to sitemesh for decoration

But I can't commit until we release 1.0 :(

So I'm stuck here... If you'd like a preview come to Efnet #java (irc) and 
look for me :)

/V

>From: "Bill Burton" <bi...@pr...>
>To: WebWork Developers <web...@li...>
>Subject: [Webwork-devel] Adding i18n and text support to Velocity
>Date: Wed, 20 Feb 2002 00:18:21 -0500
>
>Hello,
>
>I've been looking into the best way to add support for the equivalent of
>the ww:i18n and ww:text JSP tags to Velocity.
>
>One thing that seems apparent is that the ValueStack needs to be exposed
>to Velocity templates in some manner.  This is at least true to get the
>i18n functionality to work and may be necessary in other cases as well.
>
>I'm planning on adding the ValueStack to the VelocityContext so it can be
>accessed via the key $valuestack.  However, most usage will be wrapped in
>macros like #pushvalue() and #popvalue() so users won't access $valuestack
>directly.  For user visible methods such as findValue() and test(), I've
>modified WebWorkUtil adding these methods to the delegate to the same
>ValueStack methods.  This will allow these methods can be called using the
>syntax $webwork.methodName().  In the case of findValue() that will
>probably be available as $webwork.value(...).
>
>In the case of i18n support there would be an i18n macro that would be
>called like this:
>     #i18n("webwork.action.test.i18n.Shop")
>
>By definition it would push the specified ResourceBundle on the ValueStack
>thereby allowing the text support to use that ResourceBundle instead of
>the default.  However, because this macro isn't a block tag, there needs
>to be some way of popping the ResourceBundle off the ValueStack.  To do
>this, I was going to expose the ValueStack popValue() method within a
>macro:
>     #popvalue()
>Which would be implemented as $valuestack.popValue().
>
>In like manner there are times when an Action or Bean needs to be pushed
>onto the stack.  For instance:
>     #action("i18n.Shop", $shop)
>     #pushvalue($shop)
>     ...
>     #execute($shop)
>     ...
>     #popvalue()
>
>I'm also looking into making an i18n block directive which would scope the
>ResourceBundle instance as in:
>     #i18n("webwork.action.test.i18n.Shop")
>     ...
>     #end
>
>If I can get that to work, the popValue will be implied at the #end.
>
>As far as support for text goes, I'm planning on adding a several text()
>methods to WebWorkUtil.  As a result, they'll be available via the
>$webwork context name.
>     $webwork.text(key)
>     $webwork.text(key, param0)
>     etc.
>
>In order to implement the parameter support, I'll copy the TextTag class
>into the .velocity package and rework it with more appropriate API's for
>Velocity.  After the 1.0 release, these two classes could be refactored so
>they call a common class in .util.
>
>Thanks for any feedback,
>-Bill
>
>_______________________________________________
>Webwork-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webwork-devel

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Hello,

I've been looking into the best way to add support for the equivalent of
the ww:i18n and ww:text JSP tags to Velocity.

One thing that seems apparent is that the ValueStack needs to be exposed
to Velocity templates in some manner.  This is at least true to get the
i18n functionality to work and may be necessary in other cases as well.

I'm planning on adding the ValueStack to the VelocityContext so it can be
accessed via the key $valuestack.  However, most usage will be wrapped in
macros like #pushvalue() and #popvalue() so users won't access $valuestack
directly.  For user visible methods such as findValue() and test(), I've
modified WebWorkUtil adding these methods to the delegate to the same
ValueStack methods.  This will allow these methods can be called using the
syntax $webwork.methodName().  In the case of findValue() that will
probably be available as $webwork.value(...).  

In the case of i18n support there would be an i18n macro that would be
called like this:
    #i18n("webwork.action.test.i18n.Shop")

By definition it would push the specified ResourceBundle on the ValueStack
thereby allowing the text support to use that ResourceBundle instead of
the default.  However, because this macro isn't a block tag, there needs
to be some way of popping the ResourceBundle off the ValueStack.  To do
this, I was going to expose the ValueStack popValue() method within a
macro:
    #popvalue()
Which would be implemented as $valuestack.popValue().

In like manner there are times when an Action or Bean needs to be pushed
onto the stack.  For instance:
    #action("i18n.Shop", $shop)
    #pushvalue($shop)
    ...
    #execute($shop)
    ...
    #popvalue()

I'm also looking into making an i18n block directive which would scope the
ResourceBundle instance as in:
    #i18n("webwork.action.test.i18n.Shop")
    ...
    #end

If I can get that to work, the popValue will be implied at the #end.

As far as support for text goes, I'm planning on adding a several text()
methods to WebWorkUtil.  As a result, they'll be available via the
$webwork context name.
    $webwork.text(key)
    $webwork.text(key, param0)
    etc.

In order to implement the parameter support, I'll copy the TextTag class
into the .velocity package and rework it with more appropriate API's for
Velocity.  After the 1.0 release, these two classes could be refactored so
they call a common class in .util.

Thanks for any feedback,
-Bill

Hello,

There really should be another RC release.  If all goes well, release 1.0
a week or so later.  After updating from CVS late yesterday, found all
kinds of problems with broken links to the examples (need to be prefixed
with example/) and duplicated files, some in the example directory and
some in the main directory.  

Issues making it difficult for new users:
* Properties files exist only in webwork.jar.  If you want to see what's
in them, you have to go hunting around through the source tree to find
them.  All these files should really be deployed to WEB-INF/classes as
well.  This allows people to more easily experiment by changing the
existing files.
* The source to the examples isn't readily available from the deployed web
app.  It would be much better if the example code could be rebuilt from
within the deployed web app.

All of these issues can be solved fairly easily with some modifications to
the build.xml.  It would make for a much better first impression for those
new to WW.

As far is the docs go, the Action API is the cornerstone of WW.  It really
needs to be documented for 1.0.  To get the ball rolling on this could
someone at least post a list of items that ought to be covered?  I'd be
willing to rework it into XML and sumbit a patch.  At least that would
provide a place to start.

-Bill

Matt Baldree wrote:
> 
> I thought WW was going to be released on the 15th. What is the delay? I
> think we need to go ahead and get the release out so we can move forward
> with 1.1. I think many people are waiting for the release. Any sections in
> the documentation that are blank should be commented out to be finished
> later or removed all together.
> 
> -Matt

I thought WW was going to be released on the 15th. What is the delay? I
think we need to go ahead and get the release out so we can move forward
with 1.1. I think many people are waiting for the release. Any sections in
the documentation that are blank should be commented out to be finished
later or removed all together.

-Matt

Update of /cvsroot/webwork/webwork/src/docs
In directory usw-pr-cvs1:/tmp/cvs-serv10073

Modified Files:
	jsp-iterator.xml 
Log Message:
updated docs to reflect new modulus functions

Update of /cvsroot/webwork/webwork/src/main/webwork/taglib
In directory usw-pr-cvs1:/tmp/cvs-serv30537

Modified Files:
	IteratorStatus.java 
Log Message:
added modulus methods

Update of /cvsroot/webwork/webwork/src/resources/web
In directory usw-pr-cvs1:/tmp/cvs-serv29688

Modified Files:
	iterators.jsp 
Log Message:
added modulus tests

I know that WebWork's documentation is generated using DocBook.
I would like to use DocBook for other projects.

What is involved in setting a DocBook environment? Tutorial somewhere?
Would it be possible to generate the documentation in PDF?
Any other better alternative than DocBook?

Wich XML editor are you suggesting?

Cheers,
______________________________________________
François Beauregard
Pyxis Technologies
Vice-président, recherche et développement

Tel: (450) 681-9094
Fax: (450) 681-5758
fbe...@py...

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (316)	Dec (117)
2002	Jan (197)	Feb (229)	Mar (293)	Apr (177)	May (84)	Jun (40)	Jul (43)	Aug	Sep	Oct	Nov	Dec

webwork-devel Mailing List for WebWork (Page 31)

webwork-devel — WebWork development