Parent of Target

[Trevor DeVore]

On Tue, Aug 22, 2017 at 3:24 PM, Sannyasin Brahmanathaswami via
use-livecode <use-livecode at lists.runrev.com> wrote:

>
> 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
>

Hi BR,

Let's see if I understand the problem sufficiently. Below you will find my
responses. If they seem way off then assume I didn't understand the
question :-)

You have multiple components that are involved with a basic search UI. At
the very least you need the following:

1. The UI element that the user types the search term into.
2. The code that processes the search term entered and fetches the search
results
3. The UI element that displays the search results.

Here is how I design such things.

The search UI element [1] is a custom control/widget in and of itself that
can be reused multiple times your application. Because it involves text
entry it will probably be a custom control and not just a widget. Make this
custom control completely self contained. It should not need to know
anything about what is going on outside of the custom control. The custom
control should dispatch a message when the user does something that should
trigger a search (e.g. types some number of characters or presses the
return key). You might use a name like "SearchOnTerm" for the message name.

The code that handles the "SearchOnTerm" message and searches using the
search term [2] can go in a couple of different places. The lowest place I
would but it (I think of messages as falling down) is the behavior script
attached to the card the search UI element appears on. If your search
widget is part of yet another custom control (let's call this SearchView)
that also includes the UI element that displays the search results [3] AND
you have a behavior attached to SearchView then I would handle
"SearchOnTerm" there.

The card or SearchView behaviors will do whatever needs to be done with the
search term. Maybe this card searches an array. Maybe it queries a SQL
database. Or maybe it makes a REST call. [1] and [2] don't need to know
about what is going on. [1] sends a message, the card or SearchView
behavior code processes and then displays it in [3]. Of course you can use
libraries to contain handlers that help with searching. Perhaps you have a
handler that parses a search phrase and breaks it up into a SQL query or
REST request. The card or SearchView behavior scripts would call any
library handlers as needed and then massage the search results into a
format that can be displayed in the search results UI element [3].

Using the above approach your UI elements are self contained and can be
reused. The behaviors attached to these UI elements should not use
complicated branching. Just dispatch messages and let the "controllers"
catch and process the messages.


> 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.
>

There is nothing special that you have to do with widgets as they are
single controls. If you ever update the widget code and recompile then the
widget is updated in your entire application. Levure doesn't ship with a
Helper (features are added to Levure using Helpers) that provides
templates. I have one Levure app that has a template concept in it and one
that doesn't. The general concept is that you use a card to layout a "view"
that will be used in your application. You can then insert this "view"
anywhere you want. Updating the "view" on the card will go through your app
and update all instances of the "view". This type of functionality isn't
directly connected to any particular framework, though a framework can make
it easier to work with templates and package up the resulting application.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.com