On 2011-08-30, at 5:03 PM, Q wrote:
>
> On 30/08/2011, at 3:44 PM, David Avendasora wrote:
>
>>
>> On Aug 29, 2011, at 11:43 PM, Markus Ruggiero wrote:
>>
>>> Thanks Ramsey,
>>>
>>> This is a completely standalone table with no relationships that contains
>>> one record with a couple attributes that define the configuration of the
>>> app. I was so deep into doing everything without programming that I missed
>>> the obvious. Your answer triggered the following solution: Having a simple
>>> page with a message and only a CANCEL button for the Create*
>>> pageConfiguration should solve my problem.
>>
>> Beware. That solution only prevents creating new instances of your class
>> when the creation is called using D2W, and then only for ways of creating it
>> that match your rule. Any other code can still very simply call:
>>
>> EOUtillities. createAndInsertInstance(editingContext, "MySingleton")
>>
>> and get a new instance.
>>
>> At a minimum, you should override all the easy ways to create a new instance
>> in the class to simply return the Singleton instead of actually creating a
>> new one.
>>
>> I think a better solution (off the top of my head, not tested, Chuck will
>> probably say it's all wrong, yadda, yadda) would be:
>
> Close, not Chuck. :)
>
>>
>> public class MySingletonEO {
>>
>> private static MySingletonEO singleton = null;
>>
>> public MySingletonEO() {
>> // Don't call super() so this will stop instantiation.
>> // Not sure what EOF will do, probably die horribly,
>> // but really, that's okay, right?!
>> }
>
> Bug #1: This doesn't work. The java compiler always inserts an implicit
> super() call, if no such constructor exists in the parent the class will not
> compile. The only thing you can do to prevent instantiation is to throw an
> exception in the constructor or make the constructor private.
>
>> public static MySingletonEO initialize(EOEditingContext editingContext) {
>> if(singleton == null) {
>> singleton = EOUtilities.faultWithPrimaryKeyValue(editingContext,
>>
>> MySingletonEO.ENTITY_NAME,
>>
>> Integer.valueOf(123456789)));
>> }
>> return singleton;
>> }
>> }
>
> Bug #2: This is a race condition. This method is not synchronised, so you
> could end up returning more than one "singleton" instance in a threaded
> environment.
> Bug #3: If this method is called more than once the returned EO may not have
> been inserted into the provided editing context creating the potential for
> changes to be lost if saveChanges is called on the wrong ec.
Yeah, a singleton EO makes no sense as you need a separate instance in each EC
(unless you want to use the Shared EC).
public static MySpecialEO instance(EOEditingContext editingContext) {
return EOUtilities.faultWithPrimaryKeyValue(editingContext,
MySingletonEO.ENTITY_NAME,
Integer.valueOf(123456789)));
}
Is probably closer to what you want.
Chuck
>
>>> Thanks Ramsey, it is not the first time that your input has helped me
>>> further.💐
>>
>> Funny, now you'll probably be saying "Thanks Dave, it's not the first time
>> your input has completely screwed me over."
>>
>> Dave
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>
> This email sent to [email protected]
--
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
