Can a chain have more than one View?
Yes, of course:
I read this to mean, can a chain actually finish on more than one view.
For example:
CreateAccount.action=Create
CreateAccount.success=SendConfirmationEmail.action,create_success.jsp
In which case the answer would be no. A chain can only
On Wednesday, Nov 6, 2002, at 09:51 Europe/London, Rickard Öberg wrote:
The issue about actions.xml is verbosity, not being able to figure out
how to create it. Having a DTD doesn't change a thing in this regard.
XDoclet, perhaps?
/Rickard, who still uses views.properties
:)
Regards,
Joseph Ottinger wrote:
Well, I was looking at SendConfirmationEmail as an action/view inside the
chain, not as a chain in and of itself. I can see a lot of power in the
ability to, say, do something like this (poorly thought out, I just got
up):
SubscribeToList.action=Subscribe
Exactly my point, you can make the configuration method support a lot of
power but only require simple configuration.
Now, multiple config files could possibly confuse users, no doubt about
that. I don't think I'd like that. Good thing that configuration is
pluggable, so any kind of config is
In a web environment, a single termination point is logical, but as we
move away from being web based, might there be a place for ending on
multiple views? For the above example, CreateAccount could have 2 success
views, one view rendered to SMTP, the other to HTTP. Since an Action
shouldn't
Blah First off, to JoeO's whole action as a view stuff... I have
no idea what that's all about, sorry :)
Maurice also treated my original example (as to why action params are
needed) not how I intended and somehow the SendEmail action become some
wacky view stuff. That's not what I
Is no one seeing it? AmI really just that strange with WebWork usage?
*Sigh* Patrick, you are fighting against the framework instead of
trying to use it. No matter how many times I show you how to accomplish
what you want, you don't even try it. Stop trying to force it to work
the
WebWork uses commons-logging now. This was the subject of some various
heated threads a while back.
-
Joseph B. Ottinger [EMAIL PROTECTED]
http://enigmastation.comIT Consultant
On Wed, 6 Nov 2002, [UTF-8]
Bah! ObSelfPlug: http://www.sys-con.com/java/article.cfm?id=1714
See the second page, on log4j.
-
Joseph B. Ottinger [EMAIL PROTECTED]
http://enigmastation.comIT Consultant
On Wed, 6 Nov 2002, Patrick
Joseph Ottinger wrote:
WebWork uses commons-logging now. This was the subject of some various
heated threads a while back.
Ok, so then the log4j conf option should be removed, right?
/Rickard
---
This sf.net email is sponsored by: See the
I would presume so, unless you have commons-logging configured to use
log4j... :)
-
Joseph B. Ottinger [EMAIL PROTECTED]
http://enigmastation.comIT Consultant
On Wed, 6 Nov 2002, [UTF-8] Rickard Öberg
Only heated cuz you lit the fire ;) J/K...
Matt told me to do it, so I did. All my modules (OSCore, OSWorkflow, OSUser,
and PropertySet -- and soon Clickstream) use commons-logging now as well.
-Pat
- Original Message -
From: Joseph Ottinger [EMAIL PROTECTED]
To: WebWork [EMAIL
Rickard Öberg wrote:
That said, how are you others handling this? (I mean, reading log4j
files) I've tried writing a ServletContextListener, but even though it
runs, and finds the XML file, and loads it, nothing happens. The XML
file I load has webwork set to INFO, but I still see debug. Anyone
What's surreal is that you still don't see all the stuff I'm doing with
WebWork. My usages, as I'm sure you can admit, are very unique. I doubt
there is a single person out there that is doing what I'm doing. With that
said, I also used to use WebWork like you and the rest of the world did. I
see
FWIW, from the discussions I've seen so far between the two of you,
Maurice has my vote on all counts.
Great. What is the reason for that?
Also, just to make it totally clear, I've used WebWork for a long time
and I
have used the techniques that you and everyone else on this list uses.
Inline...
-
Joseph B. Ottinger [EMAIL PROTECTED]
http://enigmastation.comIT Consultant
On Wed, 6 Nov 2002, [ISO-8859-1] Rickard Öberg wrote:
Patrick Lightbody wrote:
FWIW, from the discussions I've
I'm only one guy, but...
For one thing, it would be nice if everyone involved took a step back,
breathed deeply, and remembered that this stuff isn't all there is to
life. Relax. Smell the flowers. Sneeze.
For another... I think it's important in the context of the dispatcher
discussion to note
Again, that age old questionwhy? Why this hatred of the unloved and
unappreciate if/iterator tags? What have they ever done to you?
Quoting boxed [EMAIL PROTECTED]:
I've had a most enlightening conversation on irc recently. A friend of mine
pointed out that property tag and iterator tag
Anders has had a good point all along. ww:property/ is really doing two
jobs: push and print. We are all OK with it because we're used to it. But
his post below of course looks completely silly... why would you want
ww:property/ to do push, print, AND include. That's just silly, right?
Well, now
Agreed! But please don't loose site of the ww:property tag arguments either.
It really is doing two jobs and the only reason we like it (I like it too!)
and it makes sense (makes sense to me!) is because we've grown accustomed to
it. But you cannot deny it is doing two different jobs: push and
Argh, give up! We've argued propertytag to death, we agreed that the solution
is to ensure the documentation is clear. Enough already!
I'm reminded of the boy who cried wolf, to be honest. If someone keeps
repeating the same thing over and over again (that others disagree with), then
when that
On Wed, Nov 06, 2002 at 11:48:58AM +0100, Rickard wrote:
Hm... maybe I'm just going crazy here, but the above smells like it
needs AOP :-) SCE sounds like an interceptor to me...many of the
problems here seem to be related to NOT making a difference between
actual functionality and things
On Wednesday, November 6, 2002, at 04:09 PM, Hani Suleiman wrote:
Actually, while I've pretty much agreed with Maurice on every single
point he's
made, this is one case where I agree that ui:hidden and ui:submit
would make
sense.
Hey, just because Patrick wrote it doesn't mean I disagree
Patrick,
Let me start by saying that I *do* respect your opinions. You are a
bright and energetic developer and we would be poorer if you left the
project.
As to the configuration code, I stand by all my technical arguments.
We came to an agreement and I'm holding you to it.
http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-84
If an invalid date text is submitted the attribute will
get the current date, while a null value is more appropriate.
The problem is in the DateFormatter constructor where the
date variable is initialized to new Date()
While I see
25 matches
Mail list logo
