watermark for custom plug-in rather than native QC elements

jean_pierre's picture

recently, i toiled in the editor attempting to put assemble what i felt was a pretty complex flow for data management and i wondered how others manage this kind of task (i hear a lot of JavaScript patches) and at what point a custom plugin is appropriate rather than using core QC elements like structs/queues/multiplexing/sample&hold.

in my particular case, i was trying to put together a somewhat complex slideshow that had dynamic data sources and some shuffling of display. for storage i was using structures with 'sample & hold' and to edit, i ended up writing a custom plugin for structure member insert, remove, update and structure shuffle as i wasn't super interested in constantly transforming the contents in JavaScript patches. several failed attempts later, i had a barebones version of the composition working but it became really quite cumbersome to make changes to. this might be more an expression of my QC naiveté than of QC's trouble in handling this kind of data but, i then decided to look into writing a custom plug-in to handle this. 20 minutes later i had a custom plug-in that managed all data storage and synchronization far better than my multi-layered / macro'd composition, but i am left wondering if there are tasks that just don't lend themselves to native QC elements and how people typically handle data management?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

dust's picture
Re: watermark for custom plug-in rather than native QC elements

For me it depends on how your using qc. Normally I do data management if running qc natively with a customplugin that writes XML plists and if using a comp in an application I use core data models which I suppose is sort of the same type of thing saving your data to SQL lite or XML data base.

I use plugins when there isn't a way to accomplish something natively in qc or when a native implementation is slow. I would say a custom plugin. Is faster than java script patches. Maybe not to implement but In performance so usually where performance matters. The other use for plugins is to facilitate the use of frame works not available to qc.

Normally I find things easier to noodle out in qc than to write in code. But yes there are things that are just better suited to be bundled up in a plug like data management.

jean_pierre's picture
Re: watermark for custom plug-in rather than native QC elements

thanks for the response dust, i felt as though i was taking the easy path by managing my data through a custom plug-in, but it sounds as though the native QC patches might not be well suited for this anyways -- the XML plist is a pretty clever way to easily and somewhat visibly manage that too.