Re: [OS-webwork] Velocity for View Tags
Send me your diffs I'll check them in. You can contact me on ICQ(11843516)/AIM(farkas24)/Y!(scott_farkas) if you need to discuss anything. Scott Philipp Meier wrote: On Tue, Jan 28, 2003 at 07:50:56PM +1100, Scott Farquhar wrote: - Getting the templates (using servletPath). Some servlet containers have problems with getRealPath(). We can always bundle default templates in the jar (a plus), but how do we access the templates? Rickard seems to do it with his WebWorkVelocityServlet - but I'm not sure how. Thread.currentThread().getContextClassLoader().getResourceAsStream(/path/relative/to/web/roo) should do the trick. I recently changed my local version of the XSLTServlet to access the xslt stylesheets in this way. Could someone please give me cvs access again, then I could check in my improvements. -billy. -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support --- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Using the WiKi
Wiki's operate on the paradigm that a page is useless without any links to it - therefore you create the link first. Makes some sense :) -mike On 28/1/03 2:59 PM, Jason Carreira ([EMAIL PROTECTED]) penned the words: Cool. Got it. It sure wasn't obvious though! Maybe my wiki paradigm has been messed up because we use Traction at work. -Original Message- From: Erik Beeson [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 10:40 PM To: Subject: [OS-webwork] Using the WiKi To add a page to the WiKi (as I understand it): Create and account and login. Go to the page that you want to link to your new page. Edit the page by clicking the [edit] link in the upper right hand corner. Create a link to your new page by putting the link text in []. (See http://snipsnap.org/space/snipsnap-QuickTour) Save the page. You'll have a link on the page saying [create MyLinkText] Go to your new page and edit it as desired. --Erik See the following for more help: http://snipsnap.org/space/snipsnap-QuickTour http://snipsnap.org/space/snipsnap-help --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocity for View Tags
I'm confused about all the rd.include talk? What is wrong with the way things are now? With the servlet mapping the way it is for .vm etc it all just comes out in the wash doesn't it? Usually having access to the value stack from within a template isn't strictly necessary it is? Here's a rough version of text.jsp as a VM that I wipped out whilst trying this out. The issue for me was not wanting to hard code paths in my templates whilst maintaining the controlheader.jsp, controlfooter.jsp functionality. Here's text.vm #* -- -- WebWork, Web Application Framework -- -- Distributable under LGPL license. -- See terms of license at opensource.org -- -- -- text.jsp -- -- Required Parameters: -- * label - The description that will be used to identfy the control. -- * name - The name of the attribute to put and pull the result from. -- Equates to the NAME parameter of the HTML INPUT tag. -- -- Optional Parameters: -- * labelposition - determines were the label will be place in relation -- to the control. Default is to the left of the control. -- * size - SIZE parameter of the HTML INPUT tag. -- * maxlength - MAXLENGTH parameter of the HTML INPUT tag. -- * disabled - DISABLED parameter of the HTML INPUT tag. -- * readonly - READONLY parameter of the HTML INPUT tag. -- * onkeyup- onkeyup parameter of the HTML INPUT tag. -- * tabindex - tabindex parameter of the HTML INPUT tag. -- * onchange - onkeyup parameter of the HTML INPUT tag. *# #parse(controlheader.vm) #set ( $name = $parameters.get(name) ) #set ( $size = $parameters.get(size) ) #set ( $maxlength = $parameters.get(maxlength) ) #set ( $nameValue = $parameters.get(nameValue) ) #set ( $disabled = $parameters.get(disabled) ) #set ( $readonly = $parameters.get(readonly) ) #set ( $onkeyup = $parameters.get(onkeyup) ) #set ( $tabindex = $parameters.get(tabindex) ) #set ( $onchange = $parameters.get(onchange) ) #set ( $id = $parameters.get(id) ) input type=text name=$name #if ($size) size=$size #end #if ($maxlength) maxlength=$maxlength #end #if ($nameValue) nameValue=$nameValue #end #if ($disabled) disabled=$disabled #end #if ($readonly) readonly=$readonly #end #if ($onkeyup) onkeyup=$onkeyup #end #if ($tabindex) tabindex=$tabindex #end #if ($onchange) onchange=$onchange #end #if ($id) id=$id #end / #parse(controlfooter.vm) here's controlheader.vm ## Only show message if errors are available. ## This will be done if ActionFormSupport is used. #set ( $name = $parameters.get(name) ) #set ( $error = $errors.get($name) ) #if ($error) tr #set ($labelposition = $parameters.get(labelposition) ) #if ($labelposition == top) td align=left valign=top colspan=2 #else td align=center valign=top colspan=2 #end span class=errorMessage$error/span /td /tr #end ## if the label position is top, ## then give the label it's own row in the table tr #set ( $labelposition = $parameters.get(labelposition) ) #if ($labelposition == top) td align=left valign=top colspan=2 #else td align=right valign=top #end #if ($error) span class=errorLabel #else span class=label #end #set ( $label = $parameters.get(label) ) $label: /span /td #if ($labelposition == top) /trtr #end td ... This was all proof of concept. I didn't quite understand how the file resource loader stuff works in velocity... I didn't want to have to hard code any specific path in my #parse statements but I want to separate my velocity tag support from my result views. as the above stands .. controlheader.jsp has to be in the root context for this to load and that's not acceptable. On Tuesday, January 28, 2003, at 08:50 AM, Scott Farquhar wrote: (Also available here: http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-111) I have looked at changing the view tags over to velocity, and it is looking very promising. I have attached the text.vm text.jsp files for a comparison, and it cleans the code up quite a bit. As a first step, all the views can be duplicated in velocity, and then use the VelocityServlet to include them. This will not reduce the overhead of the rd.include() but will reduce the time for the included page to be parsed. I have completed (committed) this added a corresponding '.vm' file for most ui tags. You need to change 'webwork.ui.templateSuffix' to 'vm' and you need to map the WebWorkVelocityServlet to '*.vm'. I have tested the examples, but nothing further. However, when working through this, I came to a few problems: - Getting the value from the top of the valueStack. This is usually obtained with a . or a null value passed to stack.findValue(). However, in velocity, all values must start with a character. Are their any other synonyms for the current value that I don't know about? Can we add one? - Getting the
RE: [OS-webwork] Xwork configuration update
Can a stack reference a stack? It is sometimes nice of actions could refer to default which in turn could refer to either defaultStack or defaultDebug. Actions then refer to default and can be switched between production and debug simply by editing the debug interceptor stack reference. Yep. See the example config file. Interceptor instances and stacks are saved in the same Map, so either can be referenced the same way. Only one thing, either an Interceptor instance or a stack, can be referenced by one name, though. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Releasing 1.3 and new development
People have been adding new stuff, like the Velocity based templates, while the head is still (as far as I know) supposed to be 1.3 RC2. I like new stuff (see Xwork), but we really need to branch 1.3 to keep it clean of new stuff so we can develop against the head. If we end up needing to release 1.3.1 or somesuch to fix bugs, then we'll need the 1.3 source tree as a base to work from without keeping people from moving forward. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Releasing 1.3 and new development
I like webwork head cvs, and want to see it keep moving forward. We can tag a release (1.3) anytime now, really. Only thing that perhaps needs doing is updating some of the docs, and having decent release notes. xwork is still sandbox, and is nowhere near production worthy (right?) and I'd much rather than those of us who enjoy webwork and contributing to it don't end up feeling like second class citizens in favour of xwork. Quoting Jason Carreira [EMAIL PROTECTED]: People have been adding new stuff, like the Velocity based templates, while the head is still (as far as I know) supposed to be 1.3 RC2. I like new stuff (see Xwork), but we really need to branch 1.3 to keep it clean of new stuff so we can develop against the head. If we end up needing to release 1.3.1 or somesuch to fix bugs, then we'll need the 1.3 source tree as a base to work from without keeping people from moving forward. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone:585.240.2793 fax:585.272.8118 email:[EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocity for View Tags
I never got a chance to look into velocity loading problems but is it
possible to have the templates
like that of the jsps? ie. no need to specify the parent directory of
the tags templates in the velocity template even using a variable like
you've suggested.
Is it not possible for velocity to load templates to tags from a
different location than result views? ie. implicitly having a different
template root for each of these?
Velocity tag templates should still exist under webwork.TemplateDir
On Tuesday, January 28, 2003, at 01:27 PM, Scott Farquhar wrote:
You may want to check out my recent CVS commits - I have already
commited files for this.
Currently the paths to controlheader controlfooter are hard-coded,
but I will fix that tomorrow. I'll just add the current servlet's
path to the velocity context. So the parse line will be:
#parse (${currentpath}/controlheader.vm)
Have a look at the current CVS HEAD for webwork, and try out the
examples after changing the templateSuffix property in
webwork.properties.
Cheers,
Scott
Robert Nicholson wrote:
I'm confused about all the rd.include talk?
What is wrong with the way things are now?
With the servlet mapping the way it is for .vm etc it all just comes
out in the wash doesn't it?
Usually having access to the value stack from within a template isn't
strictly necessary it is?
Here's a rough version of text.jsp as a VM that I wipped out whilst
trying this out.
The issue for me was not wanting to hard code paths in my templates
whilst maintaining the controlheader.jsp, controlfooter.jsp
functionality.
Here's text.vm
#*
--
-- WebWork, Web Application Framework
--
-- Distributable under LGPL license.
-- See terms of license at opensource.org
--
--
-- text.jsp
--
-- Required Parameters:
-- * label - The description that will be used to identfy
the control.
-- * name - The name of the attribute to put and pull the
result from.
-- Equates to the NAME parameter of the HTML INPUT
tag.
--
-- Optional Parameters:
-- * labelposition - determines were the label will be place in
relation
-- to the control. Default is to the left of
the control.
-- * size - SIZE parameter of the HTML INPUT tag.
-- * maxlength - MAXLENGTH parameter of the HTML INPUT tag.
-- * disabled - DISABLED parameter of the HTML INPUT tag.
-- * readonly - READONLY parameter of the HTML INPUT tag.
-- * onkeyup- onkeyup parameter of the HTML INPUT tag.
-- * tabindex - tabindex parameter of the HTML INPUT tag.
-- * onchange - onkeyup parameter of the HTML INPUT tag.
*#
#parse(controlheader.vm)
#set ( $name = $parameters.get(name) )
#set ( $size = $parameters.get(size) )
#set ( $maxlength = $parameters.get(maxlength) )
#set ( $nameValue = $parameters.get(nameValue) )
#set ( $disabled = $parameters.get(disabled) )
#set ( $readonly = $parameters.get(readonly) )
#set ( $onkeyup = $parameters.get(onkeyup) )
#set ( $tabindex = $parameters.get(tabindex) )
#set ( $onchange = $parameters.get(onchange) )
#set ( $id = $parameters.get(id) )
input type=text name=$name
#if ($size)
size=$size
#end
#if ($maxlength)
maxlength=$maxlength
#end
#if ($nameValue)
nameValue=$nameValue
#end
#if ($disabled)
disabled=$disabled
#end
#if ($readonly)
readonly=$readonly
#end
#if ($onkeyup)
onkeyup=$onkeyup
#end
#if ($tabindex)
tabindex=$tabindex
#end
#if ($onchange)
onchange=$onchange
#end
#if ($id)
id=$id
#end
/
#parse(controlfooter.vm)
here's controlheader.vm
## Only show message if errors are available.
## This will be done if ActionFormSupport is used.
#set ( $name = $parameters.get(name) )
#set ( $error = $errors.get($name) )
#if ($error)
tr
#set ($labelposition = $parameters.get(labelposition) )
#if ($labelposition == top)
td align=left valign=top colspan=2
#else
td align=center valign=top colspan=2
#end
span class=errorMessage$error/span
/td
/tr
#end
## if the label position is top,
## then give the label it's own row in the table
tr
#set ( $labelposition = $parameters.get(labelposition) )
#if ($labelposition == top)
td align=left valign=top colspan=2
#else
td align=right valign=top
#end
#if ($error)
span class=errorLabel
#else
span class=label
#end #set ( $label = $parameters.get(label) )
$label:
/span
/td
#if ($labelposition == top)
/trtr
#end
td
...
This was all proof of concept.
I didn't quite understand how the file resource loader stuff works in
velocity... I didn't want to have
to hard code any specific path in my #parse statements but I want to
separate my velocity tag support
from my result views.
as the
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Francois Beauregard wrote: A few developers here have used freemarker a little while ago and loved it. It seems to be a very good alternative to velocity. Since it worked for WebWork and after some little discensions the community seems be very well and alive, I would like to throw the suggestion the freemarker joins OpenSymphony. If the suggestion makes sense, an evaluation of the ptoential must be done by both party. Also, goals and directions for the project should be established first. I think this is the part that was missing when the WebWork joined OpenSymphony. Well, I remember some not so long ago the FreeMarker main developer went to the Velocity lists and ranted like crazy. It was a very disappointing read and he just wouldn't give up. I'm sure FreeMarker is ok technically, but I'd prefer to keep stuff like that out of here. So, no, I don't think FreeMarker should join OS. IMHO. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
On the contrary, that makes it perfect for OS! ;) Quoting Rickard Öberg [EMAIL PROTECTED]: Francois Beauregard wrote: A few developers here have used freemarker a little while ago and loved it. It seems to be a very good alternative to velocity. Since it worked for WebWork and after some little discensions the community seems be very well and alive, I would like to throw the suggestion the freemarker joins OpenSymphony. If the suggestion makes sense, an evaluation of the ptoential must be done by both party. Also, goals and directions for the project should be established first. I think this is the part that was missing when the WebWork joined OpenSymphony. Well, I remember some not so long ago the FreeMarker main developer went to the Velocity lists and ranted like crazy. It was a very disappointing read and he just wouldn't give up. I'm sure FreeMarker is ok technically, but I'd prefer to keep stuff like that out of here. So, no, I don't think FreeMarker should join OS. IMHO. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Francois Beauregard wrote: I was not aware of that fact. You are right. OpenSymphony seem to have got lately to a point where there is a good exchange of ideas and the community moves forward. This must stay the way it is right now. Do you remeber the reasons for the ranting? Yes, his belief that FreeMarker was the ultimate solution and that he was entitled to telling everyone of this regardless of everyone on the list begging for the opposite. It was (to me) quite disgusting. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Wiki dammit
Jason Carreira wrote: Can someone please explain to me how to publish a page on the Wiki? I can't seem to find a link to create a new page Gaah! I just set up SnipSnap and ran into the same issue. 1. Log in. 2. Enter the desired topic into the Search fill-in and click the button. 3. Below any search matches, you will see something like, There is no snip with New Topic , would you like to [create New Topic]? Click the link to create you topic. Other than this and some other minor issues, I've really enjoyed using SnipSnap for my own KBase. -Bill Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Just wanted to emphasize the fact that supporting Freemarker as a view technology in WebWork and integrating Freemarker as an OpenSymphony project are two really separate issues. François -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg Sent: January 28, 2003 11:14 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags Francois Beauregard wrote: I was not aware of that fact. You are right. OpenSymphony seem to have got lately to a point where there is a good exchange of ideas and the community moves forward. This must stay the way it is right now. Do you remeber the reasons for the ranting? Yes, his belief that FreeMarker was the ultimate solution and that he was entitled to telling everyone of this regardless of everyone on the list begging for the opposite. It was (to me) quite disgusting. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Francois Beauregard wrote: Just wanted to emphasize the fact that supporting Freemarker as a view technology in WebWork and integrating Freemarker as an OpenSymphony project are two really separate issues. Oh absolutely. If someone wants to integrate FreeMaker go right ahead. I have no problem with that. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Releasing 1.3 and new development
I am in total agreement. A stable 1.3 branch is definitely needed. I think it would be very confusing for a new WW user to be expected to pull from the CVS head when the head potentially changes minute by minute. The 1.2 release has been totally ignored because work continued on the head to create the 1.3 release. IMO the feature sets should be better defined with specific goals so that developers know when a release is ready to be baked. I might be wrong but it seems that 1.3 was arbitrarily created because its been long enough since the 1.2 release. Consistent logging, performance enhancements and stability seems to be the goals of 1.3 from what I can tell. I an very confident that myself and several others on this list would help to maintain the 1.3 branch if necessary. BTW great job guys! WW does indeed rock! Regards, Kirk Rasmussen Lucasfilm Ltd. -Original Message- From: Jason Carreira [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 7:36 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Releasing 1.3 and new development Nononono you misunderstood. My bad. I want to branch 1.3 to be able to do bug fixes for any future 1.3.x releases. I want to keep the CVS head for continuing development and new features with a view to a 1.4 release. Xwork 1.0 and Webwork 2.0 can, and should, remain in the sandbox for now, until a LOT of issues are worked out and it's been fleshed out to do everything that WW 1.3 does. My point was really to be able to get back to 1.3 for bug fixes while not keeping people from continuing to develop against the CVS head. I'm not terribly comfortable with CVS, so I was throwing this out for someone to do. If we were using Perforce, I would create a branch, because branching is fast and low cost and it's how you do most code management in P4. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Releasing 1.3 and new development I like webwork head cvs, and want to see it keep moving forward. We can tag a release (1.3) anytime now, really. Only thing that perhaps needs doing is updating some of the docs, and having decent release notes. xwork is still sandbox, and is nowhere near production worthy (right?) and I'd much rather than those of us who enjoy webwork and contributing to it don't end up feeling like second class citizens in favour of xwork. Quoting Jason Carreira [EMAIL PROTECTED]: People have been adding new stuff, like the Velocity based templates, while the head is still (as far as I know) supposed to be 1.3 RC2. I like new stuff (see Xwork), but we really need to branch 1.3 to keep it clean of new stuff so we can develop against the head. If we end up needing to release 1.3.1 or somesuch to fix bugs, then we'll need the 1.3 source tree as a base to work from without keeping people from moving forward. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone:585.240.2793 fax:585.272.8118 email:[EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Locale Property Editor
I have just finished writing a FastPropertyEditor for java.util.Locales. Would this be useful to add to the webwork code? If so I can contribute it. Geoff --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Velocity for View Tags
Hello, Scott Farquhar wrote: (Also available here: http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-111) I have looked at changing the view tags over to velocity, and it is looking very promising. I have attached the text.vm text.jsp files for a comparison, and it cleans the code up quite a bit. Great! As a first step, all the views can be duplicated in velocity, and then use the VelocityServlet to include them. This will not reduce the overhead of the rd.include() but will reduce the time for the included page to be parsed. I have completed (committed) this added a corresponding '.vm' file for most ui tags. You need to change 'webwork.ui.templateSuffix' to 'vm' and you need to map the WebWorkVelocityServlet to '*.vm'. I have tested the examples, but nothing further. However, when working through this, I came to a few problems: - Getting the value from the top of the valueStack. This is usually obtained with a . or a null value passed to stack.findValue(). However, in velocity, all values must start with a character. Are their any other synonyms for the current value that I don't know about? Can we add one? The bigger problems is the VS isn't exposed in templates so it should be exposed in some manner. I can think of a couple of ways to do this. In WebWorkVelocityServlet just put the VS into the VelocityContext as vs, valuestack, stack, etc. For example: Index: src/main/webwork/view/velocity/WebWorkVelocityServlet.java === RCS file: /cvsroot/opensymphony/webwork/src/main/webwork/view/velocity/WebWorkVelocityServlet.java,v retrieving revision 1.4 diff -u -r1.4 WebWorkVelocityServlet.java --- src/main/webwork/view/velocity/WebWorkVelocityServlet.java 15 Sep 2002 02:02:33 - 1.4 +++ src/main/webwork/view/velocity/WebWorkVelocityServlet.java 28 Jan 2003 18:28:09 - @@ -157,6 +157,7 @@ Context ctx = new WebWorkVelocityContext(ServletValueStack.getStack(request)); ctx.put(REQUEST, request); ctx.put(RESPONSE, response); + ctx.put(stack, ServletValueStack.getStack(request)); return ctx; } If exposing the VS under $webwork is preferred, another option would be to make WebWorkUtil into a facade for the ValueStack class. Then you would use in your templates: $webwork.findValue(.). Using WebWorkUtil would also allow creation of helper methods to the VS. For instance, $webwork.current - calls a getCurrent method returning vs.findValue(.) $webwork.parent - calls a getParent method returning vs.findValue(..) - Getting the templates (using servletPath). Some servlet containers have problems with getRealPath(). We can always bundle default templates in the jar (a plus), but how do we access the templates? Rickard seems to do it with his WebWorkVelocityServlet - but I'm not sure how. You really need to check out the Velocity Tools project (http://jakarta.apache.org/velocity/toolsubproject.html). There in as enhanced VelocityViewServlet that uses a Resource Loader (WebappLoader) so templates are loaded via ServletContext.getResourceAsStream rather than relative to getRealPath. This also allows templates being pulled from a .war if the container supports it. See WebappLoader at http://cvs.apache.org/viewcvs/jakarta-velocity-tools/view/src/java/org/apache/velocity/tools/view/servlet/WebappLoader.java?rev=1.1.1.1content-type=text/vnd.viewcvs-markup and VelocityViewServlet which calls it at http://cvs.apache.org/viewcvs/jakarta-velocity-tools/view/src/java/org/apache/velocity/tools/view/servlet/VelocityViewServlet.java?rev=1.6content-type=text/vnd.viewcvs-markup. In the short run, you could use the WebappLoader from within the WebWorkVelocityServlet. Longer term when the Velocity Tools project has a release, it may make sense to base WWVS on VelocityViewServlet so the toolbox stuff will be available. -Bill --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Releasing 1.3 and new development
+1 to all of that. Who wants to (and knows how to) create a branch? -Original Message- From: Kirk Rasmussen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Releasing 1.3 and new development I am in total agreement. A stable 1.3 branch is definitely needed. I think it would be very confusing for a new WW user to be expected to pull from the CVS head when the head potentially changes minute by minute. The 1.2 release has been totally ignored because work continued on the head to create the 1.3 release. IMO the feature sets should be better defined with specific goals so that developers know when a release is ready to be baked. I might be wrong but it seems that 1.3 was arbitrarily created because its been long enough since the 1.2 release. Consistent logging, performance enhancements and stability seems to be the goals of 1.3 from what I can tell. I an very confident that myself and several others on this list would help to maintain the 1.3 branch if necessary. BTW great job guys! WW does indeed rock! Regards, Kirk Rasmussen Lucasfilm Ltd. -Original Message- From: Jason Carreira [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 7:36 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Releasing 1.3 and new development Nononono you misunderstood. My bad. I want to branch 1.3 to be able to do bug fixes for any future 1.3.x releases. I want to keep the CVS head for continuing development and new features with a view to a 1.4 release. Xwork 1.0 and Webwork 2.0 can, and should, remain in the sandbox for now, until a LOT of issues are worked out and it's been fleshed out to do everything that WW 1.3 does. My point was really to be able to get back to 1.3 for bug fixes while not keeping people from continuing to develop against the CVS head. I'm not terribly comfortable with CVS, so I was throwing this out for someone to do. If we were using Perforce, I would create a branch, because branching is fast and low cost and it's how you do most code management in P4. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Releasing 1.3 and new development I like webwork head cvs, and want to see it keep moving forward. We can tag a release (1.3) anytime now, really. Only thing that perhaps needs doing is updating some of the docs, and having decent release notes. xwork is still sandbox, and is nowhere near production worthy (right?) and I'd much rather than those of us who enjoy webwork and contributing to it don't end up feeling like second class citizens in favour of xwork. Quoting Jason Carreira [EMAIL PROTECTED]: People have been adding new stuff, like the Velocity based templates, while the head is still (as far as I know) supposed to be 1.3 RC2. I like new stuff (see Xwork), but we really need to branch 1.3 to keep it clean of new stuff so we can develop against the head. If we end up needing to release 1.3.1 or somesuch to fix bugs, then we'll need the 1.3 source tree as a base to work from without keeping people from moving forward. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webw ork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
RE: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Just off the top of my head... Doesn't FreeMarker have a macro language similar to Velocity? I believe you could write custom functions to access the ValueStack. I was actually thinking about doing the FreeMarker integration just last week. Once I get some spare time I might look into this. Regards, Kirk Rasmussen Lucasfilm Ltd. -Original Message- From: James Cook [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 11:46 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags The one thing that may prevent FreeMarker from being drop-in replacement for the WebWork JSP is the expression language supported by the WebWork taglibs. It also affects JSTL integration and Velocity integration. It concerns the hierarchical nature of the ValueStack. Most of these third-party view technologies don't understand the concept of '../name'. We use WebWork/Velocity on a huge project and have never had any need for this syntax, but some WebWork developers (I guess) use the hierarchical ValueStack quite often. Since you own the FreeMarker syntax and can modify it, perhaps you may want to include such constructs. On Tuesday, January 28, 2003, at 01:59 PM, Attila Szegedi wrote: Actually if I understand it right, the integration is quite trivial. We have a Model2-compliant view servlet bundled into the core distribution. It lets templates access request, session, and servlet context attributes. It also lets templates use any JSP taglib present in the webapp. Therefore it is pretty much a drop-in replacement for JSP as far as WebWork is concerned. Is there anything else codewise that should be done for integration? (My feeling is that there isn't, but please correct me if there are some gotchas). --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
- Original Message - From: James Cook [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 8:46 PM Subject: Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags The one thing that may prevent FreeMarker from being drop-in replacement for the WebWork JSP is the expression language supported by the WebWork taglibs. If the WebWork tag expects these expressions to be passed to it as plain string attributes, then it's no problem. I know JSP 2.0 will have container-evaluated expressions, but for now we support the JSP 1.2 spec so we're just calling property setters for tag attributes. It also affects JSTL integration and Velocity integration. It concerns the hierarchical nature of the ValueStack. Most of these third-party view technologies don't understand the concept of '../name'. Depends on where. FM's own include and import directives do understand .. when resolving the template name to include. But maybe I'm talking nonsense - I'll take a closer look at the expression language and WW stacks to see if something rings an alert in my head. Thanks for bringing it to my attention. We use WebWork/Velocity on a huge project and have never had any need for this syntax, but some WebWork developers (I guess) use the hierarchical ValueStack quite often. Since you own the FreeMarker syntax and can modify it, perhaps you may want to include such constructs. I'll take a closer look at it. Cheers, Attila. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
- Original Message - From: Kirk Rasmussen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 8:59 PM Subject: RE: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags Just off the top of my head... Doesn't FreeMarker have a macro language similar to Velocity? I believe you could write custom functions to access the ValueStack. Undoubtedly. Alternatively, since (that's why I brought up the issue originally) FreeMarker can now host JSP custom tag libraries, the existing taglibs that manipulate the value stack can be used without modifications. Altough it might be that a WW-specialized FM-data models could be created for performance reasons... I was actually thinking about doing the FreeMarker integration just last week. Once I get some spare time I might look into this. That'd be way cool. Cheers, Attila. Regards, Kirk Rasmussen Lucasfilm Ltd. You use WW and/or FM at Lucasfilm? Wow. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags
Hello, Attila Szegedi wrote: - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 6:48 PM Subject: Re: [OS-webwork] Freemarker WAS Using SiteMesh for the UI tags snip/ Actually if I understand it right, the integration is quite trivial. We have a Model2-compliant view servlet bundled into the core distribution. It lets templates access request, session, and servlet context attributes. It also lets templates use any JSP taglib present in the webapp. Therefore it is pretty much a drop-in replacement for JSP as far as WebWork is concerned. Is there anything else codewise that should be done for integration? (My feeling is that there isn't, but please correct me if there are some gotchas). Although you could call the WW JSP tags, in many cases this won't make sense. For instance, you will want to use the FM if tag, not the ww:if tag. Velocity doesn't support the WW expression language. FM may not need to support it (much) either. IF FM has something like Velocity's context chaining, you could transparently support finding objects on the ValueStack. See WebWorkVelocityServlet. For more specific access to the ValueStack, it should be put into the context so one can call specific methods to access or manipulate the stack. I just posted a couple of suggested ways this could be done for Velocity. I guess all it takes is adding another chapter to WebWork documentation that shows how to set up FreeMarker's built-in view servlet in the build.xml and maybe a small example. I can prepare this documentation if you're willing to place it into the Supported Views chapter. For examples, you will also want to implement the monthlist example plus some more substantive ones if possible. Cheers, Attila. /Rickard -Bill --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Re: Freemarker WAS Using SiteMesh for the UI tags
Francois Beauregard wrote: I was not aware of that fact. You are right. OpenSymphony seem to have got lately to a point where there is a good exchange of ideas and the community moves forward. This must stay the way it is right now. Do you remeber the reasons for the ranting? François, I don't believe that you should take Rickard's account of what happened as definitive, particularly when there is a complete electronic record of all of this that anybody can look at. In the following post, a velocity users asks about monetary values in a velocity template. At some point in the thread, I respond. Here is the initial post of that thread, entitled Comparing Monetary Value. http://www.mail-archive.com/velocity-user@jakarta.apache.org/ msg08355.html Here is my initial contribution to the thread and thus, I suppose, this is an example of my ranting: http://www.mail-archive.com/velocity-user@jakarta.apache.org/ msg08366.html I would encourage you to read through the whole thread and how it developed. It actually becomes piquant. Quite entertaining stuff. But I think you'll see that Rickard's characterization of what happened is pretty stretched. What you'll see is that various people attempt to engage me in debate and then, when they end up looking foolish *but fairly, in legitimate technical debate* they then start the attacks on my person. And then they later claim (quite mendaciously, of course) that I was the one engaging in personal attacks on them!!! Yes, his belief that FreeMarker was the ultimate solution and that he was entitled to telling everyone of this regardless of everyone on the list begging for the opposite. To be clear, I see no real problem with telling people about FreeMarker on a Velocity mailing list. There are 2 key reasons for this: 1. Velocity is a monumentally mediocre piece of work that only receives the level of usage and attention that it does because it is part of apache.org. Since there is such a huge disparity in the visibility of Velocity and something like FreeMarker, I have no compunctions about mentioning FreeMarker on the Velocity list, no more than I would in mentioning FreeMarker on a list devoted to JSP. In any case, my behavior there may have its obnoxious side. Fine. Okay BUT... but what is the basic grievance? At the end of the day, the end-user can always choose to use whichever tool suits him best. You may also note that my posts were invariably factual and could have been helpful to anybody making such a decision. It appears that the Velocity community did not want anybody making comparisons. 2. Velocity developers have engaged in this kind of behavior themselves on the webmacro mailing list. This was particularly obnoxious because, of course Velocity is little more than a rip-off clone of Webmacro in the first place. In fact, the origin of it is that Webmacro was supposed to be an apache project, but there was some falling out between Jon Stevens and Justin Wells and Jon Stevens started the webmacro clone that became velocity. But anyway, given the history, the velocity developers are very poorly placed to scream and holler about me showing up on their mailing list. You see, they have bad karma... It was (to me) quite disgusting. Well, I'm glad you put the to me there in parentheses. I am quite convinced that some people derived vicarious pleasure from it. :-) But anyway, I very honestly do not want to start a flamewar here. I don't have the time for it and I don't have any quarrel with anyone here. In fact, I have little intention of participating much more on this list. But here's the key point: Look, there's a complete electronic record of all of this. Go look at it and see if Rickard's characterization of my 'ranting' is accurate. That's pretty reasonable, huh? Best Regards, Jonathan Revusky -- Lead developer, FreeMarker project http://freemarker.org/ /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Re: Example war file problems
On Tue, Jan 28, 2003 at 04:56:23PM -0800, Chris Nokleberg wrote: I was going to attempt to write a WebWorkFreemarkerServlet, but got stuck pretty early on. Checked out webwork fresh from cvs, ant war, copied to tomcat 4.1.18 webapps directory, and I get the following: Actually, it *does* work when I copy the war file manually to the webapps directory, but fails when I use the tomcat manager application or ant tasks to install or deploy the webapp. I imagine there is a resource loading issue, maybe WebWork is using getRealPath when it should be using ServletContext or something. -Chris --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Freemarker WAS Using SiteMesh for the UI tags
Jonathan Revusky wrote: François, I don't believe that you should take Rickard's account of what happened as definitive, particularly when there is a complete electronic record of all of this that anybody can look at. Absolutely, go read it. In the following post, a velocity users asks about monetary values in a velocity template. At some point in the thread, I respond. Here is the initial post of that thread, entitled Comparing Monetary Value. http://www.mail-archive.com/velocity-user@jakarta.apache.org/ msg08355.html Here is my initial contribution to the thread and thus, I suppose, this is an example of my ranting: http://www.mail-archive.com/velocity-user@jakarta.apache.org/ msg08366.html Not really, but it's a good start. I would encourage you to read through the whole thread and how it developed. It actually becomes piquant. Quite entertaining stuff. But I think you'll see that Rickard's characterization of what happened is pretty stretched. What you'll see is that various people attempt to engage me in debate and then, when they end up looking foolish *but fairly, in legitimate technical debate* they then start the attacks on my person. And then they later claim (quite mendaciously, of course) that I was the one engaging in personal attacks on them!!! As Jonathan said, read the thread. Yes, his belief that FreeMarker was the ultimate solution and that he was entitled to telling everyone of this regardless of everyone on the list begging for the opposite. To be clear, I see no real problem with telling people about FreeMarker on a Velocity mailing list. There are 2 key reasons for this: 1. Velocity is a monumentally mediocre piece of work that only receives the level of usage and attention that it does because it is part of apache.org. Since there is such a huge disparity in the visibility of Velocity and something like FreeMarker, I have no compunctions about mentioning FreeMarker on the Velocity list, no more than I would in mentioning FreeMarker on a list devoted to JSP. In any case, my behavior there may have its obnoxious side. Fine. Okay BUT... but what is the basic grievance? At the end of the day, the end-user can always choose to use whichever tool suits him best. You may also note that my posts were invariably factual and could have been helpful to anybody making such a decision. It appears that the Velocity community did not want anybody making comparisons. What an eloquant way to say I have the right to say whatever I want, wherever I want, whenever I want, no matter what anyone else thinks. It's really fine up until the very last point. Your above reasoning would allow us to go to the Struts list to explain to them what a monumentally mediocre piece of work they have, which get the level of usage and attention that it does because it is a part of apache.org. Factually correct (one could argue), but oh so irrelevant. I guess we will just have to agree on disagreeing on this point. 2. Velocity developers have engaged in this kind of behavior themselves on the webmacro mailing list. This was particularly obnoxious because, of course Velocity is little more than a rip-off clone of Webmacro in the first place. In fact, the origin of it is that Webmacro was supposed to be an apache project, but there was some falling out between Jon Stevens and Justin Wells and Jon Stevens started the webmacro clone that became velocity. But anyway, given the history, the velocity developers are very poorly placed to scream and holler about me showing up on their mailing list. You see, they have bad karma... In other words, if someone else is a prick you have the right to be a prick too. Interesting logic, and again I guess we will just have to agree on disagreeing on this point. It was (to me) quite disgusting. Well, I'm glad you put the to me there in parentheses. I am quite convinced that some people derived vicarious pleasure from it. :-) Absolutely: you seemed to have fun. That's why I added to me, because I had a hunch that you'd disagree. But anyway, I very honestly do not want to start a flamewar here. I don't have the time for it and I don't have any quarrel with anyone here. In fact, I have little intention of participating much more on this list. But here's the key point: Look, there's a complete electronic record of all of this. Go look at it and see if Rickard's characterization of my 'ranting' is accurate. That's pretty reasonable, huh? Sure enough. And ironically, your post is an excellent example of the kind of stuff I want to avoid in OpenSymphony. Now back to our regular programming. regards, Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
