Re: [OS-webwork] re: some suggestion about ww2.0
On Wed, Feb 19, 2003 at 09:13:49PM +0100, Anders Engström wrote: In the current code-base when an exception is thrown in action.execute() a standard web-work page is rendered by ServletDispatcher. There is no (?) way to override this. It would be very useful if one could define an application error page in views.properties on-exception.view=error.jsp or an action-specific exception view HelloAction.on-exception.view=hello_error.jsp I always thought that in case of an exception error is used as view. Or did this change somewhen? This was a reasonable behaviour, IMHO. I don't wan't to differenciate between normal errors (whatever they are) and exceptions. If an exception slips throught, show error. If you have to diferentiate, catch and handle in your Action class. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] re: some suggestion about ww2.0
On Thu, Feb 20, 2003 at 10:46:45AM +0100, Philipp Meier wrote: On Wed, Feb 19, 2003 at 09:13:49PM +0100, Anders Engström wrote: In the current code-base when an exception is thrown in action.execute() a standard web-work page is rendered by ServletDispatcher. There is no (?) way to override this. It would be very useful if one could define an application error page in views.properties on-exception.view=error.jsp or an action-specific exception view HelloAction.on-exception.view=hello_error.jsp I always thought that in case of an exception error is used as view. Or did this change somewhen? This was a reasonable behaviour, IMHO. I don't wan't to differenciate between normal errors (whatever they are) and exceptions. If an exception slips throught, show error. If you have to diferentiate, catch and handle in your Action class. As far as I can tell from looking at the code (CVS) in ServletDispatcher/GenericDispatcher when an exception is thrown in the Action.execute() ServletDispatcher will generate a WebWork specific error page (HTTP Response Code 500). It will not select the error view. It's this WW specific error page I would like to override with an application specific view (your standard error.jsp in most cases). Also see my previous post on why the WW framework should handle java.lang.Throwable instead of java.lang.Exception in these cases. //Anders -- |===| |Anders Engström| |[EMAIL PROTECTED]| |http://www.gnejs.net | |===| |Your mind is like an umbrella. | |It doesn't work unless you open it.| | /Frank Zappa | |===| --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: RE: [OS-webwork] re: some suggestion about ww2.0
I think this would be a good thing to put in an interceptor and not in
the core XWork framework. However, putting a param tag inside an action
might not be a bad idea.
action name=create
param name=methodtransferAccount/param
param name=param1acct1/param
param name=param2acct2/param
interceptor-ref name=pojo/
...
/action
--
Matt Ho
Principal
Indigo Egg, Inc.
http://www.indigoegg.com/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Jason Carreira
Sent: Wednesday, February 19, 2003 5:25 AM
To: [EMAIL PROTECTED]
Subject: FW: RE: [OS-webwork] re: some suggestion about ww2.0
Hmmm... This has me thinking. Maybe we could allow command driven
actions
to specify the method to call (defaulting to doCommandName) to execute
the
action for that command?
What do we do if the method doesn't return String? Should we try to
catch
exceptions, then return ERROR if we catch one, or return SUCCESS if
not?
Do we need the Action interface in this case?
Jason
-Original Message-
From: ¹ËÌìÑï [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 12:25 AM
To: Jason Carreira
Subject: RE: RE: [OS-webwork] re: some suggestion about ww2.0
Why could we call common methods of a POJO javabean from some new
tags?
My problem comes from below situation:
My system is a 3-tier system, web tier - middle tier - database.
In the middle tier, system is composed of entities and business logic.
An example of a business logic like this:
public class AccountManager
{
//create account
public void createAccount(Account account)
{
...
}
//transfer amount between accounts
public void transferAccount(String acct1,String
acct2,
long amount)
{
...
}
//get account balance
public balance getAccountBalance(String acct1)
{
...
}
...
}
In ww1.x, AccountManager cant be directly used as Control for
webwork
view technologies. I must translate AccountManager to many Actions.
Each
action spreads method params and result to action fields, like this:
public class CreateAccountAction extends ActionSupport {
Account account;
public Account getAccount(){};
public void setAccount(Account account){};
public void execute()
{
//call middle tier logic
getAccountManger().createAccount(account);
}
}
I know the tedious translation work could be automatically by xdoclet.
But if ww2.0 view technologies could support POJO such as
AccountManager
as Logic layer, it'll be preferred for programmers like me.
- Original Message -
From:Jason Carreira [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
Subject:RE: [OS-webwork] re: some suggestion about ww2.0
Date:Wed, 19 Feb 2003 12:33:27 +0800
Maybe I asked a foolish question or my english is poor
( I am not a native English Speaker). But please correct
me if I am wrong.
My main suggestion is remove the restriction of Action layer.
Could we just use POJO as Action? If it's possible, we
could say proundly, No formbeans, No actions :)
Gu Tianyang
[EMAIL PROTECTED]
The problem here is that you'll want your web app to DO something.
Without an Action, how will it be triggered to do something? Is
populating a javabean the only thing you're looking to do?
Jason
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day
Trial.
www.slickedit.com/sourceforge
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
__
===
ÊÖ»úÓïÒôÁÄÌì¹úÄÚ³¤Í¾5·ÖÖÓ/1Ôª¡¢Ë§¸çÃÀÅ®ö¦ÕÕ¾¡ÔÚ°®Çé¿ìµÝ
(http://love.sina.com.cn)
ÊÖ»ú¶ÌÐÅ·¢ËÍmµ½10£¬Ãâ·Ñ»ñµÃÐÂÀË15MÈÎÄãÓÊÓÊÏ䣡
(http://vip.sina.com/love_send/lover.html)
çÍ·×ÏÂÔؾãÀÖ²¿ ÿÔÂ5ԪͼƬÁåÉùËæÐÄ»»
(http://sms.sina.com.cn/act/member.html
RE: [OS-webwork] re: some suggestion about ww2.0
I was thinking something like this:
action name=Foo class=com.opensymphony.xwork.SimpleAction
param name=foo17/param
param name=bar23/param
result name=success type=chain
param name=actionNameBar/param
/result
interceptor-ref name=debugStack/
interceptor-ref name=defaultStack/
command name=myCommand alias=fooCommand method=myFooAction
param name=baz100/param
/command
/action
Where we define commands that are mapped to an alias and a method to execute (which is
optional and would default to doMyCommand() in this case).
If we did this, we could make it where name is an optional attribute of action and, if
present, creates a default command alias with a method mapping of execute(). Then,
rather than using the Action Interface, which only defines the execute() method, you'd
just use reflection to find ALL execute methods, either execute() or doMyCommand() or
whatever you map. Notice that in Xwork, ActionSupport's execute() method only returns
SUCCESS, it doesn't actually have to do anything, because the Interceptors take care
of things like validation.
All execute methods, no matter what they're named, would need to be zero arg methods
and return a String... Or if it returns something besides a String I suppose we could
just take not throwing an exception as SUCCESS, and throwing an exception as ERROR.
Thoughts?
Jason
-Original Message-
From: Matt Ho [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 9:37 AM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] re: some suggestion about ww2.0
I think this would be a good thing to put in an interceptor
and not in the core XWork framework. However, putting a
param tag inside an action might not be a bad idea.
action name=create
param name=methodtransferAccount/param
param name=param1acct1/param
param name=param2acct2/param
interceptor-ref name=pojo/
...
/action
--
Matt Ho
Principal
Indigo Egg, Inc.
http://www.indigoegg.com/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of
Jason Carreira
Sent: Wednesday, February 19, 2003 5:25 AM
To: [EMAIL PROTECTED]
Subject: FW: RE: [OS-webwork] re: some suggestion about ww2.0
Hmmm... This has me thinking. Maybe we could allow command driven
actions
to specify the method to call (defaulting to doCommandName)
to execute
the
action for that command?
What do we do if the method doesn't return String? Should we try to
catch
exceptions, then return ERROR if we catch one, or return SUCCESS if
not?
Do we need the Action interface in this case?
Jason
-Original Message-
From: ¹ËÌìÑï [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 12:25 AM
To: Jason Carreira
Subject: RE: RE: [OS-webwork] re: some suggestion about ww2.0
Why could we call common methods of a POJO javabean from some new
tags?
My problem comes from below situation:
My system is a 3-tier system, web tier - middle tier - database.
In the middle tier, system is composed of entities and
business logic.
An example of a business logic like this:
public class AccountManager
{
//create account
public void createAccount(Account account)
{
...
}
//transfer amount between accounts
public void transferAccount(String acct1,String
acct2,
long amount)
{
...
}
//get account balance
public balance getAccountBalance(String acct1)
{
...
}
...
}
In ww1.x, AccountManager cant be directly used as Control for
webwork
view technologies. I must translate AccountManager to many
Actions.
Each
action spreads method params and result to action fields, like this:
public class CreateAccountAction extends ActionSupport {
Account account;
public Account getAccount(){};
public void setAccount(Account account){};
public void execute()
{
//call middle tier logic
getAccountManger().createAccount(account);
}
}
I know the tedious translation work could be automatically
by xdoclet.
But if ww2.0 view technologies could support POJO such as
AccountManager
RE: RE: [OS-webwork] re: some suggestion about ww2.0
I like this idea :)
You could then specify a view to go to based on either ExceptionType, or a
return type
There may also be a need to store the result of the POJO method execution
in an action variable
action name=create return=transaction
param name=methodtransferAccount/param
param name=param1acct1/param
param name=param2acct2/param
interceptor-ref name=pojo/
...
view exception=PermissionExceptionLogin.action/view
view return-value=transaction.approvedAccountSummary.action/view
view return-value=transaction.failedRetry.vm/view
/action
Therefore running the action will do this
Try
{
valueStack.push(transaction,
transferAccount(params.get(acct1), params.get(acct2)))
}
Catch (PermissionException pe)
{
// goto a chained action Login.action
}
If (valueStack.get(transaction.approved))
{
// goto a chained action AccountSummary.action
}
Else If (valueStack.get(transaction.approved))
{
// goto view Retry.vm
}
...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Matt Ho
Sent: Thursday, 20 February 2003 12:37 AM
To: [EMAIL PROTECTED]
Subject: RE: RE: [OS-webwork] re: some suggestion about ww2.0
I think this would be a good thing to put in an interceptor and not in the
core XWork framework. However, putting a param tag inside an action might
not be a bad idea.
action name=create
param name=methodtransferAccount/param
param name=param1acct1/param
param name=param2acct2/param
interceptor-ref name=pojo/
...
/action
--
Matt Ho
Principal
Indigo Egg, Inc.
http://www.indigoegg.com/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Jason Carreira
Sent: Wednesday, February 19, 2003 5:25 AM
To: [EMAIL PROTECTED]
Subject: FW: RE: [OS-webwork] re: some suggestion about ww2.0
Hmmm... This has me thinking. Maybe we could allow command driven
actions
to specify the method to call (defaulting to doCommandName) to execute
the
action for that command?
What do we do if the method doesn't return String? Should we try to
catch
exceptions, then return ERROR if we catch one, or return SUCCESS if
not?
Do we need the Action interface in this case?
Jason
-Original Message-
From: ¹ËÌìÑï [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 12:25 AM
To: Jason Carreira
Subject: RE: RE: [OS-webwork] re: some suggestion about ww2.0
Why could we call common methods of a POJO javabean from some new
tags?
My problem comes from below situation:
My system is a 3-tier system, web tier - middle tier - database.
In the middle tier, system is composed of entities and business logic.
An example of a business logic like this:
public class AccountManager
{
//create account
public void createAccount(Account account)
{
...
}
//transfer amount between accounts
public void transferAccount(String acct1,String
acct2,
long amount)
{
...
}
//get account balance
public balance getAccountBalance(String acct1)
{
...
}
...
}
In ww1.x, AccountManager cant be directly used as Control for
webwork
view technologies. I must translate AccountManager to many Actions.
Each
action spreads method params and result to action fields, like this:
public class CreateAccountAction extends ActionSupport {
Account account;
public Account getAccount(){};
public void setAccount(Account account){};
public void execute()
{
//call middle tier logic
getAccountManger().createAccount(account);
}
}
I know the tedious translation work could be automatically by xdoclet.
But if ww2.0 view technologies could support POJO such as
AccountManager
as Logic layer, it'll be preferred for programmers like me.
- Original Message -
From:Jason Carreira [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
Subject:RE: [OS-webwork] re: some suggestion about ww2.0
Date:Wed, 19 Feb 2003 12:33:27 +0800
Maybe I asked a foolish question or my english is poor
( I am not a native English Speaker). But please correct
me if I am wrong.
My main suggestion is remove the restriction of Action layer.
Could we just use POJO as Action? If it's possible, we
could say proundly, No formbeans, No actions
Re: RE: [OS-webwork] re: some suggestion about ww2.0
On Thu, Feb 20, 2003 at 01:37:49AM +1000, Cameron Braid wrote: [snip] You could then specify a view to go to based on either ExceptionType, or a return type [snip] This is a functionality I miss in WW a lot. You can only specify views based on success, error, input etc (please correct me if I'm wrong). - but it would be very nice if you could select view based on Exception or user-defined return-values: (pseudo code): AnAction.action=TheAction AnAction.success=good.jsp AnAction.error=bad.jsp AnAction.error.java.net.MalformedURLException=noconnection.jsp AnAction.user-defined=better.jsp I suppose something similar could be accomplished by chaining actions and redirecting (just guessing). I'm pretty new with WW - so let me know if these features already exists (will exist in WW2). //Anders -- |===| |Anders Engström| |[EMAIL PROTECTED]| |http://www.gnejs.net | |PGP-Key: http://dmzc.gnejs.net/public_key.asc | |===| |Your mind is like an umbrella. | |It doesn't work unless you open it.| | /Frank Zappa | |===| msg01875/pgp0.pgp Description: PGP signature
RE: [OS-webwork] re: some suggestion about ww2.0
You can already define any (String) return codes you want. Success, error, input, and login are just the pre-defined ones. The ability to define which view to forward to based on exception type does not exist, except for ResultException, which encapsulates the information for which view to forward to. Jason -Original Message- From: Anders Engström [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 10:56 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] re: some suggestion about ww2.0 On Thu, Feb 20, 2003 at 01:37:49AM +1000, Cameron Braid wrote: [snip] You could then specify a view to go to based on either ExceptionType, or a return type [snip] This is a functionality I miss in WW a lot. You can only specify views based on success, error, input etc (please correct me if I'm wrong). - but it would be very nice if you could select view based on Exception or user-defined return-values: (pseudo code): AnAction.action=TheAction AnAction.success=good.jsp AnAction.error=bad.jsp AnAction.error.java.net.MalformedURLException=noconnection.jsp AnAction.user-defined=better.jsp I suppose something similar could be accomplished by chaining actions and redirecting (just guessing). I'm pretty new with WW - so let me know if these features already exists (will exist in WW2). //Anders -- |===| |Anders Engström| |[EMAIL PROTECTED]| |http://www.gnejs.net | |PGP-Key: http://dmzc.gnejs.net/public_key.asc | |===| |Your mind is like an umbrella. | |It doesn't work unless you open it.| | /Frank Zappa | |===| --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] re: some suggestion about ww2.0
Anders Engström wrote: This is a functionality I miss in WW a lot. You can only specify views based on success, error, input etc (please correct me if I'm wrong). - but it would be very nice if you could select view based on Exception or user-defined return-values: snip The idea is that if an exception is thrown from execute() it's a system exception and not an application exception. I.e. you're supposed to catch all application exceptions and return some view string that corresponds to the error message to be shown. /Rickard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] re: some suggestion about ww2.0
On Wed, Feb 19, 2003 at 05:04:23PM +0100, Rickard Öberg wrote:
Anders Engström wrote:
This is a functionality I miss in WW a lot. You can only specify views
based on success, error, input etc (please correct me if I'm wrong).
- but it would be very nice if you could select view based on Exception
or user-defined return-values:
snip
The idea is that if an exception is thrown from execute() it's a system
exception and not an application exception. I.e. you're supposed to
catch all application exceptions and return some view string that
corresponds to the error message to be shown.
That sounds resonable, when you put it that way. Am I correct in my
assumption that you can return your own 'result' from an action - it
doesn't have to be 'error', 'success' etc. to map the result
string to a view?
About exceptions - Looking at GenericDispatcher is seems that
RuntimeException Co are never trapped when thrown from
Action.execute() (in GenericDispatcher.executeAction()).
try
{
result = action.execute();
} catch(Exception e)
{
actionException = e;
return;
}
If a RuntimeException is thrown in Action.execute() it will propagate
all the way up to the caller (if using WW in a servlet container, the
servlet container would handle the Throwable - and ServletDispatcher's
pretty error page will not be shown).
Is this the way it is supposed to work - or should GenericDispatcher and
ActionResult actually handle Throwable instead of Exception?
//Anders
msg01878/pgp0.pgp
Description: PGP signature
Re: [OS-webwork] re: some suggestion about ww2.0
Anders Engström wrote:
That sounds resonable, when you put it that way. Am I correct in my
assumption that you can return your own 'result' from an action - it
doesn't have to be 'error', 'success' etc. to map the result
string to a view?
Yes, we just predefined a couple that seemed common. But you can return
anything, as long as you match 'em with corresponding view mappings.
About exceptions - Looking at GenericDispatcher is seems that
RuntimeException Co are never trapped when thrown from
Action.execute() (in GenericDispatcher.executeAction()).
try
{
result = action.execute();
} catch(Exception e)
{
actionException = e;
return;
}
If a RuntimeException is thrown in Action.execute() it will propagate
all the way up to the caller (if using WW in a servlet container, the
servlet container would handle the Throwable - and ServletDispatcher's
pretty error page will not be shown).
Is this the way it is supposed to work - or should GenericDispatcher and
ActionResult actually handle Throwable instead of Exception?
I think you just found a bug :-)
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] re: some suggestion about ww2.0
On Wed, Feb 19, 2003 at 05:59:34PM +0100, Rickard Öberg wrote: Anders Engström wrote: [snip] If a RuntimeException is thrown in Action.execute() it will propagate all the way up to the caller (if using WW in a servlet container, the servlet container would handle the Throwable - and ServletDispatcher's pretty error page will not be shown). Is this the way it is supposed to work - or should GenericDispatcher and ActionResult actually handle Throwable instead of Exception? I think you just found a bug :-) Heh.. well.. what can I say :) I'm extra sensitive when it comes to Exception/Throwable-catching. Spent one week chasing weird exceptions in an application where we use Oracle BC4J (persistence framework) which throws a lot of RuntimeException sub-classes. Our MVC framework were written to handle only Exception.. no log entries, no stack-traces nothing :) The framework catches Throwable now smile. //Anders -- |===| |Anders Engström| |[EMAIL PROTECTED]| |http://www.gnejs.net | |===| |Your mind is like an umbrella. | |It doesn't work unless you open it.| | /Frank Zappa | |===| msg01881/pgp0.pgp Description: PGP signature
RE: [OS-webwork] re: some suggestion about ww2.0
+1. Struts allows you declaratively handle exceptions. Initially, I really appreciated that feature, but I soon found that it made the managing exceptions a pain as there wasn't any runtime checking to ensure that all the exceptions had been caught. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rickard Öberg Sent: Wednesday, February 19, 2003 8:04 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] re: some suggestion about ww2.0 Anders Engström wrote: This is a functionality I miss in WW a lot. You can only specify views based on success, error, input etc (please correct me if I'm wrong). - but it would be very nice if you could select view based on Exception or user-defined return-values: snip The idea is that if an exception is thrown from execute() it's a system exception and not an application exception. I.e. you're supposed to catch all application exceptions and return some view string that corresponds to the error message to be shown. /Rickard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] re: some suggestion about ww2.0
OK, two things: 1) The command piece should not be formally built in to the configuration framework. I'm fine with it being part of ActionSupport and the command param being passed through, but I don't want to see it built in to the configuration framework _unless_ it is also a feature that is core to XWork (ie: not part of ActionSupport). 2) Having views based on exceptions should be easy to add. I'll work on this. -Pat - Original Message - From: Matt Ho [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 19, 2003 10:01 AM Subject: RE: [OS-webwork] re: some suggestion about ww2.0 +1. Struts allows you declaratively handle exceptions. Initially, I really appreciated that feature, but I soon found that it made the managing exceptions a pain as there wasn't any runtime checking to ensure that all the exceptions had been caught. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rickard Öberg Sent: Wednesday, February 19, 2003 8:04 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] re: some suggestion about ww2.0 Anders Engström wrote: This is a functionality I miss in WW a lot. You can only specify views based on success, error, input etc (please correct me if I'm wrong). - but it would be very nice if you could select view based on Exception or user-defined return-values: snip The idea is that if an exception is thrown from execute() it's a system exception and not an application exception. I.e. you're supposed to catch all application exceptions and return some view string that corresponds to the error message to be shown. /Rickard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] re: some suggestion about ww2.0
Check the messages I posted. What if we made ALL ActionConfigs based on Commands, with an optional default command mapped to the execute() method if you give your Action element a name attribute (which is an alias). Then you can also add more commands to your action with different execute methods and alias's. I think this would be VERY cool, and we could drop the Action Interface requirement... Jason -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 1:10 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] re: some suggestion about ww2.0 OK, two things: 1) The command piece should not be formally built in to the configuration framework. I'm fine with it being part of ActionSupport and the command param being passed through, but I don't want to see it built in to the configuration framework _unless_ it is also a feature that is core to XWork (ie: not part of ActionSupport). 2) Having views based on exceptions should be easy to add. I'll work on this. -Pat - Original Message - From: Matt Ho [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 19, 2003 10:01 AM Subject: RE: [OS-webwork] re: some suggestion about ww2.0 +1. Struts allows you declaratively handle exceptions. Initially, I really appreciated that feature, but I soon found that it made the managing exceptions a pain as there wasn't any runtime checking to ensure that all the exceptions had been caught. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rickard Öberg Sent: Wednesday, February 19, 2003 8:04 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] re: some suggestion about ww2.0 Anders Engström wrote: This is a functionality I miss in WW a lot. You can only specify views based on success, error, input etc (please correct me if I'm wrong). - but it would be very nice if you could select view based on Exception or user-defined return-values: snip The idea is that if an exception is thrown from execute() it's a system exception and not an application exception. I.e. you're supposed to catch all application exceptions and return some view string that corresponds to the error message to be shown. /Rickard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] re: some suggestion about ww2.0
Would it be possible to make the view selection algorithm pluggable, as a Strategy or something like that? Just a thought. On Wed, Feb 19, 2003 at 05:59:34PM +0100, Rickard Öberg wrote: Anders Engström wrote: That sounds resonable, when you put it that way. Am I correct in my assumption that you can return your own 'result' from an action - it doesn't have to be 'error', 'success' etc. to map the result string to a view? Yes, we just predefined a couple that seemed common. But you can return anything, as long as you match 'em with corresponding view mappings. Re-thinking this exception thing... I agree that WW should not select views based on exception class - but (from a web-front-end view) there should be a way for an application to present its own error page (with nice layout and perhaps an email sysadmin button on it :). In the current code-base when an exception is thrown in action.execute() a standard web-work page is rendered by ServletDispatcher. There is no (?) way to override this. It would be very useful if one could define an application error page in views.properties on-exception.view=error.jsp or an action-specific exception view HelloAction.on-exception.view=hello_error.jsp this view would receive the exception the normal way (provided the jsp isErrorPage). //Anders -- |===| |Anders Engström| |[EMAIL PROTECTED]| |http://www.gnejs.net | |===| |Your mind is like an umbrella. | |It doesn't work unless you open it.| | /Frank Zappa | |===| --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] re: some suggestion about ww2.0
Steve Conover wrote: Would it be possible to make the view selection algorithm pluggable, as a Strategy or something like that? Just a thought. It could be, but it would have to account for allowing multiple algorithms to be present. If a webapp A is composed of webapps B and C, both of which use WebWork but with algo's X and Y respectively, A needs to work as expected. This is a generally tricky situation, but as we move more towards a portlet-world where apps are composed of smaller components it is a very important thing to consider. In general I'm not in favor of pluggability at that level. It tends to confuse more than it helps. /Rickard --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] re: some suggestion about ww2.0
Maybe I asked a foolish question or my english is poor ( I am not a native English Speaker). But please correct me if I am wrong. My main suggestion is remove the restriction of Action layer. Could we just use POJO as Action? If it's possible, we could say proundly, No formbeans, No actions :) Gu Tianyang [EMAIL PROTECTED] The problem here is that you'll want your web app to DO something. Without an Action, how will it be triggered to do something? Is populating a javabean the only thing you're looking to do? Jason --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
