MetaCase Homepage
Forum Home Forum Home > > MetaEdit+
  New Posts New Posts RSS Feed - Label on connectable
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Label on connectable

 Post Reply Post Reply
Author
Message
edward22243 View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Apr.2019
Points: 26
Post Options Post Options   Thanks (0) Thanks(0)   Quote edward22243 Quote  Post ReplyReply Direct Link To This Post Topic: Label on connectable
    Posted: 18.Jun.2021 at 10:28
I have an object called Processor with a sub-graph (decomposition) attached to it.
The sub-graph is shown below. There are 4 little square cyan boxes, they are objects with type PropConnector.

Those PropConnectors are all connected to a Port in the green Skill-objects. Now I want to define the PropConnectors as dynamic ports in the (parent) Processor object.
I can do this in the Symbol Editor of the object Processor with a Template. 
When I define a generator as this I partly get what I want:

do decompositions {
  foreach .PropConnector {
    do ~From~To.(){
      :Name; 
    }
  }
}
You can see that the Name of the Skill is given below.



However I want the portname and Skillname to be given (as such)

do decompositions {
  foreach .PropConnector {
   do ~From~To#(){
    ' (prop ' :name; ')' 
   }
   do ~From~To.(){
    :Name; newline
   }
  }
}

But it seems this is not possible. How can I achieve this?
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 602
Post Options Post Options   Thanks (1) Thanks(1)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 18.Jun.2021 at 11:22
There are two parts to this:
  1. How to get the list of PropConnector subobjects for the Template in the parent Processor object
  2. How a PropConnector should display itself
For the first, you can choose the Subobject source to be Subgraph of type: <whatever is the type of the subgraph you showed> and Object type: PropConnector. You could also do the same thing with a generator, e.g. if you wanted to specify the order of ports as something other than alphabetical + creation order.



(Note that I'm following what you wrote, so the PropConnector rather than the Skill is the dynamic port.)

For the second part, you want a symbol for the PropConnector as a dynamic port. The PropConnector already has a blue square symbol for when it is used directly in a graph, but in the Template you can set it to use a library symbol when it is a subsymbol here: Subsymbol | Library symbol named by: Selection | ... | New. Give a name for the new library symbol and a Symbol Editor for it will open. Note that you have to OK the Template dialogs before Windows will allow you to click in the new Symbol Editor. 

Draw a Text element the same size as your dynamic port, and set it as a generator. We want to display what the PropConnector is connected to, e.g. the port name 'Src' and the Skill name 'SetStartLocation'. Our starting context was in the upper graph though, and after that on the stack we have the Processor object then the PropConnector. To get into the subgraph, we want to start from the Processor (one level higher on the stack than where we are) and go to its decomposition:

do decompositions;1 {

Now we want to navigate from the PropConnector, one level higher from where we are now:

   do ~From;1~To {

we only navigate into the To role, not the port. From the To role we can display the port's name and Skill object's name:

      do #() { '(prop ' :name; ') ' }
      do .Skill { :Name }


Edited by stevek - 18.Jun.2021 at 11:24
Back to Top
edward22243 View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Apr.2019
Points: 26
Post Options Post Options   Thanks (0) Thanks(0)   Quote edward22243 Quote  Post ReplyReply Direct Link To This Post Posted: 18.Jun.2021 at 13:40
Succes. Thank you. I actually experimented with the library-element but failed to go up one level on the stack so it did not lead to any result.  This works great,  thanks for the (quick) help.
Back to Top
edward22243 View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Apr.2019
Points: 26
Post Options Post Options   Thanks (0) Thanks(0)   Quote edward22243 Quote  Post ReplyReply Direct Link To This Post Posted: 18.Jun.2021 at 13:43
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 602
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 18.Jun.2021 at 14:06
Excellent!
Back to Top
edward22243 View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Apr.2019
Points: 26
Post Options Post Options   Thanks (0) Thanks(0)   Quote edward22243 Quote  Post ReplyReply Direct Link To This Post Posted: 19.Jun.2021 at 08:12
As you can see (in the very first pic) I use the PropConnector to connect to a Port that does not have anything else connected to it (the others are connected to object with text "Data Instance") .

Say I delete all four PropConnectors. Than I have 4 Ports that have nothing connected to it. Would it be possible to create ports in the Processor-object with the exact same result as before ?

So iso using PropConnectors, identify which ports of the Skill that are not connected? I wrote a generator that can identify which ports are not connected (not have a relationship), but it seems (but not sure) I need (in the generator in the format template) to supply a id and there is no unique id for these ports (only combi Skill + Port is unique).

The benefit of this is that I just can leave the ports unconnected, iso having to connect a PropConnector to all empty ports (really the only reason why I defined a PropConnector is to be able to generate ports in the Processor). It is a small benefit but usefull.
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 602
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 24.Jun.2021 at 14:18
The best approach in cases like these is to make the subgraph explicitly reveal the ports it offers to the parent object. Compare the subgraph to a function in a programming language: it has its contents, but also a name and list of parameters that it reveals as its signature. That has proven to be the most efficient, solid solution. 

At the moment, your PropConnector objects have no name of their own, but instead reveal the name of the port on an object in the subgraph (e.g. Src on SetStartLocation). If we follow the analogy of a function, the PropConnector should be able to set its own name, which allows better specification of the semantics of the port in the context of this graph. We could consider the signature to be (StartSrc, StartDest, TargetSrc, TargetDest). It's better that those are explicitly revealed and named — rather than just being "any port I haven't connected yet", revealing and creating a strong coupling with the internal details of the sub-object name (SetStartLocation), and a port within its subgraph (Src). 

Often, we want our languages to be scalable, allowing multiple levels of subgraphs. If we make the name displayed in an object's port to be the name of a object's port in a subgraph, then we have to ask where that lower port got its name. Presumably from a subgraph; obviously that chain has to end somewhere, with the lowest subgraph no longer connecting its port to another object with ports, but instead to an atomic object. That object will be a literal value like '3' or a local variable - and neither of those are well-suited to be the name of a port several layers higher. It's cleaner and more scalable to put the name into the 'formal parameter' - your PortConnector, which is an example of what we often call 'interface objects'. 

This approach also lets you connect an interface object in the subgraph to several ports - the modeling equivalent of using a function parameter in more than one place in the function body. That's very common, and shows up another problem if the naming is taken from the subobjects' ports: if an interface object is connected to two ports with different names, which one wins?

Your example graph above probably doesn't have all these issues, and may never need to scale up and face them. Still, these are good general principles that we've found, and hopefully give you some useful points of view to think about. 
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 10.16
Copyright ©2001-2013 Web Wiz Ltd.

This page was generated in 0.063 seconds.