Loading ...
Sorry, an error occurred while loading the content.

Re: More on custom properties...

Expand Messages
  • Marielle Lange
    ... You should try, Trevor. I got very found of this approach myself after hearing David hint me on the way getprop and setprop could be used this way and
    Message 1 of 107 , Mar 31, 2006
    • 0 Attachment
      >I never thought of
      > using the setprop/getprop just like a "handler" - I've always assumed that
      > it was 'attached' to the object that is getting its property set/retrieved.

      You should try, Trevor. I got very found of this approach myself after hearing David hint
      me on the way getprop and setprop could be used this way and reading on design
      patterns & OOP approaches & MVC. It encourages to write your code in terms of widgets...
      and the advantage of widgets is that you create components that you write once but use
      anywhere, by simple drag and drop in another stack.

      I am always a bit sad when I see on the lists proposals of this kind received with comments
      like "no use for reusable components or a OOP approach, I can write any code from
      scratch in less than 10 minutes". The reasons to become interested in re-usable
      components is not the economy of time or of lines of codes. It is the potential for a
      gradual increase in the quality of the functions and widgets available within the
      community, which has the potential to immensely benefit us all, skilled and unskilled
      users alike. I am sure that any of you can easily write a powerful application from scratch
      in only a few hours. A components-based approach provides you with a framework where
      you have some *other* choice than do it that way. Hence, a problem in the runrev
      community is that less skilled users are forced to follow the same approach as yours but
      without the benefits of your experience and level of skill. Though some stacks are
      available in open format here and there, some relatively advanced level of skill is still
      required to understand the code well enough to adapt it. With a components-model, you
      let others re-use components without having to understand the code. You can if you want
      (and I know Mark wants this ;-) ), but you don't *need* to. Total "control" comes with
      benefits, but also with costs. A component-based approach give you the ability to weight
      benefits and costs differently in different contexts of use.

      Sure, in the short term, this may means that open alternative of some of the plugins you
      sell may appear. However, in the longer term, this means that the size of the community
      will be expanding, as newcommers will find it easier to start using revolution. Professional
      developers will also benefit from the fact that it becomes increasingly easier and faster to
      assemble new applications, using widely tested components. Though there may be fear
      that the availability of quality components may negatively impact on your reputation, the
      fact is that the whole is always more than the sum of the parts. To get the whole right
      requires a talent and expertise that cannot be acquired in only a few months.

      Like you, David, I take a MVC approach for the coding of widgets.

      The view is kept separate from the model. This means that I can choose to display any file
      name the apple way, with ellipses when the file name is too long for a text field "/folder/
      fol.../file.txt". Alternatively, I can decide to display it the BBedit way, file.txt -- /folder/
      folder/ with a single change in property or parameter value The way I choose to display
      the file won't affect the inner working of the library.

      Because the view is also separated from the controller, I can very easily change my mind
      on whether the file value should be presented in textfield 1 rather than textfield 2, in a
      button, or should not appear at all.

      I suspect that I have something very similar to what you have done, David. How similar, I
      don't know. Last time we discussed of this, you said you wanted to keep your widgets for
      your private use and I wanted to construct a catalogue of widgets, mixing open and paying
      ones, made available to the community. Given our divergence of view, I have avoided
      looking at your code so far. I was afraid to inadvertendly re-use some of your solution. I
      have also done my best to go in directions that don't repeat the work you have already
      done (providing a model for embedding widgets within widges).

      For instance, you will note that an important difference with anything mentioned in this
      group is that I have chosen to explore the use the textfields to store library scripts.

      Because I use textfields to store library functions, I can rapidly provide a class and
      subclass model, with a card in my library stack containing mutltiple textfieds (card = class,
      textfield = subclass). I find using a textfield very efficient as it lets me organise my
      functions into very small chunks that can very flexibly be added to any stack.

      Because of this, I can more easily achieve encapsulation. Hence having a script stored in a
      object means I can store custom properties at the level of this textfield object rather than
      at the level of the card or stack, as is the usual approach. The custom property value can
      only be changed when referencing to the correct object.

      Because I use textfields, that is fairly small chunks of functions, I am encouraged to write
      my functions in such a way that the dependencies with functions in other textfields are
      absent or at worst limited and unambiguously declared.

      Because I use textfields, I can more easily run unit testing and make sure that all functions
      run properly without any call made to any function not declared as required.

      Because I store scripts in textfields objects rather than card or stack level, I can get over
      the complex prefixing conventions defined in this group. As I can easily get encapsulation
      when using custom properties of a group holding a widget, I can replace a syntax like that:

      > stsXML_GetRSSChannelProperty(<prop> [,<channel> [,<doc>]])
      > stsXML_SetRSSChannelProperty(<prop>,<newValue> [,<channel> [,<doc>]])

      With a syntax like this:
      get the RSSChannelProperty[params] of libpath["lib_xml"]

      Without creating any conflict. More info at:

      Obviously, an important problem with this approach is the fact that I still want to have
      some shared libraries to be in the back of the message path and I am limited to 10 objects
      in the front and back script, in a standalone or played stack. The only get around I have
      found so far is to add a "building" stage, which will run some operations that have for
      effect to merge all library scripts together within a card script. I expect this suggestion to
      be immensely impopular here. Ah, yeah, and other criticisms made by Trevor apply. Only
      one parameter for a getProp... But it is quite easy to send a string that contains all
      parameters or to set a custom prop to this sequence of paramaters. Anyway a cleaner
      approach is probably to set the properties of the function rather than call a function that
      requires very many parameters. No pass by reference. But if you use encapsulation, you
      don't need to pass by reference anymore. What you can then point to a custom property
      and update it from many places.

      It would be nice if we could find a way to make our work (David Bovil, David Burgun, Mark
      Wieder, etc.) compatible.

      If a workshop on this is planned at Monterey, then unfortunately it is about impossible for
      me to finance travel + conference costs to get there.

    • Jeanne A. E. DeVoto
      ... If you remove a group from any cards it is placed on using the remove command, the group still exists but is not placed on any cards. In this case it
      Message 107 of 107 , Apr 11, 2006
      • 0 Attachment
        At 10:45 AM +0000 4/8/2006, Marielle Lange wrote:
        >I wonder, how do you do that? Create what is defined as a control
        >but has no physical
        >counterpart on the interface?

        If you remove a group from any cards it is placed on using the
        "remove" command, the group still exists but is not placed on any
        cards. In this case it continues to be referencable, retains all its
        properties, may be placed on cards, etc., but it has no physical

        (Rev uses such groups to place prepackaged libraries in standalones,
        among other things.)
        jeanne a. e. devoto ~ revolution@...
      Your message has been successfully submitted and would be delivered to recipients shortly.