No Just-migration-summary Examples?

84 views
Skip to first unread message

Kimball Johnson

unread,
Aug 5, 2016, 6:37:59 PM8/5/16
to mutation-summary-discuss
So I've read through everything I can find about the migration-summary.js library, following your specific links.And I found a lot that informed my understanding of your discussions in the attributes section of this link:

But I'm surprised that I cannot find a bunch of basic examples about how to set up migration summary in common script situations. Your github examples involve libraries that consume migration-summary, but the basic examples use migration observers?

For me, the problem with this is ambiguity: maybe this seems too boring, but those types of examples disambiguate many initial expectations that developers have about how something is supposed to be integrated into various basic html/javascript settings. This is especially important when working with the more mature commercial and semi-commercial frameworks that have a lot of eccentricities and 'helper scenarios' like MS MVC and Angular.

I did look through your source and your tests, but again, how to integrate into common scenarios is not in evidence, although the basic principles you have described in text and video do become emphasized in those perspectives.

The one aspect that did raise my curiosity was the ability to use jQuery objects in the place of the strict html attributes, which seem to be at the root of the design principles for mutation observers and your mutation summary library. How jQuery could navigate the clear structural issues that you have identified between properties and attributes is a little mystifying.

So here's my specific use case: MS ASPNET MVC4 application using html helper EditorFor/Displayfor templates. These 'html helpers' consume LINQ-based collections of sub-view-models that are typically constructed as members of a complex view-model whose design mirrors the layout of a complex web page or sub-component of a complex LOB web page. In the rendering phase, the view models are handed to the meaninglessly named 'razor views' who convert them into element, property, attribute, and value nodes (perhaps) within a primitive structure of static HTML. As the views process the members of the collections, they call sub-views to which they hand-off sub-collections of view-models stored in the sub-members of the tree of view-model collections. As a conceptual aid, recognize that LINQPad is perfect for dissecting these hierarchical view-model structures. And note that all these view-models are pre-loaded with specific, business-specific values, some of which are used for information, others for attribute modification, and others for business logic control.

So the problems with all this are manifold. But what I'm hoping to use MutationSummary for is to capture the differential between the DOM structure of the target HTML container (a Telerik modal window in this case) before and after the expansion of the DOM structures injected into the hierarchy of views in the page layout. I am optimistic that MutationSummary will be able to capture the elements and attributes as the well-designed HTML elements are created and injected into ul/li, table, and other recognizable controls. The current obstacle is that the razor views become opaque to browser developer tools and many jquery queries fail to be able to capture the DOM objects being created down-level, especially in the case of many down-level layers.

My optimism is based on demonstrations and commentary about the comprehensive DOM capturing capabilities. But still, how to get past the first few failed attempts to integrate MutationSummary in its canonical format into a javascript file at the right level in the structure will be dicy.

Therefore, if I could find a 20 line, authoritative example of how to design a 100-200 line instance of MutationSummary and structure it in such a way that it could capture and then react to all the created DOM nodes in such a dynamic operation would be extremely valuable. For me the biggest obstacle is how to place the basic pieces of the MigrationSummary implementation in the correct order so that I can design the attributes of elements that will be injected so that they are in a 'starting state', and then use the callbacks connected to those elements by MigrationSummary to make final adjustments to those attributes when the creation/injection phase has completed, prior to the user beginning their exploit. 

In this, my goal is to be able to detect the point of completion based on fore-knowledge of the final structure. In fact, the entire search that resulted in my consideration of MigrationSummary was initiated by the realization that jQuery could not recognize accurately when an element became visible without a trigger operation to fire the query to make the detection, leading to a wait-cycle standoff. In my case I only need to be able to detect the transition from the creation/injection of one group of elements to the next branch in the hierarchy. Putting flags attributes in the injected elements seems clumsy, but possible. But being able to determine that one of the mutation summaries is active and then inactive might be enough to provide a sufficient indication... but if its acting like mux??

Thanks for providing this interesting library.

Kimball Johnson

Kimball Johnson

unread,
Aug 5, 2016, 8:09:28 PM8/5/16
to mutation-summary-discuss
Sorry, I just found your tutorial page again. It provides the examples I was looking for. But I would appreciate any comments in any case. Thanks, Kimball Johnson
Reply all
Reply to author
Forward
0 new messages