Patrick Lightbody wrote:
So anyway, I'm just going to disregard the Documentation thread and start
a thread that is actually useful :)
Good idea :-)
(Though, Ken, we're still hoping your willing to do some Doc work!)
Same here!
So besides Action Chaining, Rickard made a good point that
I remember that it was asked in the mailing list if this change would affect
a
existing webapp. I remember also that I made a grep through our code and
I didn't see that we used the url tag directly without a value attribute.
BUT what was missed (I also did forget) was to make a grep though
All,
Since quite a few of you disagreed with my resignation as XWork
architect, I've given some thought to how it would be possible to merge
my requirements with those that you have. It might be possible to do it,
and if so I would reconsider re-starting my work on XWork. I'd like to
begin
Quoting Rickard Öberg [EMAIL PROTECTED]:
Hani Suleiman wrote:
Well, we're not talking about writing a tx system here, just providing
the calls to begin/commit/rollback. And that's definitely a good idea to
put here, especially if you're doing a straight servlets/db application,
i.e. no
Hani Suleiman wrote:
Sure, however, please do keep in mind that many people do choose to use EJB's
for the tx stuff. Session beans really are great for that kind of thing. I
realise that you and others have much against EJBs, and that's fair enough, but
I was just voicing the sentiment that I
For those who want to use EJB's to do the tx demaraction, you'd simply
remove the tx interceptor.
Or, another way to put what Rickard said is:
For those who don't want to use EJB's to do the tx demarcation, you'd simply
add the tx interceptor. ;)
No, of course not. Transactions are just a good base case because they are a
type of interceptor that works on both sides of the action (before and
after) and behavior can change based on possible configurations, changes in
the action contex, etc.
-Pat
- Original Message -
From: Hani
For those who want to use EJB's to do the tx demaraction, you'd simply
remove the tx interceptor.
You mean not add it, I hope. The basic configuration should imho be as clean
as possible.
Anders Hovmöller
[EMAIL PROTECTED] http://boxed.killingar.net
On Fri, Jan 10, 2003 at 10:59:06AM +0100, Rickard Öberg wrote:
These are the core concepts that I can think of. Now, for my own
portlet-ish needs (which I hope will be more common for others too in
the future) the following applies:
* Actions and Components, and their resulting views, are
As I said, I don't think GD is needed anymore. Here's an example
interceptor I wrote:
public class ParameterInterceptor
implements ActionInterceptor
{
// ActionInterceptor implementation --
public String execute(ActionInvocation invocation)
Typo.
Rickard Öberg wrote:
When configuring actions you don't typically specify individual actions,
...individual interceptors,
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
Title: sorting collections
My Action class has a method getCars() that returns a collection of Car objects.
The Car class has a method getMake(), along with several others.
I'd like to output a sorted table of the cars in my JSP, sorted on the make.
Here's what I tried.
table
webwork:bean
On Sat, 2003-01-11 at 01:28, James Cook wrote:
Is JasperReports already integrated as a view technology in 1.3? I saw some
documentation regarding its use in WebWork.
Yes. I've committed some enhancements to CVS that do more and I'll get
around to updating the example code and documentation
Rickard,
These are great, I've placed them on the Wiki (Which is now linked from the
main site, yay!).
-Pat
- Original Message -
From: Rickard Ã-berg [EMAIL PROTECTED]
To: WebWork [EMAIL PROTECTED]
Sent: Friday, January 10, 2003 1:59 AM
Subject: [OS-webwork] XWork: core concepts
All,
14 matches
Mail list logo
