You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by David Mulligan <da...@LECAN.ie> on 2002/08/09 11:46:09 UTC
RE: Struts & Persistence
Hey James,
I'm just wondering if you have made any progress on your struts-example
using OJB?
Tnx,
Dave.
-----Original Message-----
From: James Mitchell [mailto:jmitchtx@telocity.com]
Sent: Tuesday, July 23, 2002 7:22 PM
To: Struts Users Mailing List
Subject: RE: Struts & Persistence
I'll be uploading a modified version of the example app (struts-example.war)
which uses OJB as soon as I can finish it.
Basic O/R mapping using JDO API w/MySql on the backend.
It's not there yet, but here's the url:
http://sourceforge.net/projects/struts/
James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta
> -----Original Message-----
> From: Elderclei R Reami [mailto:reami@vertisnet.com.br]
> Sent: Tuesday, July 23, 2002 2:54 PM
> To: struts-user@jakarta.apache.org
> Subject: Struts & Persistence
>
>
> Hi again,
>
> Does anyone know about usage of persistence frameworks, like Torque & OJB
> from Apache Group, with Struts?
>
> Thanks for all the help with code generation. I downloaded StrutsBuilder
> and Eclipse+EasyStruts to evaluate and they are great tools. About self-
> generated apps from database schema and beer... Huhr! Sounds nice and we
> can start a new project from the idea :)
>
> Best Regards,
> Elder
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts & Persistence
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 9 Aug 2002, BaTien Duong wrote:
> Date: Fri, 9 Aug 2002 10:00:17 -0600
> From: BaTien Duong <ba...@dbgroups.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Struts & Persistence
>
> How about transactional processing over a number of data sources? e.g. first
> level of user profile is in Ldap, second level of user profile is in RDBMS.
> That is the power of portal "vision". I hope this vision may stimulate
> others.
>
I hope you're hiding the two-layer access under a DAO so that the poor app
developer writing portlets doesn't have to worry about that kind of
detail ...
Craig
> ----- Original Message -----
> From: "Eddie Bush" <ek...@swbell.net>
> To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> Sent: Friday, August 09, 2002 9:33 AM
> Subject: Re: Struts & Persistence
>
>
> > BaTien Duong wrote:
> >
> > >OJB is very important,
> > >
> > Personally, I think that's an understatement. At this point (and I
> > think they're fixing to do some major refactoring, so it would be hard
> > to speak of what will come), from what I can tell, all configuration is
> > very declarative. What does this mean to the user? Basically, it means
> > that once you get things working right under one DBMS you can probably
> > switch to another just by changing the definition of your data-source!
> > *That* is power!
> >
> > >especially combined with Struts 1.1 framework and
> > >"Struts pattern" of DAO to be independent of data sources: Directory,
> RDBMS,
> > >XML. I hope Struts user group gets more interest in this and in the
> concept
> > >of basicPortal that ties Struts, Tiles, and Event processing together.
> > >
> > >Great works and great community. :-)
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts & Persistence
Posted by BaTien Duong <ba...@dbgroups.com>.
How about transactional processing over a number of data sources? e.g. first
level of user profile is in Ldap, second level of user profile is in RDBMS.
That is the power of portal "vision". I hope this vision may stimulate
others.
----- Original Message -----
From: "Eddie Bush" <ek...@swbell.net>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Friday, August 09, 2002 9:33 AM
Subject: Re: Struts & Persistence
> BaTien Duong wrote:
>
> >OJB is very important,
> >
> Personally, I think that's an understatement. At this point (and I
> think they're fixing to do some major refactoring, so it would be hard
> to speak of what will come), from what I can tell, all configuration is
> very declarative. What does this mean to the user? Basically, it means
> that once you get things working right under one DBMS you can probably
> switch to another just by changing the definition of your data-source!
> *That* is power!
>
> >especially combined with Struts 1.1 framework and
> >"Struts pattern" of DAO to be independent of data sources: Directory,
RDBMS,
> >XML. I hope Struts user group gets more interest in this and in the
concept
> >of basicPortal that ties Struts, Tiles, and Event processing together.
> >
> >Great works and great community. :-)
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts & Persistence
Posted by "Robert J. Sanford, Jr." <rs...@trefs.com>.
> >OJB is very important,
> >
> Personally, I think that's an understatement. At this point
> (and I think they're fixing to do some major refactoring, so
> it would be hard to speak of what will come), from what I can
> tell, all configuration is very declarative. What does this
> mean to the user? Basically, it means that once you get
> things working right under one DBMS you can probably switch
> to another just by changing the definition of your data-
> source!
> *That* is power!
rjsjr
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts & Persistence
Posted by Eddie Bush <ek...@swbell.net>.
BaTien Duong wrote:
>OJB is very important,
>
Personally, I think that's an understatement. At this point (and I
think they're fixing to do some major refactoring, so it would be hard
to speak of what will come), from what I can tell, all configuration is
very declarative. What does this mean to the user? Basically, it means
that once you get things working right under one DBMS you can probably
switch to another just by changing the definition of your data-source!
*That* is power!
>especially combined with Struts 1.1 framework and
>"Struts pattern" of DAO to be independent of data sources: Directory, RDBMS,
>XML. I hope Struts user group gets more interest in this and in the concept
>of basicPortal that ties Struts, Tiles, and Event processing together.
>
>Great works and great community. :-)
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts & Persistence
Posted by BaTien Duong <ba...@dbgroups.com>.
OJB is very important, especially combined with Struts 1.1 framework and
"Struts pattern" of DAO to be independent of data sources: Directory, RDBMS,
XML. I hope Struts user group gets more interest in this and in the concept
of basicPortal that ties Struts, Tiles, and Event processing together.
Great works and great community. :-)
----- Original Message -----
From: "Eddie Bush" <ek...@swbell.net>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Friday, August 09, 2002 8:37 AM
Subject: Re: Struts & Persistence
> (David) It should be noted that the ODMG is an immediate precursor to
> JDO, and, therefore, quite similar. If you search the OJB archives
> you'll find suggestions on how to plan a transition to JDO, once that
> functionality is production-ready. Look for threads by Thomas Mahler -
> I think he's OJB's "daddy".
>
> (James) Get that Linux box up?! :-)
>
> James Mitchell wrote:
>
> >Actually, yes I am.
> >
> >Although, now that I'm a little more familiar with OJB, I must admit that
I
> >won't be using the JDO implementation, its not complete. I'm going with
> >ODMG.
> >
> >If I don't get slammed today at work, I should be finished.
> >
> >>-----Original Message-----
> >>From: David Mulligan [mailto:david.mulligan@LECAN.ie]
> >>
> >>Hey James,
> >>
> >>I'm just wondering if you have made any progress on your struts-example
> >>using OJB?
> >>
> >>Tnx,
> >>Dave.
> >>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts & Persistence
Posted by Eddie Bush <ek...@swbell.net>.
Craig R. McClanahan wrote:
><Friday Alert>
>
>I'm old enough to remember being absolutely giddy over the
>amount of space available on my first hard disk drive -- ten whole
>*mega*bytes! Whatever would I do with all of that space?
>
></Friday Alert>
>
>Craig
>
LOL - my first one had 100 MB - MAN how I echoed your feelings! LOL.
The sad thing (in retrospect) is that when I got my first 1.2 GB drive,
I was naive enough to think that *surely* I wouldn't ever need a larger one!
... what a blast from the past :-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Recommended to use static enumeration
Posted by "Philip S. Constantinou" <ph...@wayfinder.net>.
What is the recommended way to access static enumerations from taglibs? I've
defined a static enumeration class (see below) and I'd like to have an
elegant way to access them in the view. Right now I have to put Java in my
JSP pages which I'd prefer not to do.
This is what I do now:
<% pageContext.setAttribute("statuses", myPackage.Status.getStatuses()); %>
<logic:iterate id="status" name="statuses" type="myPackage.Status">
<bean:write name="status" property="name"/><br>
</logic:iterate>
Is there a better way?
Thanks -
Phil
My static enumerations look like this:
public class Status {
private static HashSet_map = new HashSet();
public static final Status PASS = new Status("PASS","Pass");
public static final Status FAIL = new Status("FAIL","Fail");
public static final Status REJECT= new Status("RJCT","Reject");
protected Status(String code, String name) {
this.code = code;
this.name = name;
_map.put(code, this);
}
public String getName() {
return name;
}
public String getCode() {
return code;
}
public static final Collection getStatuses() {
return _values.values();
}
public static Status getStatus(String code) {
return (Status)_map.get(code);
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another architecture question
Posted by Jacob Hookom <ho...@uwec.edu>.
| -----Original Message-----
| From: sean.schofield@verizon.net [mailto:sean.schofield@verizon.net]
| Sent: Saturday, August 10, 2002 3:50 PM
| To: Struts Users Mailing List
| Subject: Re: Another architecture question
|
| Thanks for the quick response.
|
| Ok so I will stick with my instincts and abandon any db code in these
| helper
| beans. I do have a couple of additional questions and thoughts in
light
| of
| the second part of your answer.
|
| It sounds like in your example that LogicController.validate() would
do
| the
| updating of the database once you "passed" the form-level validation.
Is
| this correct? If so, maybe changing the wording to
| ServiceDelegate.updateSomeDomainObject() would more accurately
describe
| things? The forms are accessing a service layer object right? (I'm
not
| being critical of your naming suggestion, just curious since I'm a
little
| shaky on some of these architecture concepts).
A lot of people use a DAO implementation to really separate java and
sql. The best way to go about this is to create a really generic
framework that knows nothing of your business logic, but is configurable
via XML:
http://www.javaworld.com/javaworld/jw-03-2002/jw-0301-dao.html
The basic goal is to provide translation from a result set to a List of
business beans. I don't even bother with memory level caching, but
there are some nice implementations out there that others can recommend
such as Castor the more closely pair business objects and your database.
I use an implementation much like this:
http://www.javaworld.com/javaworld/jw-05-2002/jw-0524-sql.html
I define "commands" in my xml along with object mappings which are just
pairs of columns to bean properties. My XML config file looks like this:
<jfuse-config>
<command alias="com_user_login"
dataSource="java:comp/env/jdbc/cp"
sql="select usrUsrID, usrEmail, usrPassword, usrCreated from
tbl_user where usrEmail = ? and usrPassword = ?"
/>
<object-map className="com.dds.module.bean.User" alias="map_user">
<property sql="usrUsrID" property="id"/>
<property sql="usrEmail" property="login"/>
<property sql="usrPassword" property="password"/>
<property sql="usrCreated" property="created"/>
</object-map>
</jfuse-config>
Then in my login action, my code looks like this:
// my sql processor
JFuse jfuse = JFuse.getInstance(servlet.getContext());
// get my command and my object map
Command loginCommand = jfuse.getCommand("com_user_login");
ObjectMap userMap = jfuse.getObjectMap("map_user");
// setup params to get user login
Object[] params = new Object[] {
form.getLogin().trim(),
form.getPassword().trim() }
// execute query
User user = (User) jfuse.doQuery(
loginCommand,
params,
userMap);
if ( user == null )
throw new InvalidLoginException();
else
{
// put data in session
}
|
| In any event, it sounds like you are propsing that this
LogicController
| access the database for me and that this LogicController could be a
simple
| java object. I'm assuming in a more complicated system, this could be
| replaced by session ejb which talk to entity ejb (aka Session Facade).
I
| certainly don't need the domain layer for just a few objects but the
| facade
| to the database still might be helpful.
|
| One final question, suggest that the form call this LogicController
class.
| What about doing this in the action's perform/execute method? My
thinking
| is that this will allow you to catch exceptions, etc. and use some of
the
| 1.1 exception stuff (like forwarding to an error page).
|
Very true, I use the struts validator with my forms. Really, the
validate method should only make sure the information submitted by the
user is valid; your business logic should be pushed to the action.
Validate should check for null or zero length parameters and for string
expressions (is it a valid phone number or email address).
| Thanks again for your insight,
|
| - sean
|
|
|
| ----- Original Message -----
| From: "Jacob Hookom" <ho...@uwec.edu>
| To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
| Sent: Saturday, August 10, 2002 4:31 PM
| Subject: RE: Another architecture question
|
|
| >
| >
| > | -----Original Message-----
| > | From: sean.schofield@verizon.net
[mailto:sean.schofield@verizon.net]
| > | Sent: Saturday, August 10, 2002 3:20 PM
| > | To: Struts Users Mailing List
| > | Subject: Another architecture question
| > |
| > | I am still a little confused about the proper way to architect a
| > struts
| > | application. In my application, I am using some "helper beans" in
my
| > | ActionForms. They are created when my action form is
instantiated.
| > The
| > | beans also have some behind the scenese JDBC logic going on since
they
| > | represent my "model."
| > |
| > | Currently when certain properties on these beans are set, they
update
| > the
| > | database behind the scenes. Oh and I also have some db code in
the
| > | constructors of a few of them. My gut instinct tells me this is
| > wrong.
| > | My
| > | first concern is that can these properties be set before
validate() is
| > | called? Because this would allow (or attempt) a db update even if
| > there
| > | was
| > | a problem!
| > |
| > | Also, there is the matter of exceptions. What happens if the
| > constructor
| > | (which is looking up a list to populate the bean with) fails? I
am
| > | reusing
| > | a single form throughout my application so sometimes there would
be db
| > | access when the form is created and then passed to the view and
| > sometimes
| > | when the form was submitted to a follow-up action that would also
use
| > the
| > | same form.
| > |
| > | It seems to me that these beans are only for storing data in
memory
| > and
| > | passing around. Maybe they shouldn't even have db logic? Or if
they
| > did,
| > | maybe the place to access it is from the action?
| >
| > Correct, business beans like you are describing 'should' just hold
| > state. Your accessor methods (get/set) should not execute or modify
the
| > bean in any other way other than assigning the passed value to the
| > specified attribute.
| >
| > In your validate, you may want to look at creating a context-based
| > singleton that handles the control of your business bean logic
whereas
| > you can do something like this in actionForm.validate():
| >
| > LogicController lc =
LogicController.getInstance(servlet.getContext());
| > boolean valid = lc.validatePurchase(this);
| >
| > This way, your logic controller may be configured by a properties
file
| > or xml file where your sql code itself is contained. One way to
really
| > separate your struts implementation and your business layer is to
use
| > interfaces that your action forms implement.
| >
| > -Jake
| >
| > |
| > | Any thoughts?
| > |
| > | TIA,
| > |
| > | - sean
| > |
| > |
| > | --
| > | To unsubscribe, e-mail: <mailto:struts-user-
| > | unsubscribe@jakarta.apache.org>
| > | For additional commands, e-mail: <mailto:struts-user-
| > | help@jakarta.apache.org>
| > |
| > | ---
| > | Incoming mail is certified Virus Free.
| > | Checked by AVG anti-virus system (http://www.grisoft.com).
| > | Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
| > |
| >
| > ---
| > Outgoing mail is certified Virus Free.
| > Checked by AVG anti-virus system (http://www.grisoft.com).
| > Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
| >
| >
| >
| > --
| > To unsubscribe, e-mail:
| <ma...@jakarta.apache.org>
| > For additional commands, e-mail:
| <ma...@jakarta.apache.org>
| >
|
|
| --
| To unsubscribe, e-mail: <mailto:struts-user-
| unsubscribe@jakarta.apache.org>
| For additional commands, e-mail: <mailto:struts-user-
| help@jakarta.apache.org>
|
| ---
| Incoming mail is certified Virus Free.
| Checked by AVG anti-virus system (http://www.grisoft.com).
| Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
|
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another architecture question
Posted by se...@verizon.net.
Thanks for the quick response.
Ok so I will stick with my instincts and abandon any db code in these helper
beans. I do have a couple of additional questions and thoughts in light of
the second part of your answer.
It sounds like in your example that LogicController.validate() would do the
updating of the database once you "passed" the form-level validation. Is
this correct? If so, maybe changing the wording to
ServiceDelegate.updateSomeDomainObject() would more accurately describe
things? The forms are accessing a service layer object right? (I'm not
being critical of your naming suggestion, just curious since I'm a little
shaky on some of these architecture concepts).
In any event, it sounds like you are propsing that this LogicController
access the database for me and that this LogicController could be a simple
java object. I'm assuming in a more complicated system, this could be
replaced by session ejb which talk to entity ejb (aka Session Facade). I
certainly don't need the domain layer for just a few objects but the facade
to the database still might be helpful.
One final question, suggest that the form call this LogicController class.
What about doing this in the action's perform/execute method? My thinking
is that this will allow you to catch exceptions, etc. and use some of the
1.1 exception stuff (like forwarding to an error page).
Thanks again for your insight,
- sean
----- Original Message -----
From: "Jacob Hookom" <ho...@uwec.edu>
To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
Sent: Saturday, August 10, 2002 4:31 PM
Subject: RE: Another architecture question
>
>
> | -----Original Message-----
> | From: sean.schofield@verizon.net [mailto:sean.schofield@verizon.net]
> | Sent: Saturday, August 10, 2002 3:20 PM
> | To: Struts Users Mailing List
> | Subject: Another architecture question
> |
> | I am still a little confused about the proper way to architect a
> struts
> | application. In my application, I am using some "helper beans" in my
> | ActionForms. They are created when my action form is instantiated.
> The
> | beans also have some behind the scenese JDBC logic going on since they
> | represent my "model."
> |
> | Currently when certain properties on these beans are set, they update
> the
> | database behind the scenes. Oh and I also have some db code in the
> | constructors of a few of them. My gut instinct tells me this is
> wrong.
> | My
> | first concern is that can these properties be set before validate() is
> | called? Because this would allow (or attempt) a db update even if
> there
> | was
> | a problem!
> |
> | Also, there is the matter of exceptions. What happens if the
> constructor
> | (which is looking up a list to populate the bean with) fails? I am
> | reusing
> | a single form throughout my application so sometimes there would be db
> | access when the form is created and then passed to the view and
> sometimes
> | when the form was submitted to a follow-up action that would also use
> the
> | same form.
> |
> | It seems to me that these beans are only for storing data in memory
> and
> | passing around. Maybe they shouldn't even have db logic? Or if they
> did,
> | maybe the place to access it is from the action?
>
> Correct, business beans like you are describing 'should' just hold
> state. Your accessor methods (get/set) should not execute or modify the
> bean in any other way other than assigning the passed value to the
> specified attribute.
>
> In your validate, you may want to look at creating a context-based
> singleton that handles the control of your business bean logic whereas
> you can do something like this in actionForm.validate():
>
> LogicController lc = LogicController.getInstance(servlet.getContext());
> boolean valid = lc.validatePurchase(this);
>
> This way, your logic controller may be configured by a properties file
> or xml file where your sql code itself is contained. One way to really
> separate your struts implementation and your business layer is to use
> interfaces that your action forms implement.
>
> -Jake
>
> |
> | Any thoughts?
> |
> | TIA,
> |
> | - sean
> |
> |
> | --
> | To unsubscribe, e-mail: <mailto:struts-user-
> | unsubscribe@jakarta.apache.org>
> | For additional commands, e-mail: <mailto:struts-user-
> | help@jakarta.apache.org>
> |
> | ---
> | Incoming mail is certified Virus Free.
> | Checked by AVG anti-virus system (http://www.grisoft.com).
> | Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
> |
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Collecting data from several jsp
Posted by Olga Agady <oa...@yahoo.com>.
Thanks again, Robert
I believe the approach with the session-timeout is
better than having dozens of hidden fields. Having
information in the bean is easier to debug.
Thanks
Olga
--- Robert Taylor <rt...@mulework.com> wrote:
> You can set the session time out in web.xml for the
> web application.
>
> <session-config>
> <session-timeout>30</session-timeout>
> </session-config>
>
> When the session times out, your bean will gc'd.
>
> If your bean uses any resources, then you may want
> to wrap it
> in a class that implements
> HttpSessionBindingListener interface.
>
> From the API:
> HttpSessionBindingListener:
>
> Causes an object to be notified when it is bound to
> or
> unbound from a session. The object is notified by an
>
> HttpSessionBindingEvent object. This may be as a
> result
> of a servlet programmer explicitly unbinding an
> attribute
> from a session, due to a session being invalidated,
> or
> die to a session timing out.
>
> Good luck,
>
> robert
>
>
> > -----Original Message-----
> > From: Olga Agady [mailto:oagady@yahoo.com]
> > Sent: Sunday, August 11, 2002 9:32 PM
> > To: Struts Users Mailing List
> > Subject: RE: Collecting data from several jsp
> >
> >
> > Thanks, Robert
> >
> > I believe the second approach is better for me. I
> have
> > to build the site having in mind that there might
> be a
> > number customers connected to the site at the same
> > time and many of them might start registering and
> > change their mind somewhere in the middle of the
> > process. So, leaving a number of JaveBeans in the
> > session is really risky (unless I can set a
> session
> > time out and remove the abandoned bean when it is
> > timed out).
> >
> > Thanks again
> > Olga
> >
> > --- Robert Taylor <rt...@mulework.com> wrote:
> > > One possible solution is to store information
> > > collected from your forms and
> > > store it in a JavaBean in your session. After
> you
> > > persist the information
> > > you could remove the bean from the session.
> > >
> > > You do run the risk of the user leaving the
> process
> > > and having data hanging
> > > around.
> > >
> > > Another solution is to "store" the collected
> > > information in hidden form
> > > fields as the user progresses through the
> process.
> > > This way if they leave
> > > the process, no data is left hanging around.
> > >
> > > This has been discussed before; check the mail
> > > archives at
> > >
> >
>
http://www.mail-archive.com/struts-user%40jakarta.apache.org/
> > >
> > > HTH,
> > >
> > > robert
> > >
> > > > -----Original Message-----
> > > > From: Olga Agady [mailto:oagady@yahoo.com]
> > > > Sent: Sunday, August 11, 2002 3:21 PM
> > > > To: Struts Users Mailing List
> > > > Subject: Collecting data from several jsp
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I am using struts in my web application. To
> > > register a
> > > > customer a need several JSPs with different
> forms.
> > > The
> > > > data are not stored in the database until the
> last
> > > > form is filled and "Submit" button is clicked.
> > > Could
> > > > someone recommed me a good design for
> collecting
> > > data
> > > > from several JSPs using struts? Probably this
> is a
> > > > basic question, but I am new in
> web-application
> > > > programming and would appreciate any help.
> > > >
> > > > Regards
> > > > Olga
> > > >
> > > >
> __________________________________________________
> > > > Do You Yahoo!?
> > > > HotJobs - Search Thousands of New Jobs
> > > > http://www.hotjobs.com
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > >
> > >
> <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > HotJobs - Search Thousands of New Jobs
> > http://www.hotjobs.com
> >
> > --
> > To unsubscribe, e-mail:
> >
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Collecting data from several jsp
Posted by Robert Taylor <rt...@mulework.com>.
You can set the session time out in web.xml for the web application.
<session-config>
<session-timeout>30</session-timeout>
</session-config>
When the session times out, your bean will gc'd.
If your bean uses any resources, then you may want to wrap it
in a class that implements HttpSessionBindingListener interface.
>From the API:
HttpSessionBindingListener:
Causes an object to be notified when it is bound to or
unbound from a session. The object is notified by an
HttpSessionBindingEvent object. This may be as a result
of a servlet programmer explicitly unbinding an attribute
from a session, due to a session being invalidated, or
die to a session timing out.
Good luck,
robert
> -----Original Message-----
> From: Olga Agady [mailto:oagady@yahoo.com]
> Sent: Sunday, August 11, 2002 9:32 PM
> To: Struts Users Mailing List
> Subject: RE: Collecting data from several jsp
>
>
> Thanks, Robert
>
> I believe the second approach is better for me. I have
> to build the site having in mind that there might be a
> number customers connected to the site at the same
> time and many of them might start registering and
> change their mind somewhere in the middle of the
> process. So, leaving a number of JaveBeans in the
> session is really risky (unless I can set a session
> time out and remove the abandoned bean when it is
> timed out).
>
> Thanks again
> Olga
>
> --- Robert Taylor <rt...@mulework.com> wrote:
> > One possible solution is to store information
> > collected from your forms and
> > store it in a JavaBean in your session. After you
> > persist the information
> > you could remove the bean from the session.
> >
> > You do run the risk of the user leaving the process
> > and having data hanging
> > around.
> >
> > Another solution is to "store" the collected
> > information in hidden form
> > fields as the user progresses through the process.
> > This way if they leave
> > the process, no data is left hanging around.
> >
> > This has been discussed before; check the mail
> > archives at
> >
> http://www.mail-archive.com/struts-user%40jakarta.apache.org/
> >
> > HTH,
> >
> > robert
> >
> > > -----Original Message-----
> > > From: Olga Agady [mailto:oagady@yahoo.com]
> > > Sent: Sunday, August 11, 2002 3:21 PM
> > > To: Struts Users Mailing List
> > > Subject: Collecting data from several jsp
> > >
> > >
> > > Hello,
> > >
> > > I am using struts in my web application. To
> > register a
> > > customer a need several JSPs with different forms.
> > The
> > > data are not stored in the database until the last
> > > form is filled and "Submit" button is clicked.
> > Could
> > > someone recommed me a good design for collecting
> > data
> > > from several JSPs using struts? Probably this is a
> > > basic question, but I am new in web-application
> > > programming and would appreciate any help.
> > >
> > > Regards
> > > Olga
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > HotJobs - Search Thousands of New Jobs
> > > http://www.hotjobs.com
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Collecting data from several jsp
Posted by Olga Agady <oa...@yahoo.com>.
Thanks, Robert
I believe the second approach is better for me. I have
to build the site having in mind that there might be a
number customers connected to the site at the same
time and many of them might start registering and
change their mind somewhere in the middle of the
process. So, leaving a number of JaveBeans in the
session is really risky (unless I can set a session
time out and remove the abandoned bean when it is
timed out).
Thanks again
Olga
--- Robert Taylor <rt...@mulework.com> wrote:
> One possible solution is to store information
> collected from your forms and
> store it in a JavaBean in your session. After you
> persist the information
> you could remove the bean from the session.
>
> You do run the risk of the user leaving the process
> and having data hanging
> around.
>
> Another solution is to "store" the collected
> information in hidden form
> fields as the user progresses through the process.
> This way if they leave
> the process, no data is left hanging around.
>
> This has been discussed before; check the mail
> archives at
>
http://www.mail-archive.com/struts-user%40jakarta.apache.org/
>
> HTH,
>
> robert
>
> > -----Original Message-----
> > From: Olga Agady [mailto:oagady@yahoo.com]
> > Sent: Sunday, August 11, 2002 3:21 PM
> > To: Struts Users Mailing List
> > Subject: Collecting data from several jsp
> >
> >
> > Hello,
> >
> > I am using struts in my web application. To
> register a
> > customer a need several JSPs with different forms.
> The
> > data are not stored in the database until the last
> > form is filled and "Submit" button is clicked.
> Could
> > someone recommed me a good design for collecting
> data
> > from several JSPs using struts? Probably this is a
> > basic question, but I am new in web-application
> > programming and would appreciate any help.
> >
> > Regards
> > Olga
> >
> > __________________________________________________
> > Do You Yahoo!?
> > HotJobs - Search Thousands of New Jobs
> > http://www.hotjobs.com
> >
> > --
> > To unsubscribe, e-mail:
> >
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Collecting data from several jsp
Posted by Robert Taylor <rt...@mulework.com>.
One possible solution is to store information collected from your forms and
store it in a JavaBean in your session. After you persist the information
you could remove the bean from the session.
You do run the risk of the user leaving the process and having data hanging
around.
Another solution is to "store" the collected information in hidden form
fields as the user progresses through the process. This way if they leave
the process, no data is left hanging around.
This has been discussed before; check the mail archives at
http://www.mail-archive.com/struts-user%40jakarta.apache.org/
HTH,
robert
> -----Original Message-----
> From: Olga Agady [mailto:oagady@yahoo.com]
> Sent: Sunday, August 11, 2002 3:21 PM
> To: Struts Users Mailing List
> Subject: Collecting data from several jsp
>
>
> Hello,
>
> I am using struts in my web application. To register a
> customer a need several JSPs with different forms. The
> data are not stored in the database until the last
> form is filled and "Submit" button is clicked. Could
> someone recommed me a good design for collecting data
> from several JSPs using struts? Probably this is a
> basic question, but I am new in web-application
> programming and would appreciate any help.
>
> Regards
> Olga
>
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Collecting data from several jsp
Posted by Olga Agady <oa...@yahoo.com>.
Hello,
I am using struts in my web application. To register a
customer a need several JSPs with different forms. The
data are not stored in the database until the last
form is filled and "Submit" button is clicked. Could
someone recommed me a good design for collecting data
from several JSPs using struts? Probably this is a
basic question, but I am new in web-application
programming and would appreciate any help.
Regards
Olga
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Another architecture question
Posted by Jacob Hookom <ho...@uwec.edu>.
| -----Original Message-----
| From: sean.schofield@verizon.net [mailto:sean.schofield@verizon.net]
| Sent: Saturday, August 10, 2002 3:20 PM
| To: Struts Users Mailing List
| Subject: Another architecture question
|
| I am still a little confused about the proper way to architect a
struts
| application. In my application, I am using some "helper beans" in my
| ActionForms. They are created when my action form is instantiated.
The
| beans also have some behind the scenese JDBC logic going on since they
| represent my "model."
|
| Currently when certain properties on these beans are set, they update
the
| database behind the scenes. Oh and I also have some db code in the
| constructors of a few of them. My gut instinct tells me this is
wrong.
| My
| first concern is that can these properties be set before validate() is
| called? Because this would allow (or attempt) a db update even if
there
| was
| a problem!
|
| Also, there is the matter of exceptions. What happens if the
constructor
| (which is looking up a list to populate the bean with) fails? I am
| reusing
| a single form throughout my application so sometimes there would be db
| access when the form is created and then passed to the view and
sometimes
| when the form was submitted to a follow-up action that would also use
the
| same form.
|
| It seems to me that these beans are only for storing data in memory
and
| passing around. Maybe they shouldn't even have db logic? Or if they
did,
| maybe the place to access it is from the action?
Correct, business beans like you are describing 'should' just hold
state. Your accessor methods (get/set) should not execute or modify the
bean in any other way other than assigning the passed value to the
specified attribute.
In your validate, you may want to look at creating a context-based
singleton that handles the control of your business bean logic whereas
you can do something like this in actionForm.validate():
LogicController lc = LogicController.getInstance(servlet.getContext());
boolean valid = lc.validatePurchase(this);
This way, your logic controller may be configured by a properties file
or xml file where your sql code itself is contained. One way to really
separate your struts implementation and your business layer is to use
interfaces that your action forms implement.
-Jake
|
| Any thoughts?
|
| TIA,
|
| - sean
|
|
| --
| To unsubscribe, e-mail: <mailto:struts-user-
| unsubscribe@jakarta.apache.org>
| For additional commands, e-mail: <mailto:struts-user-
| help@jakarta.apache.org>
|
| ---
| Incoming mail is certified Virus Free.
| Checked by AVG anti-virus system (http://www.grisoft.com).
| Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
|
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Another architecture question
Posted by se...@verizon.net.
I am still a little confused about the proper way to architect a struts
application. In my application, I am using some "helper beans" in my
ActionForms. They are created when my action form is instantiated. The
beans also have some behind the scenese JDBC logic going on since they
represent my "model."
Currently when certain properties on these beans are set, they update the
database behind the scenes. Oh and I also have some db code in the
constructors of a few of them. My gut instinct tells me this is wrong. My
first concern is that can these properties be set before validate() is
called? Because this would allow (or attempt) a db update even if there was
a problem!
Also, there is the matter of exceptions. What happens if the constructor
(which is looking up a list to populate the bean with) fails? I am reusing
a single form throughout my application so sometimes there would be db
access when the form is created and then passed to the view and sometimes
when the form was submitted to a follow-up action that would also use the
same form.
It seems to me that these beans are only for storing data in memory and
passing around. Maybe they shouldn't even have db logic? Or if they did,
maybe the place to access it is from the action?
Any thoughts?
TIA,
- sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts & Persistence
Posted by Robert Morse <rm...@mdesignz.com>.
Man walks upright
...
8" Floppies
Pertec D3000 (5 Mb fixed, 5 Mb removable)
MITS Altair S-100 Bus (I still have this!)
...
Wheel Invented!
...
IMSAI
Link-8
Alpha-Micro
...
Industrial Revolution begins!
...
360-30
...
Man takes flight!
...
Every PDP-XX
Every DG computer known to man (I'm still in therapy because of this)
VAX
...
Motorola 68000 Exormacs
More PCs than I can remember
Sequent
And even more PCs
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Friday, August 09, 2002 9:24 AM
To: Struts Users Mailing List
Subject: RE: Struts & Persistence
On Fri, 9 Aug 2002, James Mitchell wrote:
> Date: Fri, 9 Aug 2002 11:43:58 -0400
> From: James Mitchell <jm...@telocity.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts & Persistence
>
> HAHAHA....Yes, and that's fine if you're not trying to backup 17
> Gig....sheesh.
>
<Friday Alert>
I'm old enough to remember being absolutely giddy over the
amount of space available on my first hard disk drive -- ten whole
*mega*bytes! Whatever would I do with all of that space?
</Friday Alert>
Craig
> James "Sasquatch on crack" Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://www.open-tools.org/struts-atlanta
>
>
>
>
> > -----Original Message-----
> > From: Eddie Bush [mailto:ekbush@swbell.net]
> > Sent: Friday, August 09, 2002 11:37 AM
> > To: Struts Users Mailing List
> > Subject: Re: Struts & Persistence
> >
> >
> > James Mitchell wrote:
> >
> > >>(James) Get that Linux box up?! :-)
> > >>
> > >LOL......no I started consolidating my Laptop HD and noticed
> > that I didn't
> > >have enough room on my file server to backup what I had. So I'll have
to
> > >either get another 80 Gig or take the time to go through and
> > delete all that
> > >Free Software I seem to keep collecting.
> > >
> > >Hey, I wonder what 'format c:\' does. Oh SHI#!!!!!!! STOP STOP STO
> > >
> > Ever heard of CD-R/CD-RW? They really are quite handy :-) ... and
> > CD-R/Ws (disks and writers too) are really quite cheap!
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts & Persistence
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 9 Aug 2002, James Mitchell wrote:
> Date: Fri, 9 Aug 2002 11:43:58 -0400
> From: James Mitchell <jm...@telocity.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts & Persistence
>
> HAHAHA....Yes, and that's fine if you're not trying to backup 17
> Gig....sheesh.
>
<Friday Alert>
I'm old enough to remember being absolutely giddy over the
amount of space available on my first hard disk drive -- ten whole
*mega*bytes! Whatever would I do with all of that space?
</Friday Alert>
Craig
> James "Sasquatch on crack" Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://www.open-tools.org/struts-atlanta
>
>
>
>
> > -----Original Message-----
> > From: Eddie Bush [mailto:ekbush@swbell.net]
> > Sent: Friday, August 09, 2002 11:37 AM
> > To: Struts Users Mailing List
> > Subject: Re: Struts & Persistence
> >
> >
> > James Mitchell wrote:
> >
> > >>(James) Get that Linux box up?! :-)
> > >>
> > >LOL......no I started consolidating my Laptop HD and noticed
> > that I didn't
> > >have enough room on my file server to backup what I had. So I'll have to
> > >either get another 80 Gig or take the time to go through and
> > delete all that
> > >Free Software I seem to keep collecting.
> > >
> > >Hey, I wonder what 'format c:\' does. Oh SHI#!!!!!!! STOP STOP STO
> > >
> > Ever heard of CD-R/CD-RW? They really are quite handy :-) ... and
> > CD-R/Ws (disks and writers too) are really quite cheap!
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts & Persistence
Posted by James Mitchell <jm...@telocity.com>.
HAHAHA....Yes, and that's fine if you're not trying to backup 17
Gig....sheesh.
James "Sasquatch on crack" Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta
> -----Original Message-----
> From: Eddie Bush [mailto:ekbush@swbell.net]
> Sent: Friday, August 09, 2002 11:37 AM
> To: Struts Users Mailing List
> Subject: Re: Struts & Persistence
>
>
> James Mitchell wrote:
>
> >>(James) Get that Linux box up?! :-)
> >>
> >LOL......no I started consolidating my Laptop HD and noticed
> that I didn't
> >have enough room on my file server to backup what I had. So I'll have to
> >either get another 80 Gig or take the time to go through and
> delete all that
> >Free Software I seem to keep collecting.
> >
> >Hey, I wonder what 'format c:\' does. Oh SHI#!!!!!!! STOP STOP STO
> >
> Ever heard of CD-R/CD-RW? They really are quite handy :-) ... and
> CD-R/Ws (disks and writers too) are really quite cheap!
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts & Persistence
Posted by Eddie Bush <ek...@swbell.net>.
James Mitchell wrote:
>>(James) Get that Linux box up?! :-)
>>
>LOL......no I started consolidating my Laptop HD and noticed that I didn't
>have enough room on my file server to backup what I had. So I'll have to
>either get another 80 Gig or take the time to go through and delete all that
>Free Software I seem to keep collecting.
>
>Hey, I wonder what 'format c:\' does. Oh SHI#!!!!!!! STOP STOP STO
>
Ever heard of CD-R/CD-RW? They really are quite handy :-) ... and
CD-R/Ws (disks and writers too) are really quite cheap!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts & Persistence
Posted by James Mitchell <jm...@telocity.com>.
> -----Original Message-----
> From: Eddie Bush [mailto:ekbush@swbell.net]
>
> (David) It should be noted that the ODMG is an immediate precursor to
> JDO, and, therefore, quite similar. If you search the OJB archives
> you'll find suggestions on how to plan a transition to JDO, once that
> functionality is production-ready. Look for threads by Thomas Mahler -
> I think he's OJB's "daddy".
Yes, he is the Mommy and the Daddy, and Uncle and Aunt....but not Grandpa.
No that title goes to
>
> (James) Get that Linux box up?! :-)
>
LOL......no I started consolidating my Laptop HD and noticed that I didn't
have enough room on my file server to backup what I had. So I'll have to
either get another 80 Gig or take the time to go through and delete all that
Free Software I seem to keep collecting.
Hey, I wonder what 'format c:\' does. Oh SHI#!!!!!!! STOP STOP STO
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts & Persistence
Posted by Eddie Bush <ek...@swbell.net>.
(David) It should be noted that the ODMG is an immediate precursor to
JDO, and, therefore, quite similar. If you search the OJB archives
you'll find suggestions on how to plan a transition to JDO, once that
functionality is production-ready. Look for threads by Thomas Mahler -
I think he's OJB's "daddy".
(James) Get that Linux box up?! :-)
James Mitchell wrote:
>Actually, yes I am.
>
>Although, now that I'm a little more familiar with OJB, I must admit that I
>won't be using the JDO implementation, its not complete. I'm going with
>ODMG.
>
>If I don't get slammed today at work, I should be finished.
>
>>-----Original Message-----
>>From: David Mulligan [mailto:david.mulligan@LECAN.ie]
>>
>>Hey James,
>>
>>I'm just wondering if you have made any progress on your struts-example
>>using OJB?
>>
>>Tnx,
>>Dave.
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts & Persistence
Posted by James Mitchell <jm...@telocity.com>.
Actually, yes I am.
Although, now that I'm a little more familiar with OJB, I must admit that I
won't be using the JDO implementation, its not complete. I'm going with
ODMG.
If I don't get slammed today at work, I should be finished.
James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta
> -----Original Message-----
> From: David Mulligan [mailto:david.mulligan@LECAN.ie]
> Sent: Friday, August 09, 2002 5:46 AM
> To: 'Struts Users Mailing List'
> Subject: RE: Struts & Persistence
>
>
> Hey James,
>
> I'm just wondering if you have made any progress on your struts-example
> using OJB?
>
> Tnx,
> Dave.
>
> -----Original Message-----
> From: James Mitchell [mailto:jmitchtx@telocity.com]
> Sent: Tuesday, July 23, 2002 7:22 PM
> To: Struts Users Mailing List
> Subject: RE: Struts & Persistence
>
>
> I'll be uploading a modified version of the example app
> (struts-example.war)
> which uses OJB as soon as I can finish it.
>
> Basic O/R mapping using JDO API w/MySql on the backend.
>
> It's not there yet, but here's the url:
> http://sourceforge.net/projects/struts/
>
>
> James Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://www.open-tools.org/struts-atlanta
>
>
>
>
> > -----Original Message-----
> > From: Elderclei R Reami [mailto:reami@vertisnet.com.br]
> > Sent: Tuesday, July 23, 2002 2:54 PM
> > To: struts-user@jakarta.apache.org
> > Subject: Struts & Persistence
> >
> >
> > Hi again,
> >
> > Does anyone know about usage of persistence frameworks, like
> Torque & OJB
> > from Apache Group, with Struts?
> >
> > Thanks for all the help with code generation. I downloaded StrutsBuilder
> > and Eclipse+EasyStruts to evaluate and they are great tools. About self-
> > generated apps from database schema and beer... Huhr! Sounds nice and we
> > can start a new project from the idea :)
> >
> > Best Regards,
> > Elder
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>