webwork-devel — WebWork development

[Webwork-devel] CVS update: webwork/src/main/webwork/view/taglib

[Rickard ?b. <ric...@us...>]

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

Modified Files:
	ActionTag.java I18nTag.java 
Log Message:
ActionContext refactoring

[Webwork-devel] CVS update: webwork/src/main/webwork

[Rickard ?b. <ric...@us...>]

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

Modified Files:
	default.properties 
Log Message:
ActionContext refactoring

[Webwork-devel] CVS update: webwork/src/main/webwork/action/standard

[Rickard ?b. <ric...@us...>]

Update of /cvsroot/webwork/webwork/src/main/webwork/action/standard
In directory usw-pr-cvs1:/tmp/cvs-serv24381/standard

Modified Files:
	JSP.java 
Log Message:
ActionContext has been refactored to its own class in webwork.action.
*Aware interfaces will probably be deprecated in the future. Actions wanting context should call ActionContext from within code.

[Webwork-devel] CVS update: webwork/src/main/webwork/action/factory

[Rickard ?b. <ric...@us...>]

Update of /cvsroot/webwork/webwork/src/main/webwork/action/factory
In directory usw-pr-cvs1:/tmp/cvs-serv24381/factory

Modified Files:
	ActionFactory.java ApplicationMap.java 
	CommandActionFactoryProxy.java ContextActionFactoryProxy.java 
	ParameterMap.java ParametersActionFactoryProxy.java 
	SessionMap.java 
Log Message:
ActionContext has been refactored to its own class in webwork.action.
*Aware interfaces will probably be deprecated in the future. Actions wanting context should call ActionContext from within code.

[Webwork-devel] CVS update: webwork/src/main/webwork/action

[Rickard ?b. <ric...@us...>]

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

Added Files:
	ActionContext.java 
Log Message:
ActionContext has been refactored to its own class in webwork.action.
*Aware interfaces will probably be deprecated in the future. Actions wanting context should call ActionContext from within code.

[Webwork-devel] CVS update: webwork/src/main/webwork/action

[Rickard ?b. <ric...@us...>]

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

Modified Files:
	ActionSupport.java 
Log Message:
Revert back to validation on doExecute() only. Commands wishing validation must call validate() explicitly.

Re: [Webwork-devel] Validation on commands?

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

Matt Baldree wrote:

> IMHO, I believe this is why it should be explicit. You have cases where=
 it
> should be shared, not used, and separate.


Ok, I will then leave it as-is: validation will always be done for=20
doExecute() (i.e. implicitly), and needs to be called explicitly for=20
commands.

/Rickard


--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

Re: [Webwork-devel] nightly build

[Matt B. <ma...@sm...>]

Sounds like your the man. I vote lets go ahead and set this up.

----- Original Message -----
From: "Kjetil Paulsen" <kje...@mo...>
To: <ma...@sm...>; <web...@li...>
Sent: Tuesday, March 12, 2002 12:07 AM
Subject: RE: [Webwork-devel] nightly build


We can do the nigthly builds on webwork.sourceforge.net, this is a machine
located in my office and only containing the WW docs right now, I'll be
happy to set up some cron jobs to do these nightly builds...

/kjetilhp

> -----Original Message-----
> From: ma...@sm... [mailto:ma...@sm...]
> Sent: Monday, March 11, 2002 2:43 PM
> To: web...@li...
> Subject: [Webwork-devel] nightly build
>
>
> I know of several users who are behind corporate
> firewalls which do not allow outside CVS access. This
> hinders them from obtaining the latest code. I think we
> need to setup a nightly build.
>
> In addition, I think we need to establish a new release
> date. I think it is important to go ahead and establish
> a base line. This will allow developers to commit
> changes/upgrades that they want to be part of the next
> release and not this one.
>
> Thoughts?
>
> -Matt
>
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>

_______________________________________________
Webwork-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webwork-devel

Re: [Webwork-devel] Validation on commands?

[Matt B. <ma...@sm...>]

IMHO, I believe this is why it should be explicit. You have cases where it
should be shared, not used, and separate.

----- Original Message -----
From: "Rickard" <ri...@mi...>
To: "Low Heng Sin" <lo...@co...>
Cc: <web...@li...>
Sent: Tuesday, March 12, 2002 3:16 AM
Subject: Re: [Webwork-devel] Validation on commands?


Low Heng Sin wrote:

> non-cmd action - validate() -> doValidate()
> cmd-action - doDefault() -> doDefaultValidate()
> doEdit() -> doEditValidate()
> doCreate() -> doCreateValidate()
>
> The validate for cmd-action should be optional and implemented using
> reflection ( just like how cmd work ).


Preferably not. It is quite common (at least for me) that validation
rules needs to be shared between two or more commands, so splitting them
up is not a good idea.

/Rickard

--
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!


_______________________________________________
Webwork-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webwork-devel

Re: [Webwork-devel] Validation on commands?

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

Low Heng Sin wrote:

> non-cmd action - validate() -> doValidate()
> cmd-action - doDefault() -> doDefaultValidate()
> 		 doEdit() -> doEditValidate()
> 		 doCreate() -> doCreateValidate()
>=20
> The validate for cmd-action should be optional and implemented using
> reflection ( just like how cmd work ).


Preferably not. It is quite common (at least for me) that validation=20
rules needs to be shared between two or more commands, so splitting them=20
up is not a good idea.

/Rickard

--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

Re: [Webwork-devel] Validation on commands?

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

Maurice Parker wrote:

> This would break a lot of code that has relied on this behavior.  I=20
> don't use Commands, so I don't have the same validation issues that you=
=20
> get with Commands. I simply don't implement doValidation() on Actions I=
=20
> don't want to validate.  But if you remove validate() from execute()=20
> lots of my code has to be updated to go and explicitly call=20
> doValidate().  I'm sure there are others that will have the same proble=
m.

To me it sounds like most arguments thus far rely on "I need it to work=20
this way because otherwise my code breaks". Sure, I have code that would=20
need updating too (either way), but that's not really the concern right n=
ow.

If implicit -> need to add if's to validation code that switches on comma=
nd.
If explicit -> need to add validate()'s to execution/command code.

Does anyone have an opinion that is based on the actual problem and not=20
their own situation? That would be more helpful.

regards,
   Rickard

--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

RE: [Webwork-devel] nightly build

[Kjetil P. <kje...@mo...>]

We can do the nigthly builds on webwork.sourceforge.net, this is a =
machine located in my office and only containing the WW docs right now, =
I'll be happy to set up some cron jobs to do these nightly builds...

/kjetilhp

> -----Original Message-----
> From: ma...@sm... [mailto:ma...@sm...]
> Sent: Monday, March 11, 2002 2:43 PM
> To: web...@li...
> Subject: [Webwork-devel] nightly build
>=20
>=20
> I know of several users who are behind corporate
> firewalls which do not allow outside CVS access. This
> hinders them from obtaining the latest code. I think we
> need to setup a nightly build.=20
>=20
> In addition, I think we need to establish a new release
> date. I think it is important to go ahead and establish
> a base line. This will allow developers to commit
> changes/upgrades that they want to be part of the next
> release and not this one.
>=20
> Thoughts?
>=20
> -Matt
>=20
>=20
>=20
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>=20

[Webwork-devel] WebLogic Portal: WebFlow and Pipeline

[DeSouza, E. <ede...@ja...>]

Rickard, Victor,
Would be great to have something similar in WebWork.


Webflow and Pipeline are flexible mechanisms designed to help you
separate and manage the presentation and business logic that comprise
your applications, without the need for advanced programming skills. All
business logic is handled within Pipelines, while page flow is
controlled by the Webflow mechanism.
http://edocs.beasys.com/wlp/docs40/wflopipe/index.htm


WebLogic Portal Architecture:
http://edocs.beasys.com/wlp/docs40/architec/index.htm

Re: [Webwork-devel] Validation on commands?

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

Dan Bachelder wrote:

> how about marker interfaces?
>=20
> implements Validatable=20
> implements CommandValidatable


That is semantically almost equivalent to the suggestion that Matt had.=20
With the same drawbacks.

/Rickard


--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

Re: [Webwork-devel] Validation on commands?

[Dan B. <ch...@ch...>]

how about marker interfaces?

implements Validatable 
implements CommandValidatable

or something... 

On Mon, 11 March 2002, ma...@sm... wrote:

> 
> Then I vote explicit.
> 
> On Mon, 11 March 2002, Rickard wrote
> 
> > 
> > ma...@sm... wrote:
> > 
> > > Why can't we add a boolean flag,
> > > useExplicitValidation(), or something to turn it on
> or
> > > off?
> > 
> > 
> > Hm.. that would be way too confusing I think. It
> would allow differences 
> > between different developers working on the same
> project that would 
> > confuse the code too much.
> > 
> > No, either always or never. Implicit or explicit.
> > 
> > /Rickard
> > 
> > -- 
> > Rickard Öberg
> > Author of "Mastering RMI"
> > Chief Architect, TheServerSide.com
> >    The Middleware Company - We Build Experts!
> 
> 
> 
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel

Re: [Webwork-devel] Validation on commands?

[<ma...@sm...>]

Then I vote explicit.

On Mon, 11 March 2002, Rickard wrote

>=20
> ma...@sm... wrote:
>=20
> > Why can't we add a boolean flag,
> > useExplicitValidation(), or something to turn it on
or
> > off?
>=20
>=20
> Hm.. that would be way too confusing I think. It
would allow differences=20
> between different developers working on the same
project that would=20
> confuse the code too much.
>=20
> No, either always or never. Implicit or explicit.
>=20
> /Rickard
>=20
> --=20
> Rickard =D6berg
> Author of "Mastering RMI"
> Chief Architect, TheServerSide.com
>    The Middleware Company - We Build Experts!
=0D

Re: [Webwork-devel] Validation on commands?

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

Hey,

On Monday, March 11, 2002, at 07:37  AM, Rickard wrote:
>> I think the action designer can choose to call doValidation (or validate)
>>  when they feel it is appropriate. If they want the blanket validation, 
>> it is trivial to add to an ActionSupport subclass, however if it is 
>> embedded as the default behavior, then the options narrow.
>
>
> Ok, so in your view we should remove the call to validate() entirely from 
> execute()? I.e. it should always be explicit whether validation is used 
> or not? I can see your point.. it would make things much more explicit.
>
> This is a big decision... what are other's opinion on this?

-1

This would break a lot of code that has relied on this behavior.  I don't 
use Commands, so I don't have the same validation issues that you get with 
Commands. I simply don't implement doValidation() on Actions I don't want 
to validate.  But if you remove validate() from execute() lots of my code 
has to be updated to go and explicitly call doValidate().  I'm sure there 
are others that will have the same problem.

-Maurice

Re: [Webwork-devel] Validation on commands?

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

ma...@sm... wrote:

> Why can't we add a boolean flag,
> useExplicitValidation(), or something to turn it on or
> off?


Hm.. that would be way too confusing I think. It would allow differences=20
between different developers working on the same project that would=20
confuse the code too much.

No, either always or never. Implicit or explicit.

/Rickard

--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

Re: [Webwork-devel] Validation on commands?

[<ma...@sm...>]

Why can't we add a boolean flag,
useExplicitValidation(), or something to turn it on or
off?

On Mon, 11 March 2002, Rickard wrote

>=20
> Jim...@do... wrote:
>=20
> > -1
> > I'm against hardcoding validation on every command
action=20
> > indescriminately. But then again, I'm against
hardcoding validation check=20
> > in doExecute. From a practical standpoint, many of
us who use the=20
> > CommandDriven design, do so in order to "setup" a
page. This is a very=20
> > common step with no need for validation. Putting an
extraneous check in=20
> > these cases does not feel like good design.
>=20
>=20
> I personally use commands for CRUD operations (i.e.
one action with=20
> modifying 3 commands plus execute() for Read). In my
case validation is=20
> hence used for the commands but not necessarily for
execute().
>=20
> How are others using commands?
>=20
>=20
> > I think the action designer can choose to call
doValidation (or validate)=20
> > when they feel it is appropriate. If they want the
blanket validation, it=20
> > is trivial to add to an ActionSupport subclass,
however if it is embedded=20
> > as the default behavior, then the options narrow.=20
>=20
>=20
> Ok, so in your view we should remove the call to
validate() entirely=20
> from execute()? I.e. it should always be explicit
whether validation is=20
> used or not? I can see your point.. it would make
things much more explicit.
>=20
> This is a big decision... what are other's opinion on
this?
>=20
> /Rickard
>=20
>=20
> --=20
> Rickard =D6berg
> Author of "Mastering RMI"
> Chief Architect, TheServerSide.com
>    The Middleware Company - We Build Experts!
>=20
>=20
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
>
https://lists.sourceforge.net/lists/listinfo/webwork-devel
=0D

Re: [Webwork-devel] nightly build

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

ma...@sm... wrote:

> I know of several users who are behind corporate
> firewalls which do not allow outside CVS access. This
> hinders them from obtaining the latest code. I think we
> need to setup a nightly build.=20
>=20
> In addition, I think we need to establish a new release
> date. I think it is important to go ahead and establish
> a base line. This will allow developers to commit
> changes/upgrades that they want to be part of the next
> release and not this one.
>=20
> Thoughts?

Are we only missing the HMVC stuff from me now? If so, we'll leave it=20
out from 1.0.

Apart from that, I want some conclusion to this validation issue. Once=20
that is settled we release.

/Rickard

--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

[Webwork-devel] nightly build

[<ma...@sm...>]

I know of several users who are behind corporate
firewalls which do not allow outside CVS access. This
hinders them from obtaining the latest code. I think we
need to setup a nightly build. 

In addition, I think we need to establish a new release
date. I think it is important to go ahead and establish
a base line. This will allow developers to commit
changes/upgrades that they want to be part of the next
release and not this one.

Thoughts?

-Matt

Re: [Webwork-devel] Validation on commands?

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

Jim...@do... wrote:

> -1
> I'm against hardcoding validation on every command action=20
> indescriminately. But then again, I'm against hardcoding validation che=
ck=20
> in doExecute. From a practical standpoint, many of us who use the=20
> CommandDriven design, do so in order to "setup" a page. This is a very=20
> common step with no need for validation. Putting an extraneous check in=
=20
> these cases does not feel like good design.


I personally use commands for CRUD operations (i.e. one action with=20
modifying 3 commands plus execute() for Read). In my case validation is=20
hence used for the commands but not necessarily for execute().

How are others using commands?


> I think the action designer can choose to call doValidation (or validat=
e)=20
> when they feel it is appropriate. If they want the blanket validation, =
it=20
> is trivial to add to an ActionSupport subclass, however if it is embedd=
ed=20
> as the default behavior, then the options narrow.=20


Ok, so in your view we should remove the call to validate() entirely=20
from execute()? I.e. it should always be explicit whether validation is=20
used or not? I can see your point.. it would make things much more explic=
it.

This is a big decision... what are other's opinion on this?

/Rickard


--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

Re: [Webwork-devel] Validation on commands?

[<Jim...@do...>]

-1
I'm against hardcoding validation on every command action=20
indescriminately. But then again, I'm against hardcoding validation check=20
in doExecute. From a practical standpoint, many of us who use the=20
CommandDriven design, do so in order to "setup" a page. This is a very=20
common step with no need for validation. Putting an extraneous check in=20
these cases does not feel like good design.

I think the action designer can choose to call doValidation (or validate)=20
when they feel it is appropriate. If they want the blanket validation, it=20
is trivial to add to an ActionSupport subclass, however if it is embedded=20
as the default behavior, then the options narrow.=20

jim





Rickard <ri...@mi...>
Sent by: web...@li...
03/11/2002 04:24 AM

=20
        To:     WebWork Development <web...@li...>
        cc:=20
        Subject:        [Webwork-devel] Validation on commands?


Hey

What was the result of our discussions re: validating data on commands=20
as well? I recall that we said that it would be a good idea to call=20
validation() regardless of whether doExecute() or a command was to be=20
invoked.

That's ok, but then all examples break since validation is called before=20
  doDefault() is invoked. So, either the examples has to be updated so=20
that the validation rules are surrounded with
if (!isCommand("default"))
{
..
}

or, we could special-case the validation so that it's not done before=20
executing "default" but it's done on all other commands.

What say ye?

/Rickard

--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Webwork-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webwork-devel

[Webwork-devel] Aware-interfaces

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

Hey

I've been thinking about the *Aware interfaces. They are used to access=20
context which the action executes in. However, I'm more and more leaning=20
towards deprecating these in favor of accessing=20
ActionFactory.getContext() directly. This use of context should not=20
really have an impact on what the class looks like since they are=20
processing-oriented and not type-oriented. Plus, accessing=20
ActionFactory.getContext() directly requires less code.

The only reason I can see to keep the *Aware interfaces is that it makes=20
it easy to see what dependencies a particular action uses (e.g. servlet=20
or locale or similar).

Opinions and thoughts on this?

/Rickard

--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

AW: [Webwork-devel] Webwork in Weblogic 6.1

[Vedovato P. <pao...@pr...>]

it is ok now. thx.

-paolo

> -----Urspr=FCngliche Nachricht-----
> Von: Matt Baldree [mailto:ma...@sm...]
> Gesendet: Montag, 11. M=E4rz 2002 13:02
> An: Vedovato Paolo; web...@li...
> Betreff: Re: [Webwork-devel] Webwork in Weblogic 6.1
>=20
>=20
> Hmm, mine looks good try getting the latest to make sure you=20
> got the latest
> build.xml and see if it is not fixed.
>=20
> ----- Original Message -----
> From: "Vedovato Paolo" <pao...@pr...>
> To: "'Matt Baldree'" <ma...@sm...>;
> <web...@li...>
> Sent: Monday, March 11, 2002 4:00 AM
> Subject: AW: [Webwork-devel] Webwork in Weblogic 6.1
>=20
>=20
> Hi Matt
>=20
> I tried to build the newest CVS snapshot and found that we=20
> still have the
> examples
> in the webwork.jar and the webwork-examples.jar is empty.
>=20
> Cheers
> -Paolo
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Matt Baldree [mailto:ma...@sm...]
> > Gesendet: Montag, 11. M=E4rz 2002 04:58
> > An: Scott Farquhar; web...@li...
> > Betreff: Re: [Webwork-devel] Webwork in Weblogic 6.1
> >
> >
> > fixed build. thx.
> >
> > ----- Original Message -----
> > From: "Scott Farquhar" <sc...@at...>
> > To: <web...@li...>
> > Sent: Sunday, March 10, 2002 7:55 PM
> > Subject: [Webwork-devel] Webwork in Weblogic 6.1
> >
> >
> > > I am having problems running Webwork (and a few other
> > programs ;) ) in
> > > weblogic 6.1 (SP2).
> > >
> > > There seem to be problems with classloaders:
> > >
> > > jira-lib ERROR [(webwork.config.DefaultConfiguration)]
> > Could not find
> > > webwork.pr
> > > operties
> > > java.lang.IllegalStateException: webwork.properties missing
> > >          at
> > >
> >=20
> webwork.config.PropertiesConfiguration.<init>(PropertiesConfiguration
> > > .java:37)
> > >
> > > That line is:
> > > URL settingsUrl =3D
> > >
> > Thread.currentThread().getContextClassLoader().getResource(aNa
> > me+".propertie
> > s");
> > >
> > > The same code works fine in JBoss and Orion.  The=20
> webwork.properties
> > > file lives in /WEB-INF/classes/webwork.properties.
> > >
> > > This problem occurs with RC2 as well as the latest CVS=20
> version.  Has
> > > anyone got webwork to work with weblogic 6.1?
> > >
> > > Also - in the latest CVS build, the webwork.jar file has
> > gone from 200k
> > > to 500k.  This jar includes all the tests & examples in the
> > jar.  IMHO
> > > the webwork.jar should only contain classes that are
> > needed, not test or
> > > examples.
> > >
> > > Cheers,
> > > Scott
> > >
> > > --
> > > Scott Farquhar :: sc...@at...
> > >
> > > Atlassian :: http://www.atlassian.com
> > >       Supporting YOUR J2EE World
> > >
> > >
> > > _______________________________________________
> > > Webwork-devel mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/webwork-devel
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Webwork-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webwork-devel
> >
>=20
>=20
>=20
>=20