Re: Prevent NEW in D2W?
Re: Prevent NEW in D2W?
- Subject: Re: Prevent NEW in D2W?
- From: Chuck Hill <email@hidden>
- Date: Tue, 30 Aug 2011 10:52:10 -0700
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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>>
>
> _______________________________________________
> 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
--
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