webwork-devel Mailing List for WebWork (Page 47)

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

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

Modified Files:
	ElseTag.java 
Log Message:
added log

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

Modified Files:
	IfTag.java 
Log Message:
doEndTag() was not setting proper key when id was not null.

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

Modified Files:
	expr.jsp 
Log Message:
added new test for if,elseif,else relationship

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

Modified Files:
	validation.xml 
Log Message:
Started on validation doc.

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

Added Files:
	FormTest.properties 
Log Message:
Added default props. file for FormTest. NPE when having other language in the browser than those having a property file

Update of /cvsroot/webwork/webwork/src/build
In directory usw-pr-cvs1:/tmp/cvs-serv10514

Modified Files:
	build.xml 
Log Message:
removed tomcat and web targets that were inadvertently added

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

Modified Files:
	ValueStack.java 
Log Message:
Reformat
Removed stacktrace printout, since it generated unwanted log messages when text tag was used.

>I agree, and I have intended to do just that for awhile. Just never got
>around to do it.
>
>Your solutions seems ok, although I'd prefer to have a variant that doesn't 
>require ServletDispatcher to be subclassed.
>

Oh I agree too... The solution should be implemented in ServletDispatcher, 
but the action getting part should still be refactored in case someone out 
there might need to add other functionallity... For example, I ended copying 
ServletDispatcher to my project, because it really made no sense to subclass 
it! get my drift?

/V

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Victor Salaman wrote:

> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.properties")); 
> should not really be there...
> 
> 1. it overrides any log4j setting you have made externally...

Does it?.. I don't think so. The settings in there only apply to 
WebWork, so how would they interfere with other settings?

> 2. creates all sorts of confusions when you have an external 
> log4j.properties.

Such as?

/Rickard

-- 
Rickard Öberg

Victor Salaman wrote:

> By default Webwork exposes actions found on webwork.packages prefixes or 
> through aliases. This is very convenient most times, but I have noticed 
> that there are cases when it would be best to restrict the 
> ServletDispatcher to just using aliases.

<snip>

I agree, and I have intended to do just that for awhile. Just never got 
around to do it.

Your solutions seems ok, although I'd prefer to have a variant that doesn't require ServletDispatcher to be subclassed.

/Rickard

-- 
Rickard Öberg

This line in ServletDispatcher

PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.properties"));

should not really be there...

1. it overrides any log4j setting you have made externally...
2. creates all sorts of confusions when you have an external 
log4j.properties.

Perhaps we can set a setting in default.properties which would be

webwork.initialize.log4j = true

and wrap this initialization process in a configuration check conditional.

This setting by default would be on, but could be turned off by webwork 
users who do not desire to have webwork initialize log4j.

/V

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Rickard:

By default Webwork exposes actions found on webwork.packages prefixes or 
through aliases. This is very convenient most times, but I have noticed that 
there are cases when it would be best to restrict the ServletDispatcher to 
just using aliases.

The reason for this is that you could have 1,000,000 different 
"utility/helper" actions that you don't want to ever be accessed directly 
through the web.

It is a good practice to modularize a system into many bits and pieces 
(different small actions to achieve a large tasks, since you could share 
those small actions in many different places). But this scheme falls into 
pieces with some sort of security...

In order not to affect anything else, the best place to address this is in 
ServletDispatcher, as it would not then disrupt anything else and we keep 
ActionFactory preety generic.

IMHO, this segment in ServletDispatcher,

      try
      {
         action = ActionFactory.getAction(actionName);
      }

should be refactored into

      try
      {
         action = getActionImplementation(actionName);
      }

and add a protected method "getActionImplementation(actionName)" which 
subclasses could override.

A way to moderately secure this is to do an

if(actionName.indexOf('.') >=0) throw SomeException();

right before the ActionFactory.getAction(actionName)..

This would allow you to put your secure actions in non-root packages 
relative to the prefixes with no problem and we haven't modified much! :)

Cheers,

/V

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Matt Baldree wrote:

> It appears Actions that implement PrepareAction and use DefaultActionFactory
> will have their prepare() method called 2x - once from
> PrepareActionFactoryProxy and second from ContextActionFactoryProxy.
> 
> Is there a reason for this? It looks like PrepareActionFactoryProxy should
> be the only one calling prepare.

Hm.. I changed that when I refactored CAFP into those two others, but 
apparently it never made it to CVS. Very strange...

Anyway, I have re-done that change, so current CVS should work as expected.

/Rickard

-- 
Rickard Öberg

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

Modified Files:
	ContextActionFactoryProxy.java 
Log Message:
Removed parameter setting and prepare handling

Update of /cvsroot/webwork/webwork/src/build
In directory usw-pr-cvs1:/tmp/cvs-serv22012

Modified Files:
	build.xml 
Log Message:
added includeAntRuntime="no" attribute to  javac

It also appears that actions that use DefaultActionFactory are asked to set
their parameters 2x. Once from ParametersActionFactoryProxy and second from
ContextActionFactoryProxy.

Is there a reason why we need to set parameters from
ContextActionFactoryProxy as oppose to only ParametersActionFactoryProxy?

-Matt

It appears Actions that implement PrepareAction and use DefaultActionFactory
will have their prepare() method called 2x - once from
PrepareActionFactoryProxy and second from ContextActionFactoryProxy.

Is there a reason for this? It looks like PrepareActionFactoryProxy should
be the only one calling prepare.

-Matt

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

Modified Files:
	ActionSupport.java 
Log Message:
Fixed serialization support

fixed. (thx Paolo)

----- Original Message -----
From: "Vedovato Paolo" <pao...@pr...>
To: "Webwork-Dev (E-Mail)" <web...@li...>
Cc: "Webwork-User (E-Mail)" <web...@li...>
Sent: Wednesday, December 05, 2001 4:02 AM
Subject: [Webwork-devel] new ui tag addition: mismatch between taglib.tld
and combobox tag

> Hi Matt/WebWorker Developers
>
> After the new ui tag additions and cvs update I get following error:
>
> Error in using tag library uri='webwork' prefix='webwork':
> The Tag class 'webwork.taglib.ui.ComboBoxTag' has no setter method
> corresponding to TLD declared attribute 'onkeyup', (JSP 1.1 spec, 5.4.1)
>
> either this attribute is obsolete in the taglib.tld or the Combobox tag is
> not fully implemented...
>
> Cheers
> -Paolo
>
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>

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

Modified Files:
	ComboBoxTag.java 
Log Message:
missing setter for onkeyup

Hi Matt/WebWorker Developers

After the new ui tag additions and cvs update I get following error:

Error in using tag library uri='webwork' prefix='webwork': 
The Tag class 'webwork.taglib.ui.ComboBoxTag' has no setter method
corresponding to TLD declared attribute 'onkeyup', (JSP 1.1 spec, 5.4.1)

either this attribute is obsolete in the taglib.tld or the Combobox tag is
not fully implemented...

Cheers
-Paolo

I noticed a problem building WW when you copy the project tree to the root;
i.e. c:\. When you build, javac will complain with something like...

C:\webwork\src\build\build.xml:78: The file or path you specified
(..\..\lib\ant
.jar) is invalid relative to C:\webwork

The reason is the classpath specified in build.bat is carried over at
runtime. Since the base directory is ..\.., it becomes c:\webwork and then
ant tries to resolve itself under this context. A temporary fix is to load
the project one level down; i.e. c:\projects\webwork. A permanent fix is to
set the attribute "includeAntRuntime" to "false" for javac. Does anybody
know of any reason why we need to have this attribute set to "true"? If not,
I would like to propose it be set to false.

-Matt

I agree lack of documentation is frustrating and makes it difficult to sell
the framework to mgmt. Go to the bugs section to see what documentation is
being worked on. Hopefully by month's end, we will have some documentation
for public review.

-Matt

----- Original Message -----
From: "Konstantin Priblouda" <kpr...@ya...>
To: <web...@li...>
Sent: Saturday, December 01, 2001 11:23 AM
Subject: [Webwork-devel] Documentation ( lack thereof )

> Hi guys,
>
> I started to evaluate webwork, but complete lack of
> documentation is very frustrating.
> (I'm inspecting the code and examples and try to
> figure
> how things are supposed to work, but it's difficult
> and not very productive)
>
> If somebody has docs in work, please submit them to
> CVS.
>
> Areas of primary interest:
> - action mappings, syntax of JSP
> (why to wrap parameters in '' ? ),
> validation of input data, what else to read etc. pp.)
>
> I will be unable to sell this framework to project
> management, and not able to teach coworkers
> to work with it without such information.
>
> tia,
>
> =====
> 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!?
> Buy the perfect holiday gifts at Yahoo! Shopping.
> http://shopping.yahoo.com
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>

I added a few HTML attributes to the ui tags which are commonly needed.

1. tabindex attribute - change made for textfield, password, combobox,
select, textarea, radio, checkbox

Needed in complex forms where you want to control the tab flow.

2. onchange attribute - textfield, password, combobox (edit field part),
select (selectcascading would ignore this since it has its own), textarea,
radio, checkbox

Commonly needed.

3. onkeyup attribute - combobox (edit field part), textfield, textarea,
password

This is useful for instance when you want to dynamically calculate a total
when someone types a quantity.

-Matt

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

Modified Files:
	taglib.tld 
Log Message:
add HTML attribute - tabindex, onchange, onkeyup to appropriate tags

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

webwork-devel Mailing List for WebWork (Page 47)

webwork-devel — WebWork development