Re: If I've made a class for an EO entity, can I use it to add data to?
Re: If I've made a class for an EO entity, can I use it to add data to?
- Subject: Re: If I've made a class for an EO entity, can I use it to add data to?
- From: Chuck Hill <email@hidden>
- Date: Tue, 20 Jul 2004 09:46:30 -0700
The only thing I will add is to be sure to lock any editing contexts
other than the session.defaultEditingContext. You can find the class
MultiECLockManager on www.wocode.com that will handle this locking for
you in a low effort way.
Chuck
On Jul 20, 2004, at 9:15 AM, Jean-Frangois Veillette wrote:
I suggest ...
every 'edit' page (with an existing record or a new one like in this
case) do it's edition in a peer editingcontext, not in the default
one, that way, you can add, remove, and still make sure that you save
those editions only if the user press save on that exact page.
This will work because your list and edit pages wont share the same
editingcontext, but committed changes will still be visibles to the
list ones.
I use session.defaulteditingcontext for the list one, and single
action modification. for example, if in a list, I click delete and if
the delete should be committed right away, I can use that same
editingcontext. for any page that does real editing before commiting,
I create a peer eoeditingcontext. so if the user click cancel, back,
or somehow submit the form without being a save(), in this strategy
you're ok.
Make the interface (api) of those page, as transparent as possible.
something like
class EditPage extends WOComponent {
Member member;
EOEditingContext peerEc;
public EditPage(WOContext ctx) {
super(ctx);
peerEc = new EOEditingContext();
}
public void setMember(Member m) {
if(m.editingContext() == null) {
peerEc.insertObject(m);
member = m;
}
else {
member = (Member)EOUtilities.localInstanceOfObject(peerEc, m);
}
}
public void save() {
peerEc.saveChanges();
}
}
when you edit an object,
p = pageWithName("EditPage");
p.setMember(mItem);
and when you create a new one :
p.setMember(new Member());
hope this help,
- jfv
Le 04-07-20, ` 11:43, Bill Reynolds a icrit :
Amorya,
It's better to create an instance of the Object 'Members', modify all
it's
properties during your interaction with the user, and if they do
'submit'
then use a method to insert this new record in it's entirety. In
other
words do the dbase insertion very last. Of course you'll have to
contend
with making sure that each field(s) data type, length, non-Null, etc.
is all
enforced through your data gathering to assure a trouble-free insert,
but be
prepared if it's not. Either way you want to make sure you're
working with
the object and not just inserting potential orphaned and useless data
:)
-Bill
on 7/20/04 8:16, Amorya North at email@hidden wrote:
On 20 Jul 2004, at 1:57 pm, Amorya North wrote:
I'm implementing a registration page for users on my site.
I have an EO Entity called Members. This maps onto a Java class
called
Members (class generated by EOModeller).
What I want to do is add data directly to a new Members object...
OK, I've sort of managed it...
I added this to the code that runs when the Register page is opened:
public Register(WOContext context) {
super(context);
creatingMember = (Members) EOUtilities.createAndInsertInstance(ec,
"Members");
}
I still reckon that's bad practise though... What if a user goes to
the
page, but doesn't click submit? There'd be a random record hanging
around. Or what happens if they go to it multiple times, then
eventually submit - they'd add more than one record!
Any tips?
Amorya
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.