limiting MKD entries

For questions and postings not covered by the other forums
ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

limiting MKD entries

Postby ConvertFromOldNGs » Fri Aug 07, 2009 12:45 pm

by bitsnz >> Wed, 22 Dec 2004 10:34:01 GMT

Hello All

How can i limit the type of object that is put into a Member Key Dictionary.

Example:
I have all the letters in the Alphabet that are created as objects and they reside in a MKD called MaxLettersByName.

I have another MDK called MinLettersByName of which i only want a select few (say consonants)

They are referenced by app.LetterMaster that has two collections called allMaxLettersByName and allMinLettersByName

When these Letters are created they are put into both MDK's but im wanted a condition or something similar so that only what i want will go into MinLettersByName (consonants)

Make sense?

Therefore if i look under LetterMaster (the class) and inspect instances then i inspect the collections i should see all the letters in allMaxLettersByName and only a few (say consonants) in the allMinLettersByName.

I'm sure there is a simple way of doing this. Maybe a method on the collection itself but what is it? I've tried reimplementing a method but i think i have ti wrong (or the wrong one)

Can anybody help?

Thanks People

p.s. The letter example above is just that; an example. It is not what im coding but it hopefully emphasises what im after.

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: limiting MKD entries

Postby ConvertFromOldNGs » Fri Aug 07, 2009 12:45 pm

by dcooper@jade.co.nz >> Wed, 22 Dec 2004 13:53:39 GMT

If you're using JADE 6, you can use a conditional relationship to implement this.

For a thorough discussion of conditions and using them as constraints in conditional relationships, have a look at this white paper on the web site:

www.jadeworld.com/downloads/jade6/conditions.pdf

I'm assuming you have a single Letter class, or perhaps a single Letter abstract class with a subclass per letter. In either case, add a condition to the Letter class (Methods menu, New Condition) called isConsonant. If you implemented an abstract Letter class with subclasses, I'd still add the condition to the top-level Letter class as conditions are not polymorphic.

A condition is like a restricted method that always returns a Boolean. A condition is marked in the browser window with a question mark icon. One of the main uses of conditions is to put constraints on inverse references, so they have a number of restrictions to guarantee that they always produce the same result without side effects. The only statements they can contain are 'if' and 'return' statements. They can contain constant definitions but no variable definitions. They can contain constant parameters (but not input, output or io parameters). They can only reference parameters, properties of self, or other conditions. They cannot reference any environmental objects (such as app or global) as these may not be available in all contexts in which a condition is evaluated (eg: database reorg). Methods may not be invoked from a condition except for a small number of RootSchema methods (eg: Date::month), deemed to be conditionSafe (look for this in the method signature), that are guaranteed to produce the same result in any context.

Having defined your isConsonant condition to do what you want, you need to have an inverse relationship to manage your letters (conditions can only be used to constrain inverse relationships). I'll assume your Letter class has a myLetterMaster reference and that you have two inverse collections to this (allMaxLettersByName and allMinLettersByName) on LetterMaster. Select the allMinLettersByName property (the one you want to constrain) and bring up the Define Reference dialog for it (ie: select to change the property). You'll see a Constraint combo box under the allMinLettersByName property. Your isConsonant condition will appear in the combo for you to use as a constraint. Select it and ok the dialog (you'll probably get told that you need a reorg).

The effect of this is that letters will be added to allMinLettersByName only when they satisfy the constraint (ie: when your isConsonant condition returns true for the member object).

Cheers,
Dean.

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: limiting MKD entries

Postby ConvertFromOldNGs » Fri Aug 07, 2009 12:45 pm

by bitsnz >> Wed, 22 Dec 2004 22:21:08 GMT

How can i ever thank you!

I expected a short detail that i might have to investigate but this reply adds icing upon icing to my request (and then some)

A big THANKYOU.

LONG LIVE JADE!!!!!

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: limiting MKD entries

Postby ConvertFromOldNGs » Fri Aug 07, 2009 12:45 pm

by Carl Ranson >> Mon, 4 Apr 2005 5:05:50 GMT

Can conditions also be used as keys in a member key dictionary.

I remember having a situation many moons ago where we wanted to use a virtual attribute as a key for a MKD and it wasn't allowed because Jade couldn't ensure the result was deterministic. It seems like conditions effectively make a condition deterministic (same output for same inputs regardless of the context)

Carl Ranson
Unify Ltd.


Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 37 guests