-conversation-scope-doesn%27-t-work-as-property-in-a-base-action-class-tp17404381p17404381.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
:
http://www.nabble.com/model-conversation-scope-doesn%27-t-work-as-property-in-a-base-action-class-tp17404381p17404381.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
-conversation-scope-doesn%27-t-work-as-property-in-a-base-action-class-tp17404381p17404381.html
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
value=model.page /
s:submit value=End /
/s:form
/body
/html
http://www.nabble.com/file/p17404381/testapp.zip testapp.zip
--
View this message in context:
http://www.nabble.com/model-conversation-scope-doesn%27-t-work-as-property-in-a-base-action-class-tp17404381p17404381.html
-doesn%27-t-work-as-property-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
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 got now
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 one of
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 user to
derive an action class
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 dispatch events
* DispatchAction and its flavors do
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 resolves the inheritance issue, allowing any action
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 resolves
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 a user
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
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. Looking
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.
*
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]
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 the
be the *implementors of change*
Have a good day all,
Martin-
- Original Message -
From: [EMAIL PROTECTED]
To: user@struts.apache.org; [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 thing
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 with that
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)
like
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
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, if
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
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 (was: Base action class)
I think we unintentionally hijacked a thread, so just in case we discuss
any further
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 not
, 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,
Here's the thing about technology, it *evolves
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,
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,
Here's the thing
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 think the
_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:
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
,
that needs to be implemented in all teh actions which import the
BaseAction.
Thanks,
Rajasekhar Cherukuri
Please respond to
Struts Users Mailing List user@struts.apache.org
To
user@struts.apache.org
cc
Subject
Base action class
Hello,
I am trying to use a BaseAction class for my
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
/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 database in the Base
Action class, of which in fact we want one
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
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.
36 matches
Mail list logo
