Referencable components are things that will be used by:
Clonable components are things that will be used by:
Metaphorically speaking, if the app was mosaic art, clonable components would be the grout while the referencable components would be mosaic or parts of the mosaic that gets woven together using clonable components.
There is a good reason for this distinction. Clonable components usually embed user and business flows and processes that need visual cutomizations and change very often. This fact makes them a poor choice for reusability. On the other hand referencable components typically
navItems
and slides
by:frame/minimal
)
* calling frame_setnav
on the part
* defining 'frame_notify' event
* pickingdoChain
or the implicit chain
from the notify to communicate between their own slides and peer slides/
* The uri changes that match only the navItems for the splitter will only trigger refresh.
frame_nav
event occurs.visible
user state change, a new slide should be defined.slidenotify
) to refresh different subparts based on the event. Generally speaking, the parts and elements in the slide should not carry a reference to the slide as an initval. Instead the communications should be either through standard 'framexxx' or custom defined slide_xx defined by doTransition method.slide_notify
which will then based on the notification will refresh the correct components.slide
xx defined by doTransition method.frame_xxx
transitions will get routed to the frame.frame_notify
transitions and bubble that app the sourcepart
level via 'push'push.sourcepart.extpart
:onnotify: [
function(push) {modtask.action = push.sourcepart.extpart.keys.action || {};
....Instead of 'frame_xxx' just do
tap: function(push) { push(push.sourcepart.extpart.seqs.internalSeqs); }
flow
by defining navItems:
[
{ path: 'view', views: { body: 'viewmod' } },
{ path: 'edit', views: { body: 'editmod' } }]
What this is doing:
slide
moduleslide
can be maintained independent of others using the IDE.context agnostic
and dont care where in the visual hierarchy they might be. So inside
each slide we can to frame_navigate
and reference the sibling slides.state
object; state management is done by landing on the view. This simplifies creating and maintaining slides
.Contrast this with:
[
{ path: 'wizardstep/*',views: { body: 'wizardmod' }
pattern: {// will come out as itemid property in ['framegetkey', '_matches', modtask]
matches: ['step']}
}]
This approach will also give us the parsing of state from the uri to the matches.step variable. But now consider that inside the wizardmod we need to ext
load a module based on the step key (to allow for implementation of each step into a seperate file so that it can be worked on seperately using the IDE) which would make the wizardmodule redundant.
So in the case above mapping the states along navPaths in advantagous to mapping using matches.
matches are useful when:
Consider the collection/view/list
component. There is a design choice between implementing it as a frame which can then handle seletion info as a matches parameter.
[{
'path': 'collection/.*',pattern: {
// will come out as itemid property in ['framegetkey', '_matches', modtask]matches: ['selectioncsv']
},views: {
body: 'item'}
}] And the list of objects to be displayed can be passed in by framesetkey. Notice that this will mean that all the framexx interactions by the item will be trapped inside the collection frame andframenotify
will need to be used by the item. In other words, one flaw of this approach is that the item will need to be aware of the collection frame and we need extra logic at the collection frame level to intercept and pass framenotify call to the layer above.
The other problem that this will present is that defining side by side collections could become tricky as they splitter
will by design will force a state change on one to affect the other.
Now if we just implemented the collection/view/list
component as a regular component that accepted the selection and objects as initval params, we wont have the problem mentioned above.
Also notice that the first approach 'insulates' selection changes from affecting the layer above it because we are saying that the selection changes are restricted to the collection components. But if capture the selection state in the layer above, a change in selection will trigger a full redraw on the layer above which may not be desirable.
To solve the insulation
problem, we can always create a new path using the frame/minimal
component to capture the state at that level.