[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.
OR
2) Use a library that is always open and it is booted into the back script with
start using on init.
OR
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.
BR
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…"
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
