Re: Testing if an EO would be deletable
Re: Testing if an EO would be deletable
- Subject: Re: Testing if an EO would be deletable
- From: Chuck Hill <email@hidden>
- Date: Tue, 19 Jan 2010 10:29:36 -0800
On Jan 19, 2010, at 3:27 AM, David Avendasora wrote:
On Jan 19, 2010, at 5:27 AM, Paul Hoadley wrote:
Hi Cheong Hee,
On 19/01/2010, at 8:49 PM, Cheong Hee (Gmail) wrote:
I relied much on own logic checking than EOF to decide if the
object is allowed to be deleted, apart from delete rule. One of
the reasons is sometimes the object itself also depends on its
attribute value other than delete rule. Is it not better to
depend on our own delete logic than EOF? Sooorry for being naive.
No need to apologise. You might be right for your particular
circumstance, but I really do have an EO where as far as the
business logic is concerned, deletability is fully specified by the
delete rules in the model. This won't be the case all the time, as
you point out, but it's the case here. I just wondered if calling
validateForDelete() and checking for the exception really was the
best way to answer the question "Will EOF let me delete this EO if
I try?"
I haven't thought this all the way through, but this sounds like the
perfect thing to put in the eogenerator template. Something along
the lines of (for a to-one relationship)
"myRelationshipIsCurrentlyDeleteable()" method. You could then
change the logic for this based on what the settings in the eomodel
are. For example, if the delete rule is "Deny" make the method
"return false".
uh, wouldn't that be return myRelationship() != null ? false : true
You should be able to make a generic method for this that does not
change with model changes, and instead looks at the current model
settings. But this won't handle the case where objects in the
relationship or objects they cascade delete refuse deletion.
For to-many relationships, this would be more difficult and I
certainly haven't thought that one all the way through yet. But I
think that creating these methods in the _Entity.java class is the
place, then if you have business rules that cannot be expressed in
the eomodel, then you can override the generated method with your
own logic.
Which is what you will need in complex cases.
This also brings up the question of at what point should it say it
can't be deleted? Upon setting the relationship to null, or upon
save? There may be situations where you want to set a relationship
to null temporarily, but then set it to a valid object prior to
save. This process satisfies the delete rule in the eomodel, but
will be impossible to determine prior to save. But then you could
have UI logic that says if (!myRelationshipCurrentlyDeleteable() &&
myRelationship == null) then display a flag in the UI that shows
that it is manditory.
Deny and Manadatory are not required together. You can have an
optional to-one that Denies deletion.
Again, just thinking out loud. Not sure if any of this will work in
the real WOrld. :-)
It can get complicated.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden