Hi Bob, Thanks for the perspective. I had thought it could be done by wiring a number of components together, as you indicate.
However, in this case, what components are displayed and/or how they are wired will need to change based upon the Class selected. Essentially, the components need to become aware of what Class is being manipulated in order to set their parameters correctly. The TBC-defined Form enables us to tie specific display properties to a Class. Consider my original Application example where an Application has DataElements and DataElements have subElements which are DataElements, forming a hierarchy of DataElements that root at an Application. subElement is the transitive property. Using the TBE DefaultApp as a frame of reference, the Application class will appear in the "Select Class To Begin" tree. Once selected, all Applications will appear in the Result Grid. If an instance is selected, the form for Application will be displayed in the Form tab. Currently, this will only show the top level DataElements connnected directly to the application. I could create another Tree component that would be connected to the Form such that the Form could pass along the Tree root and transitive property values. However, I do not know how to do this since the Form does not appear to know what class is being displayed and certainly cannot know what root node and transitive property should be passed to the downstream tree (this will change per Class). The "metadata" about which property is the correct transitive property and associated root node need to be defined at a Class level and currently there does not appear to be support for this. That's why I would like to be able to combine components into "super forms" to enable a more robust display of instance data. Any thoughts on how to control the wiring of a TBE app based on the Class the app is manipulating? I appreciate the dynamic nature of the components but I don't understand how to leverage that into a Class-specifc function. Thanks for your input, Tim On Fri, Dec 9, 2011 at 12:21 PM, Bob Ducharme <[email protected]>wrote: > Tim,**** > > ** ** > > A TBE tree will display any instances that are related by a common > property, which you enter in the Transitive Property field of the Tree > Attributes section of the TBE configuration dialog box. So, if DataElement > instances are related to each with rdfs:subClassOf or dcterms:isPartOf > properties, you would specify that property in the Transitive Property > field. (I know from your other email that you have worked with that field, > so I may be misunderstanding your question.) **** > > ** ** > > A TBE Component like a tree cannot be incorporated into another one, such > as a form, because each has its own set of events to configure, but because > components can react to each others’ events, you can set up dynamic > relationships. For example, when a form is showing a given Application, a > tree component might show the Data Elements associated with that > application if the tree’s Switch Root attribute was configured to listen > for a new Application instance being shown in that particular form. **** > > ** ** > > Bob**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Tim Smith > *Sent:* Thursday, December 08, 2011 11:03 PM > *To:* [email protected] > *Subject:* [topbraid-users] TBC/TBE Form Questions**** > > ** ** > > Hi, > > I'm wondering if this is possible. > > I'm creating an Enterprise Architecture ontology. > > I have a class, Application. An Application can have one or more > DataElements. DataElements are hierarchical such that DataElements can be > subElements of other DataElements. > > Here's what I want to be able to do: > > On the form for Application, I want to be able to display the DataElements > as a Tree, particularly in TBE. I cannot find a way to do this. > > Is it possible to group TBE components to make complex forms? Often times > the information that needs to be displayed for an instance requires more > complex GUI components such as trees or the information is more than one > hop away and thus magic properties must be created or SPARQL queries must > be used. > > I can do all of this using SWPs but SWPs are not editable so I'm stuck > using TBE since users need to edit/add/delete from the instance data. > > Thank you in advance for your input, > > Tim**** > > -- > You received this message because you are subscribed to the Google > Group "TopBraid Suite Users", the topics of which include TopBraid > Composer, > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. > To post to this group, send email to > [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/topbraid-users?hl=en**** > > -- > You received this message because you are subscribed to the Google > Group "TopBraid Suite Users", the topics of which include TopBraid > Composer, > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. > To post to this group, send email to > [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/topbraid-users?hl=en > -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
