nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Event Registry for dynamically placed callouts?

System

Hey guys, got a bit of a tough one (though I could just be missing something obvious).

I have need to provide my own internal linking interface which uses the sitemap rather than physical .page files. I've created the necessary JSP/Servlet and integrated it with tinyMCE (hair pulling notwithstanding).

My problem is in using this browser outside of tinyMCE. I know how to open the dialog and retrieve the information. However, once I've got the path, I need to set the value on the related text item.

I've implemented a snippet system using inline, and I must be able to use the callout (or dialog type="button") in any DCT. Both of these systems clash with the limited getItem() 'XPath' system when it comes to referencing the text item.

If I use a callout, I have to register the onCallout event for each item, though there could be many, and they could be in different places.

If I use a dialog, and put it in the same container as the related text item, I could use relative pathing, but the dialog instance doesn't allow you to pass a reference to the calling item to the javascript function, so I'm stuck there.

Has anyone ever overcome a similar issue?

Find more posts tagged with

Comments

ISCBorisB

Perhaps I misunderstood, but still...

You can certainly use a callout to create single stand-alone button per Container or per DCT for that matter. Like this:[php]

[/php]You'd have to register an event once per button and you can pass whatever parameters you want in Handler's window.open URL.
May that help?

Migrateduser

Yeah, my first post was a bit... ambiguous. Basically, I've got a snippet system, so that the same FormPub code can be used by any DCT. Since this means the path to the callout could be pretty much anything, I'm having trouble registering the event:

DCT 1:

IWEventRegistry.addItemHandler("/root/path/item", "onCallout", function)

DCT 2:

IWEventRegistry.addItemHandler("/otherRoot/foo/item", "onCallout", function)

To make matters worse, we have what we call "Assembled" pages. These DCTs give the user a combination="or" for all our snippets, such that my browse snippet could be a replicant anywhere within the DCT.

---------
If I use dialog type="button", and wrap it in a container with the text item for the path, I might be able to use relative pathing: getItem(../text), but then I have this problem:

< dialog type="button" label="browse" function="myFunction" >

I'm not allowed to pass a reference to my button to "myFunction", which removes the ability to use relative pathing.

I hope that's clearer, and I really appreciate any help!

~Eric

ISCBorisB

Yeah, my first post was a bit... ambiguous. Basically, I've got a snippet system, so that the same FormPub code can be used by any DCT. Since this means the path to the callout could be pretty much anything, I'm having trouble registering the event:

DCT 1:

IWEventRegistry.addItemHandler("/root/path/item", "onCallout", function)

DCT 2:

IWEventRegistry.addItemHandler("/otherRoot/foo/item", "onCallout", function)

To make matters worse, we have what we call "Assembled" pages. These DCTs give the user a combination="or" for all our snippets, such that my browse snippet could be a replicant anywhere within the DCT.

---------
If I use dialog type="button", and wrap it in a container with the text item for the path, I might be able to use relative pathing: getItem(../text), but then I have this problem:

< dialog type="button" label="browse" function="myFunction" >

I'm not allowed to pass a reference to my button to "myFunction", which removes the ability to use relative pathing.

I hope that's clearer, and I really appreciate any help!

~Eric

Hmmm...

First of all, no - I do not think that you've missed anything trivial.
Secondly, if I were you I would've tried to use a callout, Dialog is too much of a black box.

Finally, assuming that within "Assembled" DCT you may have randomly scattered, identifiable (by naming convention?),
callout items you can perhaps do something like the following in the init Function:

1. Get root Item using IWDatacapture.getItem (hopefully you do not have too many possible "root-container"
names and can try them one by one, checking the result.
2. Recursively scan children (IWItem.getChildren), starting with root.
3. Identify callbacks and register them, your routine will have current XPath.

Not saying that's trivial but it *seems* doable if you want to invest some time.
Just my 2 cents...

Adam Stoller

In the category of "adding my $0.02" - the fact that your DCTs have different [root] structures is a symptom of short-sighted design. It's always best to be as consistent as possible to avoid lots of problems like this.

That being said, I think Boris provided most of what you need to achieve this - now it's just SMOP (small matter of programming).

Migrateduser

You know, I wish I had magically known that there was a response when I was banging my head against the keyboard last night. That will teach me to stop refreshing.

Anyways, this is the approach I'm going to go with (crawling the full form and finding the callouts). Feels too... "procedural"? to me, but it is what it is.

I am curious about what you said about differing paths being myopic as a design paradigm.

I've got my DCTs separated into data types ("article", "promotion", etc), and each has a unique root-container. This was done because one of the shared "snippets" between all low-level DCRs is a summary. I have some pages which consist merely of summaries of other DCRs. Since each different data type could require different presentation logic, the decision was made to give them unique root-containers.

In other words:


< overview> <-- the root of the "overview" data type
  < intro/>
  < summaries>
    < article>
      ...
      < summary>
      ...
    < /article>
    < promotion>
      ...
      < summary>
      ...
    < /promotion>
  < /summaries>
< /overview>

I'm not sure if I've veered wildly off the standard build path (wouldn't surprise me given how inconceivably unstandardized our static web estate was), but I couldn't really see the downside of this approach.

Until now, of course...

Fantastic help, much appreciated.
~Eric

Adam Stoller

You know, I wish I had magically known that there was a response when I was banging my head against the keyboard last night. That will teach me to stop refreshing.

It's called Subscribing to a thread with "Instant Email Notification" - either when you post (there's a drop-down select list below where you type in your post) or via the Thread menu (upper-right when viewing a thread) - simpler that constantly refreshing hoping that someone responded.

[...]
I am curious about what you said about differing paths being myopic as a design paradigm.

I've got my DCTs separated into data types ("article", "promotion", etc), and each has a unique root-container. This was done because one of the shared "snippets" between all low-level DCRs is a summary. I have some pages which consist merely of summaries of other DCRs. Since each different data type could require different presentation logic, the decision was made to give them unique root-containers.[...]

I now understand the rationale, though I think you could have achieved the same thing (albeit with slightly different processing code) by either adding an attribute to the root-container or adding a hidden-field with the value within the root-container...

Migrateduser

ghoti, I honestly wish we'd gone that way, since it would mean a trivial code change with a lot of upside.

Live and learn, I suppose. Maybe I can sneak in a migration to that setup after our first delivery.

Thanks for the in-depth responses, much appreciated.