RE: [OS-webwork] RC2?

2003-01-17 Thread Vedovato Paolo 



can 
the modification of the url tag be considered (see corresponding thread and the 
proposal of eric) for RC2?
 
-paolo
 
 

  -Original Message-From: matt baldree 
  [mailto:[EMAIL PROTECTED]]Sent: Friday, January 17, 2003 1:34 
  AMTo: [EMAIL PROTECTED]Subject: 
  [OS-webwork] RC2?
  Are we ready to push out another release 
  candidate? I think it would be nice to get the recent performance patches out 
  the door.
   
  -Matt

Re: [OS-webwork] Hidden token

2003-01-17 Thread Joseph Ottinger 
I resigned from formal association with OpenSymphony. I no longer have or
want CVS update access, or web site update capabilities, although I can
update the wiki and offer input on issues just like other users can.
What's more, since I used to be somewhat responsible for the care and
feeding of OpenSymphony, I have its best interests at heart. What better
input can there be than that of an experienced, caring user?

On Fri, 17 Jan 2003, [ISO-8859-1] Rickard Öberg wrote:

> Joseph Ottinger wrote:
> > I'd prefer adding it to the wiki or the current release of WW, since there
> > are some users who actually use what's there now as opposed to vapourware,
> > even though the vapourware is promising.
>
> Didn't you resign from OpenSymphony? Or was it just that you stopped
> doing things?
>
> /Rickard
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> ___
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>

-
Joseph B. Ottinger [EMAIL PROTECTED]
http://enigmastation.comIT Consultant



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

RE: [OS-webwork] Hidden token

2003-01-17 Thread Vedovato Paolo 
that is a very important feature that should get ASAP into current
webwork...so what can be added now (automatic or manually) should be added

cheers
-paolo

>-Original Message-
>From: matt baldree [mailto:[EMAIL PROTECTED]]
>Sent: Friday, January 17, 2003 1:27 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [OS-webwork] Hidden token
>
>
>I have the code ;). I can add it if it is what people want but 
>Rickard has a
>point in trying to make this more automatic without adding a 
>manual field. I
>guess we could have the old fashion way and if/when the 
>portlet framework
>develops we can use it.
>
>-Matt
>
>- Original Message -
>From: "Robert Nicholson" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Thursday, January 16, 2003 4:48 PM
>Subject: Re: [OS-webwork] Hidden token
>
>
>> Does that field also put the token into the session? Where's the code
>> that
>> adds the token to the session?
>>
>> On Thursday, January 16, 2003, at 01:23  AM, matt baldree wrote:
>>
>> > no just added a hidden input field. this really isn't a ui tag.
>> >
>> > - Original Message -
>> > From: "Jason Carreira" <[EMAIL PROTECTED]>
>> > To: <[EMAIL PROTECTED]>
>> > Sent: Wednesday, January 15, 2003 6:40 PM
>> > Subject: RE: [OS-webwork] Hidden token
>> >
>> >
>> > Did you modify the ui tags to automatically do this? I also added a
>> > Jira
>> > issue for this
>> >
>> >> -Original Message-
>> >> From: matt baldree [mailto:[EMAIL PROTECTED]]
>> >> Sent: Wednesday, January 15, 2003 7:44 PM
>> >> To: [EMAIL PROTECTED]
>> >> Subject: Re: [OS-webwork] Hidden token
>> >>
>> >>
>> >> my project. i can add it when i get a chance.
>> >>
>> >> - Original Message -
>> >> From: "Jason Carreira" <[EMAIL PROTECTED]>
>> >> To: <[EMAIL PROTECTED]>
>> >> Sent: Wednesday, January 15, 2003 6:10 PM
>> >> Subject: RE: [OS-webwork] Hidden token
>> >>
>> >>
>> >> In WW? Is this already there? Or did you do this in your project?
>> >>
>> >>> -Original Message-
>> >>> From: matt baldree [mailto:[EMAIL PROTECTED]]
>> >>> Sent: Wednesday, January 15, 2003 6:05 PM
>> >>> To: [EMAIL PROTECTED]
>> >>> Subject: Re: [OS-webwork] Hidden token
>> >>>
>> >>>
>> >>> yes, this is how we did it.
>> >>>
>> >>> - Original Message -
>> >>> From: "Jason Carreira" <[EMAIL PROTECTED]>
>> >>> To: <[EMAIL PROTECTED]>
>> >>> Sent: Wednesday, January 15, 2003 3:48 PM
>> >>> Subject: RE: [OS-webwork] Hidden token
>> >>>
>> >>>
>> >>> Just thought this out some more. Here's how it could work:
>> >>>
>> >>> the hidden token is set in the session when the form is
>> >>> shown, then added to the form as a hidden field. When the
>> >>> action processes the form, you look for the token and make
>> >>> sure it's the same as the last one you put in the session
>> >>> before you process.
>> >>>
>> >>> Jason
>> >>>
>>  -Original Message-
>>  From: Jason Carreira
>>  Sent: Wednesday, January 15, 2003 4:04 PM
>>  To: [EMAIL PROTECTED]
>>  Subject: [OS-webwork] Hidden token
>> 
>> 
>>  Hi all,
>> 
>>  In our evaluation of Struts vs. Webwork, I was asked about the
>>  ability to do hidden tokens on WW built forms and URLs. Struts
>>  apparently, in their form and link tags, have the possibility of
>>  (optionally) adding a hidden token (either as a hidden
>> >> form field,
>>  or through URL rewriting), which can keep the user from clicking
>>  twice and executing your action twice. I don't remember seeing
>>  anything like this in WW, although my take is that this would be
>>  easy enough to add to the URLTag. Also, is there a
>> >> ui:form tag? I'm
>>  not sure what all got added.
>> 
>>  I remember Rickard was talking about something to prevent
>> >> 2 submits,
>>  but I'm not sure what it was...
>> 
>>  Thoughts? Would this be something good to add (given that
>> >> it would
>>  be optional and not break anybodies existing code)?
>> 
>>  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: A Thawte Code Signing
>> >> Certificate
>>  is essential in establishing user confidence by providing
>> >> assurance
>>  of authenticity and code integrity. Download our Free Code
>>  Signing guide:
>>  http://ads.sourceforge.net/cgi-> bin/redirect.pl?thaw0028en
>> 
>> 
>>  ___
>>  Opensymphony-webwork mailing list
>>  [EMAIL PROTECTED]
>>  
>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>> 
>> >>>
>> >>>
>> >>> ---
>> >>> This SF.NET email is sponsored by: A Thawte Co

Re: [OS-webwork] Hidden token

2003-01-17 Thread Rickard Öberg 
Vedovato Paolo wrote:

that is a very important feature that should get ASAP into current
webwork...so what can be added now (automatic or manually) should be added


Sure, but what if we go with the automatic system later on? Then 
there'll be whining and cursing, as usual.

/Rickard



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Re: [OS-webwork] Hidden token

2003-01-17 Thread Patrick Lightbody 
Well, from my part, I'll toy with getting it in sandbox right away.

- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 12:36 AM
Subject: Re: [OS-webwork] Hidden token


> Vedovato Paolo wrote:
> > that is a very important feature that should get ASAP into current
> > webwork...so what can be added now (automatic or manually) should be
added
>
> Sure, but what if we go with the automatic system later on? Then
> there'll be whining and cursing, as usual.
>
> /Rickard
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by
implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> ___
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

[OS-webwork] webwork.util.editor handling of null

2003-01-17 Thread Dick Zetterberg 
Hi,

I just noticed that some developer (I believe the CVS name was "salaman")
had made changes to all the property editors after the 1.3RC1.
Those changes were now overwritten when Patrick submitted my contributions
for the new thread safe editors.

The changes made by "salaman" was that in the setAsText method there was an
added check for null values or empty strings. In that case the value was set
to null instead of throwing an IllegalArgumentException. Like this:

public void setAsText(String txt) {
if (txt==null || txt.equals(""))
{
   setValue(null);
   return;
}
try {
  ...

This is a perfectly reasonable change (I use similar code in my own property
editors), but it is not completely backwards compatible, since no
IllegalArgumentException will be thrown for null values anymore. It should
not be used for primitive types of course.
So the question is: should this be re-implemented for the new 1.3 release? I
would say no, because of backwards compatibility problems.
Opinions anyone? Salaman?

Cheers,

Dick

[EMAIL PROTECTED]



---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

RE: [OS-webwork] Woohoo!

2003-01-17 Thread Jason Carreira 
Title: Message



Well, 
it really came down to usability issues. We looked at things like having to have 
separate FormBeans tied to the Actions 1-1 (because you have to cast to the 
expected FormBean subclass). Also, we looked at some sample code for Struts 
and Webwork (we looked at code for Chiki, a Wiki implemented with Struts, and 
Jira. Thanks Mike for having clean code!). It was very apparent that you had to 
do a lot of busy work to initialize things and do the setup that the framework 
should have done for you in Struts, whereas in Webwork, it was pretty much all 
business code. Command driven actions were also a big hit, as our lead architect 
came from a Next background, and apparently they did code like that all the 
time. In general, I think it was just a general feeling that Webwork was better 
abstracted and architected than Struts.
 
Other 
advantages, like the ValueStack and the expression language, were less easy to 
express, since they hadn't begun to use them yet.  
 
Some 
of the concerns were (in no order):
 
-Less 
userbase - I pointed out that with a smaller project we have a better chance of 
making changes and making WW do what we need
-JSTL 
and JSF support 
-tool 
support

  
  -Original Message-From: Volkmann, Mark 
  [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 
  2003 5:52 PMTo: 
  '[EMAIL PROTECTED]'Subject: RE: 
  [OS-webwork] Woohoo!
  Can you share with us the justification you used for using 
  WebWork instead of Struts?  Others may find it useful.  Perhaps 
  you've already done that and I accidently deleted the email.  If so, 
  could you resend it to me?
  > -Original Message- > 
  From: Jason Carreira [mailto:[EMAIL PROTECTED]] 
  > Sent: Thursday, January 16, 2003 3:13 PM 
  > To: [EMAIL PROTECTED] 
  > Subject: [OS-webwork] Woohoo! > > > So we 
  had our Webwork vs. Struts talk today, and I was able > to convince > people here that there 
  was sufficiently enough better about WW to make > 
  us use it instead of Struts, even though Struts is the "standard", of 
  > sorts! Cool. > 
  > Off to catch a plane home... > > -- > 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: Thawte.com > Understand how to protect your customers personal information 
  > by implementing > SSL 
  on your Apache Web Server. Click here to get our FREE > Thawte Apache > Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en 
  > ___ 
  > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork 
  > ***WARNING: 
  All e-mail sent to and from this address will be received orotherwise 
  recorded by the A.G. Edwards corporate e-mail system and issubject to 
  archival, monitoring or review by, and/or disclosure to,someone other than 
  the 
  recipient.

RE: [OS-webwork] Hidden token

2003-01-17 Thread Jason Carreira 
> -Original Message-
> From: Robert Nicholson [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, January 16, 2003 5:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Hidden token
> 
> 
> I think the only reason Struts needs the ui:form is to associate the 
> form to the form bean.
> 
> I'm against the idea of a ui:form tag. ie. mandatory use of 
> WW UI tags 
> for proper behaviour.
> 
> Struts form beans don't work unless you use their UI tags.
> 
>> 

I was proposing the ww:form tag only to do this (the hidden token) for
you. I believe Rickard's proposed method will also require this (or
would you do ?)

I suppose we could also have the token creation be in a util action that
would populate the session, and you could call it from the jsp using
ww:action as well.


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

RE: [OS-webwork] Hidden token

2003-01-17 Thread Jason Carreira 
> -Original Message-
> From: Robert Nicholson [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, January 16, 2003 5:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Hidden token
> 
> 
> If I quickly hit the the submit button twice what happens?
> 
> What guarantee is there that the execution of both actions isn't 
> interleaved?
> 

Well, the first thing the action would do is check the token and remove
it from the session. Is access to the session thread safe? Either way,
you'd want to synchronize the read and clear of the token (or temporary
URL), and whichever one got it first would succeed. 


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

RE: [OS-webwork] Hidden token

2003-01-17 Thread Jason Carreira 
> -Original Message-
> From: matt baldree [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, January 16, 2003 7:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Hidden token
> 
> 
> I have the code ;). I can add it if it is what people want 
> but Rickard has a point in trying to make this more automatic 
> without adding a manual field. I guess we could have the old 
> fashion way and if/when the portlet framework develops we can use it.
> 
> -Matt
> 

Does the automatic way support both problem conditions: 1) reloading the
result page and thereby re-posting the form data, and 2) the user
hitting the back button and submitting the form again. I think it does,
and I'm sure the hidden token does, but I wanted to check for sure.


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Re: [OS-webwork] Hidden token

2003-01-17 Thread Rickard Öberg 
Jason Carreira wrote:

Does the automatic way support both problem conditions: 1) reloading the
result page and thereby re-posting the form data, and 2) the user
hitting the back button and submitting the form again. I think it does,
and I'm sure the hidden token does, but I wanted to check for sure.


It does. It's basically the same idea, except there's no token being 
sent. The *URL* being invoked is the "token" instead.

/Rickard




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

[OS-webwork] [OFFTOPIC] more ranting - maven

2003-01-17 Thread Hani Suleiman 
This is an offtopic post. It's not really related to webwork, and is probably 
going to be unpleasant, so those of you with sensitive dispositions, hit delete 
now...

So I find myself having to use maven to build a project (jira in this case). 
This is something I was not looking forward to, but I thought well everyone 
says how great maven is, so surely it'll be a smooth experience.

First obstacle, everyone says to use the cvs version. Of course there are no 
nightly builds or snapshots. No problem, I grab it all from cvs. A quick browse 
of their instructions says all I have to do is set an env var (nevermind that 
env vars and java are a bad idea), and run a bootstrap build file. All 
deceptively clear and straightforward.

Needless to say, my attempts resulted in nothing more than abysmal failures. My 
first attempt was on OSX, and to my surprise, the buildfile told me I had to 
set JAVA_HOME. It goes without saying that all other ant buildfiles work 
flawlessly, and none demand JAVA_HOME (and those that do need it are able to 
figure it out automagically easily enough). After that of course the build 
failed horribly, with a mile or two of stacktraces. I shrug and think 'ohwell, 
it's a bunch of people who think java==windows, I'll try later on a windows 
box'.

Onto the windows box. The build does indeed progress a bit further, but of 
course dies horribly during one of the tests. As part of the dying process, it 
cleans out everything that's been built. How...considerate. Miles of stack 
traces ensue. The stack traces themselves meander about all over the place, in 
and out of ant code, commons-jelly, werkz, maven, etc etc.

All the 'support' jar files are some kind of cvs snapshot for the 20 or so 
dependencies maven has.

One day, maven might be a good tool. Right now though, it seems suicidal to me 
to basically rely on over a dozen unrelated projects (most of which are just 
cvs snapshots) just to build a project. Maven is not a successor to ant nor is 
it a superset, it's ant as perverted by an evil scientist. Those who like wires 
hanging out everywhere, testtubes with many colourful substances (half of which 
are lethal), and the odd crazy cackle hurled your way would find maven a 
tremendously enjoyable and satisfying experience.

Everyone else though probablywouldn't.

Maybe it's all my fault/incompetence though, and I AM willing to concede that I 
might have missed some crucial step that the docs mention. However, I still 
feel that it shouldn't be quite so easy to end up with a completely non-
functional bloated pile of jakarta vomit.

Apolegetically,

Hani




---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

[OS-webwork] BeanUtil copy method efficiency

2003-01-17 Thread Robert Nicholson 
I've been looking at BeanUtil.java and I was looking at the copy method.

given that the fieldMaps are cached in objectMap wouldn't it make more 
sense
to use

static protected PropertyDescriptor getPropertyDescriptor(String 
property, Ob
ject obj)

instead of the inner loop?

Couldn't you do a lookup for pdTo with

BeanUtil.getPropertyDescriptor(pdFrom.getName(), to);

 public static void copy(Object from, Object to, boolean includeNull)
  throws IllegalArgumentException
   {
  try
  {
 Object[] readParameters = new Object[0];
 Object[] writeParameters = new Object[1];
 PropertyDescriptor[] propertiesFrom = 
getPropertyDescriptors(from.getCl
ass());
 PropertyDescriptor[] propertiesTo = 
getPropertyDescriptors(to.getClass(
));
 for (int i = 0; i < propertiesFrom.length; i++)
 {
PropertyDescriptor pdFrom = propertiesFrom[i];
for (int j = 0; j < propertiesTo.length; j++)
{
   PropertyDescriptor pdTo = propertiesTo[j];
   if (pdFrom.getName().equals(pdTo.getName()))
   {
  Method readMethod = pdFrom.getReadMethod();
  Method writeMethod = pdTo.getWriteMethod();
  if (writeMethod != null && readMethod != null)
  {
 writeParameters[0] = 
pdFrom.getReadMethod().invoke(from, re
adParameters);
 if (!(!includeNull && writeParameters[0] == null))
pdTo.getWriteMethod().invoke(to, 
writeParameters);
  }
  break;
   }
}
 }
  } catch (Exception e)
  {
 log.warn("Bean copy failed:"+e, e);
 throw new IllegalArgumentException("Bean copy failed:" + e);
  }
   }



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Re: [OS-webwork] Woohoo!

2003-01-17 Thread Robert Nicholson 
Who's your lead architect? I also come from a NeXT background.



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Re: [OS-webwork] [OFFTOPIC] more ranting - maven

2003-01-17 Thread Robert Nicholson 
I'm a little confused. Isn't JIRA commercial software?



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Re: [OS-webwork] [OFFTOPIC] more ranting - maven

2003-01-17 Thread Konstantin Priblouda 
>I'm a little confused. Isn't JIRA commercial
software?

Yes, it is.  But atlassian provides it to  lot of
opensource projects. And by conincidence a lot
of atlassian people are really active in opensource
projects. Included but not limited to opensymphony...

regards,

=
Konstantin Priblouda ( ko5tik )Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Re: [OS-webwork] webwork.util.editor handling of null

2003-01-17 Thread Patrick Lightbody 
Odd that Victor Salaman was the last one to have changed those, he hasn't
worked on WebWork in _ages_. I think setting to null would be a good idea,
the errors reported back by the PropertyEditors were pretty lame anyway
("Could not set value for").

-Pat

- Original Message -
From: "Dick Zetterberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 2:55 AM
Subject: [OS-webwork] webwork.util.editor handling of null


> Hi,
>
> I just noticed that some developer (I believe the CVS name was "salaman")
> had made changes to all the property editors after the 1.3RC1.
> Those changes were now overwritten when Patrick submitted my contributions
> for the new thread safe editors.
>
> The changes made by "salaman" was that in the setAsText method there was
an
> added check for null values or empty strings. In that case the value was
set
> to null instead of throwing an IllegalArgumentException. Like this:
>
> public void setAsText(String txt) {
> if (txt==null || txt.equals(""))
> {
>setValue(null);
>return;
> }
> try {
>   ...
>
> This is a perfectly reasonable change (I use similar code in my own
property
> editors), but it is not completely backwards compatible, since no
> IllegalArgumentException will be thrown for null values anymore. It should
> not be used for primitive types of course.
> So the question is: should this be re-implemented for the new 1.3 release?
I
> would say no, because of backwards compatibility problems.
> Opinions anyone? Salaman?
>
> Cheers,
>
> Dick
>
> [EMAIL PROTECTED]
>
>
>
> ---
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by
implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> ___
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork



---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

RE: A plea - WAS Re: [OS-webwork] Reflection

2003-01-17 Thread Blake Day 
+1+1+1

Michael Blake Day
Artistry Studios - e-commerce design, implementation and hosting
email: [EMAIL PROTECTED] 
mobile: 770.480.1547


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Rickard Oberg
Sent: Monday, January 13, 2003 2:30 AM
To: [EMAIL PROTECTED]
Subject: Re: A plea - WAS Re: [OS-webwork] Reflection


Mike Cannon-Brookes wrote:
> Some points that people seem to be forgetting:
> - Xwork is in the SANDBOX and is eXperimental (if you like the X for that)
> - Nothing in Xwork can't be changed, these are ideas, prototypes
> - Xwork will be better for 'web work' than WebWork is!
> - Xwork will be better for 'non web work' than WebWork is, _WITHOUT_
> impacting people who don't care for 'non web work'

But the experimental sandbox is not emerging out of thin air. It is
based on ideas, which are molded through various requirements. If there
are two different sets of requirements, they lead to different ideas
which lead to different code. If we can't agree on the requirements
(a.k.a. goals), then that is much more important to discover than
"writing cool code" and THEN discovering that we're not after the same
thing.

That WebWork turned out to be a generic command pattern was more of an
accident then by design. Because of this genericity WebWork is not
optimally designed for doing web work. Some of the "plumbing" needs to
be done by actions themselves, instead of having it be done by the
framework. I want to make WebWork/XWork *better* suited for the web,
because that is what *I* *need*. I want to get more for less. I don't
give a damn about making it work well in Swing. If it does, then
whaddyaknow, cool. If it doesn't, shit happens. If there's ever a point
where I need to decide between "keeping genericity, or making it work
better for the web", the latter is a given. My recent emails have
explained some of what I want to do in this area (introducing packages
and components for example). Some of those are VERY web-centric, and
that *IS THE POINT*.

MAYBE it will never come to the point where there's such a decision, but
there is a clear difference in what happens at that point in these two
projects. In WebWork it is clear that if a decision benefits the web,
then the web option it is. In XWork it is equally clear that if a
decision may benefit the web but not Swing/EmailDispatcher/XDispatcher,
then the generic option it is. This is how we have talked about the
differences between WebWork and XWork, and this is the consequence of
such different goals. I personally prefer the WebWork option, always. If
you don't agree with my conclusions, then we have a different view of
what the purpose of XWork is. I'm just going by what we have said are
the intentions of this project.

/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





---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork