nk4um

Thanks I read your post just now and though I didn''t follow everything I''m sure it will help me when I get the time to study it closer - which I really want to do I''m really interested in that example you gave above that does look simple and powerful as you say.  Are there docs covering this "DSL" as you put it?  i.e. that documents these tags like <widget>? 

I had done the tutorial you highlighted btw (the Architecture tutorial is the WiNK one right), and though I suspected this "plugging in a tab" feature made use of the DynamicImportHook capability (from the ROC Basics tutorial - like the transports are hooked in with right), I didn''t remember/catch what that Architecture/WiNK tutorial had further clarified?   Maybe I''ll go over it again maybe missed something...

But I think I vaguely followed the premise of what you said - you said there''s effectively an xml description "resource" for what tabs should appear, which presumably gets XSL''ed or something into the html for the tabs, and when a new module is added that has the right DynamicImportHook thingie included to say it should have a tab added, the system is smart enough to invalidate the resource chain that leads to the html for the entire tab bar, and it gets regenerated with the new tab included.

So I think broadly I get the idea it''s more the details I need to study closer, maybe especially the part you referred to as "aggregation" (I guess the pulling together of the disparate pieces that different modules have contributed to the composite resource that represents the overall tab bar?).  I guess maybe it''s also the DynamicImportHook stuff I don''t fully understand yet either...

I''ll get it though. :)

There''s no special "framework" since this pattern is really quite easy and  uses the regular palette of tools.  Fundamentally it relies upon the spacial dynamic import capabilities of NetKernel, which are explained with examples in the ROC Architecture tutorial

The essence of the pattern is that the tab bar is a composite resource built as follows: a resource aggregation request is made to dynamically discover every instance of a given resource identifier in all locally resolvable spaces (including any dynamic imports) (As I recall the NKSE admin structure uses the active:SpaceAggregateHDS endpoint from layer1).

When the resource list is discovered then we just SOURCE all the resources and combine into a composite resource and then apply the styling to generate the high order HTML tab bar.   The composite resource is cached but (as every other resource in NK) it has a dependency hierarchy.  It depends on all the individual resources *and* upon the space aggregation (which is also a resource - everything is!).  So as soon as a new module is commissioned that has a dynamic import, the composite tab bar becomes invalidate - next time it is requested the cycle repeats to build it again (and now a new tab in the new module will just pop into life).

FYI here''s the local tab descriptor resource that an individual module (space) publishes to show as res:/etc/system/ControlPanel.xml

<controlpanel xmlns:xrl="http://netkernel.org/xrl">   <panel>     <id>urn:org:ten60:apposite:client:panel:view</id>     <title>Apposite</title>     <subtitle>Apposite Package Management System</subtitle>     <icon>/tools/packager/pub/module.png</icon>     <order>10</order>   </panel>   <widget>     <request>       <identifier>res:/tools/apposite/widget/statistics</identifier>     </request>     <panel>urn:org:ten60:apposite:client:panel:view</panel>   </widget>   <icon>     <title>Apposite</title>     <subtitle>Software Management System</subtitle>     <path>/tools/apposite/</path>     <icon>/tools/packager/pub/module.png</icon>     <panel>urn:org:ten60:apposite:client:panel:view</panel>   </icon>   <icon>     <title>Packager </title>     <subtitle>Package modules for distribution</subtitle>     <path>/tools/packager/</path>     <icon>/tools/packager/pub/module.png</icon>     <panel>urn:org:ten60:apposite:client:panel:view</panel>   </icon>   <xrl:include>     <xrl:identifier>active:groovy</xrl:identifier>     <xrl:argumentname="operator">res:/panel/dynamicInstallPanel.gy</xrl:argument>   </xrl:include> </controlpanel>

You can see that it''s actually a DSL - a control panel descriptor language - that just leverages all the ROC infrastructure to be able to dynamically source other resources as well.   Here it includes some static icons, a widget (which is an XHTML fragment - that can include includes, and also an xrl include - since the top level aggregator runs through an XRL template recursion.

The end result is powerful, but if you think in terms of resources and resource composition, these patterns are really simple to achieve.

Are there any details/docs regarding how some of the modules installed from apposite "magically" cause a tab to appear on the 1060 admin pages?

Is that custom to the way the back end fulcrum stuff is coded or is there any kind of separate module just for that?

We work on some pretty complex web sites at work that in fact are organized with tabs for navigation not that different from the 1060 pages.  And in fact some of the tabs provide functionality that the business people have wanted to reuse on different sites, but we''ve struggled to reuse anything but the backend services.

I think the simplicity of installing a module and magically having the tab show up in the UI and actually function is really appealing...