• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Read only attributes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Read only attributes


  • Subject: Re: Read only attributes
  • From: Chuck Hill <email@hidden>
  • Date: Tue, 9 Sep 2008 09:57:05 -0700


On Sep 9, 2008, at 7:09 AM, Florijan Stamenkovic wrote:

Chuck, Dave,

Thanks for the input...

On Sep 08, 2008, at 19:37, Chuck Hill wrote:

I am guessing that (if EOF indeed does not accept modifications of RO attributes) the purpose of this is to preserve existing data, and in situations in which data is created outside of EOF?

I think you can create new objects with these attributes assigned a value. You just can't change it afterwards.

If I read you correctly, then non-saved EOs can have their read only attributes set. Which brings me to the core of the problem: do I skip read only attributes when doing automatic EO generation or not? I do not want to mess with pks and fks, but I am already dealing with class properties only, so presumably they will not be in.

My feeling is that you should be setting them on entites that you create. These would probably be non-null and read only, so you might not have much choice.



Note that I am at the moment defining the general behavior. It will be possible to override it per attribute, but only in a more restrictive way: if the default behavior prohibits it, the att won't be generated, but if it allows it, an overriding setting can be provided to prevent any values being set.

At the moment I do:

	// some attributes need to be skipped
	if(att.isReadOnly() || att.isFlattened()) continue;

Maybe that should change to:

if(att.isDerived() || att.isFlattened() || isPK(att)) continue; // check for PKs just in case they are exposed

I think that would be better.


The situation that Dave describes would not be covered, but I guess one would not go about generating random values for an externally served, deployed db :)


One would hope not!  :-P

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
  • Follow-Ups:
    • Re: Read only attributes
      • From: Florijan Stamenkovic <email@hidden>
References: 
 >Read only attributes (From: Florijan Stamenkovic <email@hidden>)
 >Re: Read only attributes (From: Chuck Hill <email@hidden>)
 >Re: Read only attributes (From: Florijan Stamenkovic <email@hidden>)
 >Re: Read only attributes (From: Chuck Hill <email@hidden>)
 >Re: Read only attributes (From: Florijan Stamenkovic <email@hidden>)

  • Prev by Date: Re: Load Order for Frameworks in a Servlet Deployment
  • Next by Date: Re: Read only attributes
  • Previous by thread: Re: Read only attributes
  • Next by thread: Re: Read only attributes
  • Index(es):
    • Date
    • Thread