G'day all,
Can someone give me a quick example of an actions.xml that implements
command-driven actions?
I got it going with view.properties, but can't get the actions.xml to work.
cheers,
Randall Dietz
IT Consultant
---
This sf.net email i
> I think it will be more obvious if we do something similar to ant :
>
>
>
>
>
>
> addentry.jsp
> addentry.jsp
> viewentry.jsp
>
>
>
> This also help to avoid the ambiguity when classes in different package
have
> same name ( Something pretty co
Brockman Bulger wrote:
One of the biggest disconnects I had when moving from Struts to WebWork
(I really like WebWork) was getting a handle on the actions.xml file. To
elaborate a little, when you declare an action in Struts you're using
the fully qualified classname in the config file. The exa
I think it will be more obvious if we do something similar to ant :
addentry.jsp
addentry.jsp
viewentry.jsp
This also help to avoid the ambiguity when classes in different package have
same name ( Something pretty common actually ).
IMHO, a
Proposed for XWork
One of the biggest disconnects I had when moving from Struts to WebWork (I
really like WebWork) was getting a handle on the actions.xml file. To
elaborate a little, when you declare an action in Struts you're using the
fully qualified classname in the config file. The exampl
I am not an expert on WW, though the normal way to deal with 'missing'
http data is to set a default value for the property and it can be
overridden by the request parameter...
i.e. if you set
protected boolean newsletter = false;
instead of true, then WW will call the setNewsletter(true) when
Hello everyone,
Please excuse this newbie question but I'm still coming up to speed on WW and I've run
into a little problem with checkboxes. There wasn't an example in the distribution
that I could find for the following situation.
On my form I have the following:
" method="POST">
Brock,
Just post your ideas on the mailing list and and Wiki and we can discuss
them.
-Pat
- Original Message -
From: "Brockman Bulger" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 17, 2002 2:04 PM
Subject: [OS-webwork] XWork configuration
>
> I noticed the roadma
I noticed the roadmap for XWork at:
http://www.opensymphony.com:8668/space/XWork+Roadmap
The configuration system is on the list to be overhauled and I had some
thoughts on how to simplify it and make it more intuitive for users and
developers. As I'm new to the mailing list and have only had
It's not because I ran in to that a problem where I had multiple copies of
ant. I've had that problem for almost 2 years. I'm springboarding off of
Ken's work on documentation and trying to organize the various components
being maintained here.
What I did was I looked at the various build processe
The same way you said you'd take care of all the
osworkflow/oscore/propertyset descriptors when you moved away from
xdoclet? The very descriptors that were out of sync/broken for fairly
significant stretches of time?
Of course, it's your right to take on whatever work. It's appreciated
and it
Hello Patrick,
I also have multiple versions of Ant installed. If you're runnig cygwin
or Ksh/Bash/Z-Shell on Unix put something like this in your .bashrc or
.zshrc:
function ant13
{
export ANT_HOME=/c/apps/jakarta-ant-1.3
export JAVA_HOME=/d/jdk1.3
export JAVACMD=$JAVA_HOME/bin/ja
OK, I'm making an executive decision: Ant will be included with the builds.
And in case you didn't know, the WebWork build works this way. End of issue,
since it's not a big issue, no matter how much people want to make it seem
like it is. Can you all please go back and look at the rest of the emai
Hello,
Bill Lynch wrote:
Hani,
I am vehemently opposed to build.bat and build.sh. All you need is
ant. I'm likewise against checking in ant to every single project.
It's a fairly reasonable assumption that people who might need to
build a project have ant installed (you don't bundle gnu make
This *really* belongs on osdev...
Anyway, my two cents: We need to be a LITTLE BIT elitist, IMHO. If people
are idiots, they shouldn't be building the software themselves; they
should be downloading ready-to-deploy components, built by non-idiots who
are able and willing to install Ant.
Special c
Bill,
My desire to include ant also stems from the fact that sometimes some of us
need multiple copies of ant hanging around. For example, I have an old
project that MUST be built with ant 1.3 (don't ask, it's a long story). So
moving in this direction would be a win. Either way, Like I've said bef
> The build.bat is useful for windows systems at least where most people
don't
> have a command prompt open - that's just one more stupid window to leave
> open with a bunch of others while developing. It's much easier to click
it
> in explorer for fast builds - it's just faster than clicking cmd,
If maintence is your worry, I'll be happy to take care of updating
everything. Since this will be _standard_, all that would need to happen
when ant 1.6 comes out is that we drop a few files in lib/build and commit.
I'll take this task on for each release, which is very rare. The added bonus
of hav
On Tuesday, Dec 17, 2002, at 16:23 Europe/London, Hani Suleiman wrote:
I am vehemently opposed to build.bat and build.sh. All you need is
ant. I'm likewise against checking in ant to every single project.
It's a fairly reasonable assumption that people who might need to
build a project have an
Hello,
Patrick Lightbody wrote:
If we don't include ant but instead tell people to download ant, I can
promise you that the mavenites will be clamoring for maven builds instead,
since downloading maven or downloading ant are parallels. Besides, build.xml
is there, you can use ant just like you al
(I'm giving up on cc'ing os-dev for now... we gotta get these mailing list
issues resolved I suppose)
Jalopy formats the actual sources, so they will get checked in. Line numbers
will match.
-Pat
- Original Message -
From: "Bill Lynch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tu
Hani,
I am vehemently opposed to build.bat and build.sh. All you need is ant.
I'm likewise against checking in ant to every single project. It's a
fairly reasonable assumption that people who might need to build a
project have ant installed (you don't bundle gnu make with every project
that h
> I really hate the src/java, src/blah structure. I'm trying to find a
> logical reason for this hatred though but not succeeding ;) I'd like
> src to just contain java. Maybe I'm old fashioned.
I disagree. The src/blah structure works very well and helps seperate
concerns. You don't want to dep
Pat,
Coding style: we need it. Live with it. It's nice. Basically, jalopy is
REALLY cool and works very well. In this build script, any code that is
compiled will be formatted as well. We'll immediately have the same coding
standard in all our classes, regardless of people's choices for coding. S
On Tuesday, December 17, 2002, at 11:31 AM, Patrick Lightbody wrote:
If we don't include ant but instead tell people to download ant, I can
promise you that the mavenites will be clamoring for maven builds
instead,
since downloading maven or downloading ant are parallels. Besides,
build.xml
is
If we don't include ant but instead tell people to download ant, I can
promise you that the mavenites will be clamoring for maven builds instead,
since downloading maven or downloading ant are parallels. Besides, build.xml
is there, you can use ant just like you always have.
src/java, src/test, sr
On the whole this seems reasonable. Some reservations though:
I really hate the src/java, src/blah structure. I'm trying to find a
logical reason for this hatred though but not succeeding ;) I'd like
src to just contain java. Maybe I'm old fashioned.
I am vehemently opposed to build.bat and bui
I think we should standardize the OpenSymphony build process. Here is my
first cut at it, please comment:
- attached is a build script for OSCore, but as you can see, it's very
generic. We should use this as a base and not add much more to it, mostly
instructions on how to package files like ejb-j
Rob,
I'm not quite sute what you are talking about :)
OSWorkflow and WebWork do share some "workflow" similiarities, but WebWork
(via Action chaining) is for automated flow, where-as OSWorkflow is for flow
that is based on user input.
-Pat
- Original Message -
From: "Dort, Rob van" <[EMA
29 matches
Mail list logo
