Parent of Target

Sannyasin Brahmanathaswami brahma at
Tue Aug 22 16:24:04 EDT 2017

[ignore previous post… hit send prematurely]

[@ Trevor if you have thoughts based on your experience with Levure… love to hear the ]

Disclaimer: this my first time ever doing something with such a huge, modular architect, all previous experience to data has been in 1 Stack with Many Cards = 1 App

This new frame work is

Many text only libs/models/behaviors
Many binary stacks which are
    -- content rich with many cards
    -- act as pure "view" containers
   -- a "customControls" with one custom control per card which again serves as a mini "view" anywhere at any time.

Mark Wieder via use-livecode"  wrote:

    >># do different things based on calling context.

    That's exactly the opposite of what behaviors are for.

BR: ?? but a behavior may contain a script with a mouseup handler at that responds to different targets with different actions/results.

    >>      I'm not sure I follow the underlying reasoning here

    Thank you. That was my reaction as well.

    B- what problem are you trying to solve?

See earlier longer memo.
USE CASE aka "Problem to Solve"

is a frame work with multiple stacks/aka "modules" with content.

Search will be a global requirement.

I can identify, at least for now, three "classes" of content to be search in any given context/module

1) an array with the full data extract from our media metadata database.
     where one might want to search in the title, file name subtitle
2) a list (of song titles, or books, or chapters or whatever)  = highly likely to be refactored to DataGrid 2 in many contexts when that is rolled out.
3) a field with text, typically
    chapter of a book
    aggregated text form different sources into one field.

In all  these stacks/modules, the UI/UX will want to offer search.

so then, you are faced with

1) create code for each module in the behavior that runs that stack/card
    = you will be re-created the same scripts over and over again in dozens of places
    = be forced to add this every time a new module is added to the frame work.


2) Use a library that is always open and it is booted into the back script with start using on init.


3) create a behavior that is can be attached to a small group comprised of a searchstring field and a search button.

You say "used all over the place" breaks the mandate for use of behaviors… my actual experience says otherwise

When used in  a library, you don't get  "me" and "me" is very useful.

e.g. in our customControls stack we have a "socialShare" group
this is dynamically copied on demand to modules as needed.
There is a behavior attached to this group.
The local module/card has commands that insert the data to be share, in this context, to local var in behavior which is the card script, This card script has a function which returns that data

function getShareData
  return sShareData
end getShareData

Now the behavior for the group ( has buttons for FB, Twitter and Email and perhaps more once we get Global Connect into this mix)
just has to check the target, and getShareData()

I don't remember exactly why today, but as I was developing that, I was working harder, writing more code when I tried is as a lib. But as a behavior, some how it was both easier to write and easier to debug…

Anyway.. using a behavior as an "agent" to handle processes called from different context/stacks works pretty well .

All I have to do is attached it to the search Button and it will server everywhere. Very easy to find, just edit the behavior of the search but (oh yeah, that was another advantage over libs. if functions/handlers are very unique to a given context, then doing it as a behavior means you have super easy access via the Inspector for the very obvious controls that would use it: vs, scanning through and clicking on the script for the library in the Project Browser.

We had developed this framework (since about Feb of 2016) starting with libs, but over time behaviors are becoming more and more useful. Then I watched Trevor's Levure Video… and see that he's doing very much what we are, though I'm not sure where levure goes when we get to the "widget/custom-controls that will  be used in many stacks/across many context" use case, and believe me, you will be there in no time at all.


Who constantly faces "choice paralysis" because Livecode makes it too easy to do almost anything, any way you want, and without a lot of experience in module frameworks, its too easy to hack yourself into mess of spaghetti code: and having experienced this last year (a great deal of pain ove initial work done on the app) I'm constantly "over thinking what is the best way here…"

More information about the Use-livecode mailing list