Jason Carreira wrote:
I was thinking it would be good to let them be able to do a series of
modifications to the programmatic configuration side then commit them
all at once. The runtime configuration is not really a cache, it's
another set of data structures that is built from the first set.
But,
Jason Carreira wrote:
action name=commandTest
class=com.opensymphony.xwork.SimpleAction
param name=foo123/param
result name=error type=chain
param name=actionNamebar/param
/result
interceptor-ref name=static-params/
Hi!
I'm looking through the Configuration stuff in XWork, and have the
following comments/questions:
* What does it mean for a package to be abstract?
* The ConfigurationProviderFactory is not a factory, so it's a bad
name. Also, what is it's purpose? It seems that the current code only
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
Why are params declared explicitly? What's wrong with finding them
implicitly, as is done in WebWork? Sounds like a refactoring disaster
waiting to happen. Any configuration that is mostly just
duplication of
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
But, that data structure could be created on each call to the
configuration, i.e. there's a deterministic way to get it from the
registered package contexts. So, in *effect* it *is* a cache.
Sort of, but it's not
Jason Carreira wrote:
There are 2 types of parameterization, and you're free to use either
or both. The params in the configuration are static params which are
intended to parameterize a reusable Action for one or more aliases.
For instance, if you had an email action you might parameterize it
Jason Carreira wrote:
Sort of, but it's not used that way.
In what way is it not used as a cache?
E.g.: xwork !-- Register subapp foo which uses XML config --
application name=foo param name=config.xmlfoo.xml/param
/application !-- Register subapp bar which uses DB config --
application
I have just started playing with webwork and I am using the examples as a
guide on how everything works. I have created a small application that
basically has one jsp called login.jsp . I have created a action.xml file
and placed it in the classes folder of my webapp. Here is the snippet of my
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
IIRC we argued about this before, and I think my position was
that you'd
typically want configuration to live elsewhere, but, as you said just
don't use it (except that it becomes a built-in anti-pattern).
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
Jason Carreira wrote:
Sort of, but it's not used that way.
In what way is it not used as a cache?
In the way in which if it doesn't find it in the runtime configuration it fails back
to the programmatic
Jason Carreira wrote:
We'll have to agree to disagree :-) I think it's useful for some cases.
How about this one: You've got an action you want to alias multiple times with different defaults?
If that ever comes up, I'll answer it. So far I've never come across
such a situation, for me or
Jason Carreira wrote:
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
Yes, and the right way to do this is probably to enforce that
views have
this style /WEB-INF/foo where foo is the name of the
subapp, i.e. do
a hard prefixing. This will ensure that you can always
Jason Carreira wrote:
* This method in ConfigurationManager is wrong:
Interceptor getInterceptor(String clazz)
It assumes that there is only one instance of each
interceptor class.
This does not account for the case where one instance is used
with many
names (compare with servlets), and
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
Ok, well I guess this argument is the same as parameterized
commands. I
have a couple of interceptors in my own AOP application that
are indeed
parameterized, so at least in that context there's a need, and I
I had a problem with jrun4 as well, but I didn't look into it much as I was
not committed to using it, I just swapped in resin.
Regards,
-Andre Mermegas
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott
Farquhar
Sent: Friday, February 28, 2003
Dang,
I was hoping that Jrun was not the problem. I am pretty much stuck with
Jrun so I guess I will not be able to use this framework. When I get some
free time I will try to see what is going with this framework and Jrun4.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
hi all,
i have problem,
when i try to submit a form to an action, and one of the form fields is
empty i get an odd message (ie. when the querystring is
http://localhost/save.action?entryId=
No view for result [input] exists for action [save]
i am not sure how to handle this since it seems to
Someone already responded, check the ParameterAware interface.
John Benediktsson wrote:
I want to use Webwork for a project and I'm having trouble finding
some similar capability to Struts DynamicActionForms.
I would like to have an Action object be able to access all fields
from a form
Messagesee:
http://www.opensymphony.com/webwork/api/webwork/action/ActionContext.html#ge
tParameters()
ActionContext.getParameters() inside your action
it returns a map of parameters, the map contains lists of the parameters
see also
ActionContext.getSingleValueParameters() if you dont want a
This is happening because you have an IllegalArgumentException being
thrown when Webwork tries to set the field with a String value...
Must be the field is a non-String which cannot accept a ? In
validate() in ActionSupport it checks the errors and errormessages and
if there are any, it throws a
20 matches
Mail list logo
