ty-in-a-base-action-class-tp17404381p17410807.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
nt page) {
> >>this.page = page;
> >>}
> >> }
> >>
> >> struts.xml:
> >>
> >>
> >> >>"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
> >>"http://struts.apache.org/dtds/struts-2.0.dtd";>
> &g
>>
>>
>>
>>
>>
>>
>>> class="com.googlecode.scopeplugin.ScopeInterceptor" />
>>
>>
>>
>>
>>
in.ScopeInterceptor" />
>
>
>
>
>
>/success
>
>
>
>
>
>/test/start.jsp
>
>
>
>
>
>
age contentType="text/html; charset=UTF-8"%>
<%@ taglib prefix="s" uri="/struts-tags"%>
Start
Page:
http://www.nabble.com/file/p17404381/testapp.zip testapp.zip
--
View this message in context:
http://www.nabble
rought from the stone ages:
>
> * Base Action class does not dispatch events
> * DispatchAction and its flavors do, but they do not allow a user to
> derive an action class from some another user's base action
>
> What we got now in 1.2.9 and 1.3.1+ :
>
> * ActionDispatcher
On 5/9/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
On 5/9/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > What we has been brought from the stone ages:
> >
> > * Base Action class does not d
On 5/9/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> What we has been brought from the stone ages:
>
> * Base Action class does not dispatch events
> * DispatchAction and its flavors do, but they do not allow a us
Niall Pemberton wrote:
> Personally I'm against this because IMO it just adds
> confusion/complexity to the Action class that is unnecessary for users
> who don't want to use the "dispatch" style.
Not if you use my idea of making the 'execute' method the default dispatch.
Of course, don't name on
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
What we has been brought from the stone ages:
* Base Action class does not dispatch events
* DispatchAction and its flavors do, but they do not allow a user to
derive an action class from some another user's base action
What we
Michael Jouravlev wrote:
> * Stick dispatching features in base Action, thus making all actions
> to be dispatch actions.
>
> Minor drawback:
>
> * only one dispatching behavior can be chosen.
>
> Thoughts? Objections? Suggestions?
Works for me, with the following commentary (some of which may be
I like it, although you should probably bring this over to the dev list. :)
Don
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
What we has been brought from the stone ages:
* Base Action class does not dispatch events
* DispatchAction and its flavors do, but they do not allow
What we has been brought from the stone ages:
* Base Action class does not dispatch events
* DispatchAction and its flavors do, but they do not allow a user to
derive an action class from some another user's base action
What we got now in 1.2.9 and 1.3.1+ :
* ActionDispatcher resolve
On 10/10/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> On 10/10/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> > The book is quite good. Low signal to noise ratio.
>
> ? ;-)
Sorry, it's another dyslexic.Monday. s/Low/High.
I'm forever doing the same thing with least versus most siginficant dig
On 10/10/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> Cockburn includes examples of all that in his book. An author is just
> not compelled to include more detail than is needed for a particular
> case. Issues like granularity are a matter of taste for particular
> team, not an issue proscribed by
On 10/10/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> The book is quite good. Low signal to noise ratio.
? ;-)
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Cockburn includes examples of all that in his book. An author is just
not compelled to include more detail than is needed for a particular
case. Issues like granularity are a matter of taste for particular
team, not an issue proscribed by the format. I use a wiki to write my
use cases, but that's
On 10/10/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> In terms of requirements, my favorite "silver bullet" is
> Cockburn-style Use Cases. Looking back over some of the requirements
> documents I've written over the the years, this Use Case format was my
> "missing link".
>
> * http://opensource2.at
On 10/7/05, Vic Cekvenich <[EMAIL PROTECTED]> wrote:
>
> > _Listen_ to the customer,
>
> +1 that requriements is the silver bullet. I address is w/ both mock ups
> and prototypes... to demonstrate active listening.
In terms of requirements, my favorite "silver bullet" is
Cockburn-style Use Cases.
e the *implementors of change*
Have a good day all,
Martin-
- Original Message -
From: <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Friday, October 07, 2005 2:33 PM
Subject: OT: RE: Development philosophy and such (was: Base action class)
Hi Frank,
Here's the thin
_Listen_ to the customer,
+1 that requriements is the silver bullet. I address is w/ both mock ups
and prototypes... to demonstrate active listening.
.V
http://roomity.com (version 1.3 is live)
-
To unsubscribe, e-mail:
On 10/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi Frank,
>
> Sorry couldn't help but remark that... it seems some people are
> forgetting the software engineering basics.. :)
>
> "There is no silver bullet!"
Damned, and I actually thought I found one :-)
But seriously, I thin
.
>
> Here's wishing you Happy Friday!,
>
> Cheers!,
>
> Dharmendra
> ps: have a super day!
> -Original Message-
> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 07, 2005 3:08 PM
> To: Struts Users Mailing List
> Cc: user@struts
On Fri, October 7, 2005 4:10 pm, [EMAIL PROTECTED] said:
> And you are absolutely right that there is no justification for using
> new technology just for the heck of it... (And there is a reason some
> of the banks still have those mainframes lying around!.) like they say
> "if it ain't broken
Zammetti [mailto:[EMAIL PROTECTED]
Sent: Friday, October 07, 2005 3:08 PM
To: Struts Users Mailing List
Cc: user@struts.apache.org; [EMAIL PROTECTED]
Subject: Re: OT: RE: Development philosophy and such (was: Base action
class)
On Fri, October 7, 2005 2:33 pm, [EMAIL PROTECTED] said:
> Hi Frank,
&
On Fri, October 7, 2005 2:33 pm, [EMAIL PROTECTED] said:
> Hi Frank,
>
>Here's the thing about technology, it *evolves*... and it comes as
> really odd that you *belive* that people introduce new technology
> solution, architecture, design changes, to just make them more
> market-able!!.
It's
ange is not
necessarily a bad thing.
Regards,
Dharmendra
ps: have a good day!
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Friday, October 07, 2005 1:10 PM
To: Leon Rosenberg
Cc: Struts Users Mailing List
Subject: Development philosophy and such (wa
On Fri, October 7, 2005 1:27 pm, Michael Jouravlev said:
> P.S. The last soldier's reply does not exist in original joke, but
> many people I told it to could not get the joke without it ;-)
You really need to find some different people to talk to... the type of
people that wouldn't get it without
On 10/7/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I think we unintentionally hijacked a thread, so just in case we discuss
> any further, a topic change is probably in order...
Tell me about hijacking ;)
On 10/7/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> But I'm absolutely with you,
I think we unintentionally hijacked a thread, so just in case we discuss
any further, a topic change is probably in order...
On Fri, October 7, 2005 12:14 pm, Leon Rosenberg said:
> My leitmotif is always: keep it simple. No ibatis, no hibernate, no
> ejb, no nothing unless you explicitely can pro
On 10/7/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I don't know about you, but I see *WAY TOO MUCH* overengineering in many
> projects. People are so anal about coming up with the absolute perfect
> architectural solution. I'm not saying we shouldn't strive for
> perfection, of course we
Leon, I have a question about this one:
"You don't need to care for exceptions you don't understand
(layer-technically, someone who writes an action doesn't care whether
its an SQLException or a FileNotFoundException)"
If you say, that it should be easy to switch layers, then persistence
layer sh
On Fri, October 7, 2005 3:05 am, Leon Rosenberg said:
> If by persistance layers you mean things like hibernate and/or ibatis,
> I would 100% agree with you.
Yep, that's what I meant :)
> But if you mean that if you have a BL
> POJO, say IMessagingService, which uses two DBs (at least logical)
>
On 10/6/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Leon Rosenberg wrote:
> > Well you shouldn't have anything with Database in the name in your
> > action, it should be encapsulated in a service POJO.
>
> I'm not so sure about this... I understand the motivation for saying it
> and agree wi
Leon Rosenberg wrote:
Well you shouldn't have anything with Database in the name in your
action, it should be encapsulated in a service POJO.
I'm not so sure about this... I understand the motivation for saying it
and agree with that motivation, but it's a bit to hard-and-fast for my
tastes.
On 10/6/05, Koen Jans <[EMAIL PROTECTED]> wrote:
>
> >What BaseActions also can do is to instantiate and manage resources
> >(yes servlet content listener can do this too, but i like to have it
> >in one place), services and so on. They also provide methods to handle
> >request parameters typed (ge
> As for now, i have put the basic stuff there like finding a
> forward for a database faillure and so on..
I handle failures like this using the declarative exception handling
(). One less thing I have to code in my Actions.
> (like in the mailreader example by the way). Also, i have put
> a
nvironment.
(http://struts.apache.org/userGuide/building_controller.html#action_design_guide)
Of an action class, only one instance is created to service all
requests; so is it safe to turn the above statement around and _do_ use
an instance variable "Logger logger" and "Database dat
personally I do overwrite execute in my baseaction and define an
abstract doExecute which all extending classes has to implement and
which is called by the execute method of the BaseAction after all
checks are done.
My BaseAction usually also define methods which can be overridden by
the extending
that needs to be implemented in all teh actions which import the
BaseAction.
Thanks,
Rajasekhar Cherukuri
Please respond to
"Struts Users Mailing List"
To
user@struts.apache.org
cc
Subject
Base action class
Hello,
I am trying to use a BaseAction class for my action,
Hello,
I am trying to use a BaseAction class for my action, and i have been
wondering what to put in there;
As for now, i have put the basic stuff there like finding a forward for
a database faillure and so on..
(like in the mailreader example by the way). Also, i have put a method
that retrieves
41 matches
Mail list logo
