On 2011-08-29, at 10: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:
>
> 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?!
You would need to throw. The JVM will call super() or force you to. I forget.
And how will you create the singleton?
Better would be to override awakeFromInsertion and throw there.
Chuck
> }
>
> public static MySingletonEO initialize(EOEditingContext editingContext) {
> if(singleton == null) {
> singleton = EOUtilities.faultWithPrimaryKeyValue(editingContext,
>
> MySingletonEO.ENTITY_NAME,
>
> Integer.valueOf(123456789)));
> }
> return singleton;
> }
> }
>
> Which should completely prevent it ever being created.
>
>> 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
>
>
>> ---markus---
>>
>> On 29.08.2011, at 17:18, Ramsey Gurley wrote:
>>
>>>
>>> On Aug 29, 2011, at 6:32 AM, Markus Ruggiero wrote:
>>>
>>>> Quick D2W question:
>>>>
>>>> isEntityEditable, isEntityDeletable, isEntityInspectable are all fine, but
>>>> is there something like isEntityNewable?
>>>>
>>>> In other words: I have an entity with exactly one record that contains
>>>> some global parameters to my app. The user must be able to update that one
>>>> record but he must not be able to add a new record, there must be exactly
>>>> one record with the same primary key at all times. How would I do this?
>>>>
>>>> Thanks
>>>> ---markus---
>>>
>>> This sounds like a model problem, not a view or controller problem. If
>>> this is a one to one relationship, then model it that way.
>>>
>>> If the relationship is required, you can simply model it as a mandatory
>>> one-to-one joined on PKs and propagate the primary key. EOF will
>>> automatically create the related object for you when your eo is created.
>>>
>>> If it is an optional one-to-one, then model it as two to-one relationships
>>> with an FK on each table. Then in your entity class, override the
>>> inverseKeyForRelationship method to return the proper inverse relationship
>>> for each.
>>>
>>> If you have no control over the database schema and you need to do optional
>>> one-to-one with PKs then you're out of luck. From your description, it
>>> sounds like doing it in the app is the wrong way to do it. To do it the
>>> wrong way, you'll need to provide your page level actions using a branch
>>> delegate and something like ERDControllerButton instead of using isEntity*
>>> since there is no key like isEntityNewable. Either that, or you can build
>>> your own d2w page template and include an isEntityNewable conditional.
>>>
>>> Ramsey
>>
>> _______________________________________________
>> 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/webobjects%40avendasora.com
>>
>> This email sent to [email protected]
>>
>>
>
> _______________________________________________
> 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]
