You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Brandon Mercer <br...@eutonian.com> on 2005/02/01 18:19:03 UTC
WAY OT Database Crossroads
Ok, I've officially NOT followed some standard somewhere. :-( Shame on
me! Can somebody help me with the following predicament? I've got a
table of transactions that need to be processed. In that table I have a
column for that persons account number... which gets assigned in a
different table which is keyed on account number and transaction number
:-(. So I can't very well insert.... (break in thought) so I guess I
don't NEED to key it on transaction because that particular table of
information will only have ONE entry with one account number. This
brings me to my next crossroad.
Lets say that I have a table that has a field that references another table
+--------------+---------------------+
| transcode | typeoftrans |
+--------------+---------------------+
|00000002 | payment |
+--------------+---------------------+
|00000003 | transfer |
+--------------+---------------------+
and the value of transtype determines the next table that I have to
insert information into. How do I handle the insert of information in
that scenario? I've got as far as INSERTing it into the first table,
recalling the transcode (which auto_inc), and I know the type of
transaction before I do the insert. Is it best to just have some logic
in my data class that says if (typeoftrans.equals("somevalue")) {
perform this insert
}
I think I may have just answered my own questions... but I'm curious to
see how the savvy struts pros would do it :-). Thanks!
Brandon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by Larry Meadors <la...@gmail.com>.
Actually, I'd keep the decision out of the Action, too.
I would create a TransactionHandler class that does it. You pass it
the information, and it returns information back - it should know
nothing about your web front end, and your web front end should know
as little as possible about the business logic in the backend.
That would also have the added benefit of hiding the strategy pattern
as well, so if you decide that I am smoking crack, and that you want
to implement it a different way, you have an easier time refactoring
and testing (because you do not need struts for the unit tests).
Larry
On Tue, 01 Feb 2005 12:58:02 -0500, Brandon Mercer <br...@eutonian.com> wrote:
> So check to see what type of transaction it is in the Action and then
> send it to the corresponding method in the data class? Sounds good,
> Brandon
> Larry Meadors wrote:
>
> >I think I'd use a strategy pattern for this. Basically, one interface
> >with several implementations; the implementation is dynamically
> >selected at runtime, based on the tranaction type.
> >
> >Larry
> >
> >On Tue, 01 Feb 2005 12:19:03 -0500, Brandon Mercer <br...@eutonian.com> wrote:
> >
> >
> >>Ok, I've officially NOT followed some standard somewhere. :-( Shame on
> >>me! Can somebody help me with the following predicament? I've got a
> >>table of transactions that need to be processed. In that table I have a
> >>column for that persons account number... which gets assigned in a
> >>different table which is keyed on account number and transaction number
> >>:-(. So I can't very well insert.... (break in thought) so I guess I
> >>don't NEED to key it on transaction because that particular table of
> >>information will only have ONE entry with one account number. This
> >>brings me to my next crossroad.
> >>
> >>Lets say that I have a table that has a field that references another table
> >>+--------------+---------------------+
> >> | transcode | typeoftrans |
> >>+--------------+---------------------+
> >> |00000002 | payment |
> >>+--------------+---------------------+
> >> |00000003 | transfer |
> >>+--------------+---------------------+
> >>
> >>and the value of transtype determines the next table that I have to
> >>insert information into. How do I handle the insert of information in
> >>that scenario? I've got as far as INSERTing it into the first table,
> >>recalling the transcode (which auto_inc), and I know the type of
> >>transaction before I do the insert. Is it best to just have some logic
> >>in my data class that says if (typeoftrans.equals("somevalue")) {
> >>perform this insert
> >> }
> >>I think I may have just answered my own questions... but I'm curious to
> >>see how the savvy struts pros would do it :-). Thanks!
> >>Brandon
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by Brandon Mercer <br...@eutonian.com>.
So check to see what type of transaction it is in the Action and then
send it to the corresponding method in the data class? Sounds good,
Brandon
Larry Meadors wrote:
>I think I'd use a strategy pattern for this. Basically, one interface
>with several implementations; the implementation is dynamically
>selected at runtime, based on the tranaction type.
>
>Larry
>
>On Tue, 01 Feb 2005 12:19:03 -0500, Brandon Mercer <br...@eutonian.com> wrote:
>
>
>>Ok, I've officially NOT followed some standard somewhere. :-( Shame on
>>me! Can somebody help me with the following predicament? I've got a
>>table of transactions that need to be processed. In that table I have a
>>column for that persons account number... which gets assigned in a
>>different table which is keyed on account number and transaction number
>>:-(. So I can't very well insert.... (break in thought) so I guess I
>>don't NEED to key it on transaction because that particular table of
>>information will only have ONE entry with one account number. This
>>brings me to my next crossroad.
>>
>>Lets say that I have a table that has a field that references another table
>>+--------------+---------------------+
>> | transcode | typeoftrans |
>>+--------------+---------------------+
>> |00000002 | payment |
>>+--------------+---------------------+
>> |00000003 | transfer |
>>+--------------+---------------------+
>>
>>and the value of transtype determines the next table that I have to
>>insert information into. How do I handle the insert of information in
>>that scenario? I've got as far as INSERTing it into the first table,
>>recalling the transcode (which auto_inc), and I know the type of
>>transaction before I do the insert. Is it best to just have some logic
>>in my data class that says if (typeoftrans.equals("somevalue")) {
>>perform this insert
>> }
>>I think I may have just answered my own questions... but I'm curious to
>>see how the savvy struts pros would do it :-). Thanks!
>>Brandon
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by Brandon Mercer <br...@eutonian.com>.
Brandon Mercer wrote:
> Larry Meadors wrote:
>
>> On Tue, 1 Feb 2005 21:09:46 +0100, PA <pe...@gmail.com> wrote:
>>
>>
>>> Static inner classes, static. Those are simply an extension of the
>>> namespace. Contrast this with the sorry freak of nature which are plain
>>> inner classes.
>>>
>>
>>
>> HAHAHAH! I just inherited some code with a pile of inner classes, and
>> I have to say I agree with you on that "sorry freak of nature"
>> comment. Still not sure I dig static ICs, but am willing to give them
>> the benefit of the doubt...for now.
>>
>> Larry
>
I was able to figure out what I was doing incorrectly. After reading
through chapter 14 of Husted's book Struts in Action, I had two things
jump out at me.
1) all your applications want to say is "I have this piece of data;take
care of it for me"... when it should say "this is what I have, this is
what I want"
2) That I have mixed my business and integration layers into my SQL
statements.
Thanks to all for their help. This list does great when it comes to
helping newbies, pro, and everyone in between (like me ).
Brandon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by Brandon Mercer <br...@eutonian.com>.
Larry Meadors wrote:
>On Tue, 1 Feb 2005 21:09:46 +0100, PA <pe...@gmail.com> wrote:
>
>
>>Static inner classes, static. Those are simply an extension of the
>>namespace. Contrast this with the sorry freak of nature which are plain
>>inner classes.
>>
>>
>
>HAHAHAH! I just inherited some code with a pile of inner classes, and
>I have to say I agree with you on that "sorry freak of nature"
>comment. Still not sure I dig static ICs, but am willing to give them
>the benefit of the doubt...for now.
>
>Larry
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
:-| this stuff is WAAAAAAAAAAYYYYY over my head... :-|
Brandon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by PA <pe...@gmail.com>.
On Feb 01, 2005, at 21:16, Larry Meadors wrote:
> HAHAHAH! I just inherited some code with a pile of inner classes, and
> I have to say I agree with you on that "sorry freak of nature"
> comment. Still not sure I dig static ICs, but am willing to give them
> the benefit of the doubt...for now.
Static inner class is perhaps a misnomer, as they get tainted by
associations with their degenerated cousins, the "inners".
In a nutshell, static don't share anything with their enclosing class
except being in the same source file. Think of them more in terms of
"packaging" then "semantic".
Cheers
--
PA, Onnay Equitursay
http://alt.textdrive.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by Larry Meadors <la...@gmail.com>.
On Tue, 1 Feb 2005 21:09:46 +0100, PA <pe...@gmail.com> wrote:
> Static inner classes, static. Those are simply an extension of the
> namespace. Contrast this with the sorry freak of nature which are plain
> inner classes.
HAHAHAH! I just inherited some code with a pile of inner classes, and
I have to say I agree with you on that "sorry freak of nature"
comment. Still not sure I dig static ICs, but am willing to give them
the benefit of the doubt...for now.
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by PA <pe...@gmail.com>.
On Feb 01, 2005, at 21:03, Larry Meadors wrote:
> Something like that, yes. I have never been a fan of inner classes,
Static inner classes, static. Those are simply an extension of the
namespace. Contrast this with the sorry freak of nature which are plain
inner classes.
> but that is still the idea.
Talking of which, and for entertainment purpose only, here is an
introduction to a post-structuralist object oriented system:
"Lua’s Story of O"
http://alt.textdrive.com/lua/19/lua-story-of-o
Be warned though that this article is rated PG. Parental guidance
suggested. Some material may not be suitable for children.
Cheers
--
PA, Onnay Equitursay
http://alt.textdrive.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by Larry Meadors <la...@gmail.com>.
Something like that, yes. I have never been a fan of inner classes,
but that is still the idea.
On Tue, 1 Feb 2005 18:55:15 +0100, PA <pe...@gmail.com> wrote:
>
> On Feb 01, 2005, at 18:23, Larry Meadors wrote:
>
> > I think I'd use a strategy pattern for this. Basically, one interface
> > with several implementations; the implementation is dynamically
> > selected at runtime, based on the tranaction type.
>
> Perhaps something like this?
>
> http://dev.alt.textdrive.com/file/pl/PLWriter.java
>
> Check the writeObject() instance method.
>
> Cheers
>
> --
> PA, Onnay Equitursay
> http://alt.textdrive.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by PA <pe...@gmail.com>.
On Feb 01, 2005, at 18:23, Larry Meadors wrote:
> I think I'd use a strategy pattern for this. Basically, one interface
> with several implementations; the implementation is dynamically
> selected at runtime, based on the tranaction type.
Perhaps something like this?
http://dev.alt.textdrive.com/file/pl/PLWriter.java
Check the writeObject() instance method.
Cheers
--
PA, Onnay Equitursay
http://alt.textdrive.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: WAY OT Database Crossroads
Posted by Larry Meadors <la...@gmail.com>.
I think I'd use a strategy pattern for this. Basically, one interface
with several implementations; the implementation is dynamically
selected at runtime, based on the tranaction type.
Larry
On Tue, 01 Feb 2005 12:19:03 -0500, Brandon Mercer <br...@eutonian.com> wrote:
> Ok, I've officially NOT followed some standard somewhere. :-( Shame on
> me! Can somebody help me with the following predicament? I've got a
> table of transactions that need to be processed. In that table I have a
> column for that persons account number... which gets assigned in a
> different table which is keyed on account number and transaction number
> :-(. So I can't very well insert.... (break in thought) so I guess I
> don't NEED to key it on transaction because that particular table of
> information will only have ONE entry with one account number. This
> brings me to my next crossroad.
>
> Lets say that I have a table that has a field that references another table
> +--------------+---------------------+
> | transcode | typeoftrans |
> +--------------+---------------------+
> |00000002 | payment |
> +--------------+---------------------+
> |00000003 | transfer |
> +--------------+---------------------+
>
> and the value of transtype determines the next table that I have to
> insert information into. How do I handle the insert of information in
> that scenario? I've got as far as INSERTing it into the first table,
> recalling the transcode (which auto_inc), and I know the type of
> transaction before I do the insert. Is it best to just have some logic
> in my data class that says if (typeoftrans.equals("somevalue")) {
> perform this insert
> }
> I think I may have just answered my own questions... but I'm curious to
> see how the savvy struts pros would do it :-). Thanks!
> Brandon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org