Dictionary vs. Glossary

Hi Tom,

your filter "where name contains''" will always return everything (this is a little metaphysical, but everything contains a little nothingness). You probably just need to tweak that filter. It sounds like you're using the (EMR) text in the name to distinguish the project that this applies to - did I get that right? If so, you may just want to create a custom field for the dictionary item called Project and specify it there. Then just change your filter to look for "project = 'EMR'". If I didn't interpret your question properly, run it past me again and give me another bite at the apple.

Regarding the parameter definition - if you want to include punctuation in the default value, enclose it in quotes

$param $$project = "(EMR)"

Ron,

I will try the "s for the parameter (that was one option I hadn't tried yet).  I'd kind of like to stay away from custom fields for this one, but I may resort to that, if nothing else seems to be working.

As far as the "metaphysics" go, I think i get it, but I still have a question as to why a glossary item is an entry with no fields, a dictionary item is an entry which has fields, but a dictionary listing with a specific qualifier will list ALL glossary and dictionary terms.  Is that understandable (i.e, do you get what i mean)?

I was hoping I could do "data terms" (dictionary items) with no "project' qualifier by indicating that the qualifier (the "project" parameter) was blank (or non-existent.

Anyway, thanks for the suggestion!

Tom

Quotes don't seem to work.

$param $$project "(EMR)"

still gives "project" "EMR" in the parameters dialog box.

Tom

try

$param $$project = "(EMR)"

(use the equals sign between the variable name and the value.

With respect to your previous post: you clarified what I was missing in your first post - that when the repeat includes a filter it's grabbing ALL, not just items with fields. I suspect that is what we in the biz call a bug :(

I'll check it out.

No joy!

$param $$project = "(EMR)" still displays "EMR" for the parameter value.

Bizarre!  I can enter (EMR) in the parameter dialog box, and it works exactly the way I want it to.  It just does not seem to translate from the $param syntax, no matter what I do.

The "dictionary" vs. "glossary" thing is a newly discovered hidden "feature".  We development types don't like the "B" word! LOL

Tom

Just took a look in the code and verified that Dictionary will always include everything; Glossary will include only elements sans fields. Bug? Feature?

At any rate you can use the new $when syntax to make the distinction for you. for example, to list only those dictionary elements with fields, you could do something like:

$repeatDictionary
$whenFields
Dictionary item $Name
$endwhenFields
$endrepeatDictionary

Why the parameter is not working for you is puzzling me. Here's my $info section (that's working great)

$info
$description "this will list only dictionary elements with fields"
$param $$project = "(EMR)"
$endinfo

Can you email me your template? I'm curious why I'm seeing different behavior than you are.

Ron,

Should I just send it to support@serlio.com?

The dictionary seems to be working as you describe.  I'm not sure why I thought it "automagically" determined whether there were fields or not and excluded the entries which did not have fields defined.  That's fine.

On the other hand, the parameter is still behaving strangely.  It will accept parentheses both in the "info" block and in the parameter dialog box, but, if parentheses are defined in the info block, they are ignored, both in the dialog box and in the parameter value assignment.

As you know, I am a bit "at odds" with the way field constraints are displayed in the dictionary, and I just noticed something else which is a cause for concern.  It seems that the specific constraints are not necessarily displayed in the same order for different fields.  In one case, the display order is # values allowed followed by required; in another case, the order was maximum size, required, # values allowed.

Is there any work being done (anticipated for an upcoming release) to extend the capability for displaying field constraints (e.g., making each constraint a "mappable" element in the document)?

Thanks!

Tom

Hi Tom -

Sure, the support email will get that to me.

Regarding the constraints - you're right - those are just displayed in storage order. There's no implied sorting or ordering. Can you expand on what you mean by making the constraint a "mappable" element?

I'd like to be able to create a table which would have a column for each individual constraint (or whichever of them I choose/need), kind of like values for custom fields.

Name/Type/Description/Required/Size/Count/Range/Pattern/Constraints

Seems like it's a matter of storing the elements (constraints) individually, rather than as a single block of data.

That would be a huge plus for me.

Tom