Re: More on custom properties...

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: More on custom properties...

Marielle Lange-3
>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:
   http://projects.widged.com/widgets/

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.

Marielle





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
Marielle-

Friday, March 31, 2006, 6:36:31 AM, you wrote:

> 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

Not strictly true at all. I have an xml-tree component where I pass it
data by "set the DisplayXMLData of field xyz to myData", where myData
is an entire xml tree. OK - technically that's a single pointer to a
piece of data, but even with complex xml data (embedded commas and
carriage returns and such) it still works fine. It's all in the
packaging.

--
-Mark Wieder
 [hidden email]





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
In reply to this post by Marielle Lange-3
Marielle-

Friday, March 31, 2006, 6:36:31 AM, you wrote:

"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 may have to steal this line and use it for marketing... <g>

--
-Mark Wieder
 [hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Trevor DeVore
In reply to this post by Marielle Lange-3
On Mar 31, 2006, at 6:36 AM, Marielle Lange wrote:

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

Umm, I do.  The text quoted above was from a post from Ken <http://
groups.yahoo.com/group/revInterop/message/298>.  I use virtual  
getProp/setProps in my code quite a bit.

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

Marielle, I can assure you that I am very much in favor of reusable  
code as I have lots of libraries that go from project to project.  
Some are general libraries, others only act on certain objects.  Just  
because I don't use the methods that Mark uses doesn't mean I'm  
against reusability.  I very much like looking at the work Mark is  
doing, I just don't use that approach in my applications.  It just  
means I have different tastes for how I like my code to work and  
where I want to put it.

Perhaps I don't feel that traditional OOP syntax is the best approach  
for reusability in Rev.

--
Trevor DeVore
Blue Mango Learning Systems - www.bluemangolearning.com
[hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Trevor DeVore
In reply to this post by mwieder
On Mar 31, 2006, at 10:17 AM, Mark Wieder wrote:

> Marielle-
>
> Friday, March 31, 2006, 6:36:31 AM, you wrote:
>
> > 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
>
> Not strictly true at all. I have an xml-tree component where I pass it
> data by "set the DisplayXMLData of field xyz to myData", where myData
> is an entire xml tree. OK - technically that's a single pointer to a
> piece of data, but even with complex xml data (embedded commas and
> carriage returns and such) it still works fine. It's all in the
> packaging.

Well Mark, technically you are only passing in one parameter :-)  You  
are passing one parameter that you have to parse.  If you go this  
route for data other than xml then you could also have an object  
(button) that you assign properties to and then pass the id of it  
like this:

set the uSomeCustPropThatNeedsLotsOfParams of me to the long id of  
button "theProps"


setProp uSomeCustPropThatNeedsLotsOfParams pObjRef
        put the uProps["Param1"] of pObjRef into theParam
        ...
end uSomeCustPropThatNeedsLotsOfParams

It just isn't as easy (or sometimes as readable) as passing in params  
directly.

--
Trevor DeVore
Blue Mango Learning Systems - www.bluemangolearning.com
[hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
In reply to this post by Trevor DeVore
Trevor-

Friday, March 31, 2006, 11:00:50 AM, you wrote:

> doing, I just don't use that approach in my applications.  It just
> means I have different tastes for how I like my code to work and  
> where I want to put it.

Yes, exactly the point. The reason we're having this discussion here
(well, the reason "*I'm* having it here) is to promote the
interoperability of the various components that people are and will be
designing. IMO rev is way behind the rest of the world of development
environments in (at least) the ability to add and exchange components.
In Real Basic or Delphi or whatever this is built in.

I'm less interested in the actual mechanism for message-passing than
in the ability for different components to play well together. And
since there are any number of given ways to implement things, there's
no reason why Trevore should have to adopt my way of doing things, or
I should have to adopt Marielle's, etc. I think what's important here
is that we work out a standard of component interoperability.

...and what's becoming increasingly clear to me is that this goes in
the opposite direction from identifying unique namespaces for
libraries, as per the ECMI. I'm more thinking that for component event
passing we want to promote namespace collisions to enable polymorphism
at the library level. In other words, rather than my having a library
function named "mdw_libEventStuff_RegisterEvent", what I really should
have is "RegisterEvent". That way library stacks are interchangeable
without change. And more importantly, it means that components someone
else develops can be pasted or drag-and-dropped into my stacks without
my having to fiddle with the code.

--
-Mark Wieder
 [hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Alain Farmer
In reply to this post by mwieder
Hello Mark Wieder, Marielle, and y'all

>> "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 may have to steal this line
> and use it for marketing... <g>

Marielle does indeed express herself coherently,
clearly, and persuasively. Her above sentence is
well-formed, but, more importantly, her *content*
speaks to us all. :-)

It's not just a "line", I might add. I am SURE that
she is being utterly-sincere. It is not a marketing
ploy. She's not 'selling' us anything. She is urging
us to work together ..[as a community] to create and
manage high-quality re-usable code|widgets|etc, as a
Commons that everyone shares, for the augmentation of
all.

IOW :

* Why re-invent the wheel ?

* Standing om the shoulders of giants.

It's the same insight that propelled, & still propels,
the Open Source movement as well as the academics that
were, and still are, intimately tied to the emergence
of the Web. Btw, these academics have now re-launched
a new Web 2.x, separate from the public mainstream
Web,  for the [academic] purposes they set out to
solve with the Web in the first place. XML & RDF
really kick-ass, in this regard, e.g. the Semantic
Web.

"Meanwhile back at the ranch", let's sum up this foray
by summarizing the 'players' that have benefitted from
the approach in question, e.g. open sharing to augment
the potential, the efficacy, the efficiency, the reuse
and the quality ... of their work|research|etc:

* Science
* Academia
* Libraries
* UNIX/GNU-Linux
* Open source
* etc

If we are here today, *with all of the technological
marvels that caracterize our times*, it is *because*
of this open sharing ("commons") that the became able
to SURPASS what any *private* person or organization
could ever hope to achieve alone. This open sharing,
or "communism" I suppose you could say, propelled us
(ALL of us) forward. Of course I am not arguing that
there weren't any pitfalls & so-on in this progress,
but, over-all, we are ALL a LOT better-off than our
ancestors were! (life-expectancy, meds, life-saving
surgeries, etc, etc, etc.). :-)

Marielle's point is that we should encourage the reuse
of code, [in the form of widgets]+, amongst ourselves,
e.g. Transcript users, in the spirit of benefitting us
all (in the manner described in this post). This is a
worthwhile goal, no doubt about it. But are we serious
enough to take the necessary steps to make it happen?
-- that is the question! Marielle & me, and others, we
answer YES! What is YOUR answer going to be? The more
we are, the *less* each stakeholder will need to do to
accomplish our collective goal. IOW a "multiplication"
factor. So what are **y'all** going to answer? :-))

Yes-fully yours,  ;-)

Alain

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Trevor DeVore
In reply to this post by mwieder
On Mar 31, 2006, at 11:16 AM, Mark Wieder wrote:

>
> ...and what's becoming increasingly clear to me is that this goes in
> the opposite direction from identifying unique namespaces for
> libraries, as per the ECMI. I'm more thinking that for component event
> passing we want to promote namespace collisions to enable polymorphism
> at the library level. In other words, rather than my having a library
> function named "mdw_libEventStuff_RegisterEvent", what I really should
> have is "RegisterEvent". That way library stacks are interchangeable
> without change. And more importantly, it means that components someone
> else develops can be pasted or drag-and-dropped into my stacks without
> my having to fiddle with the code.

I like the approach of common handlers shared among libs and using  
custom props to decide if the lib should act on object.  That way I  
could do this:

RegisterEvent the long id of button "MyButton", ...

on RegisterEvent pObj
        if the uLibrary of pObj is not "MarksAwesomeLib" then pass  
RegisterEvent

end RegisterEvent

But I am a custom prop kind of guy.  I think they solve most of the  
worlds problems ;-)
The one problem is what if RegisterEvent makes it to the engine and  
there is no lib to handle it?  The engine throws an error even though  
the message was passed along the message path.  That brings me back  
to my post to the improve list...

--
Trevor DeVore
Blue Mango Learning Systems - www.bluemangolearning.com
[hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
In reply to this post by Trevor DeVore
Trevor-

Yes, I realize that was kind of cheating... but yes, if you can
package the data correctly then you can get around the single
parameter hurdle.

--
-Mark Wieder
 [hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
In reply to this post by Alain Farmer
Alain-

Friday, March 31, 2006, 11:23:28 AM, you wrote:

> Marielle does indeed express herself coherently,
> clearly, and persuasively. Her above sentence is
> well-formed, but, more importantly, her *content*
> speaks to us all. :-)

Yes, I think you may have gotten the wrong idea from my post. I wasn't
trying to be flippant here. Marielle did indeed get right to the core
of what we're doing here.

--
-Mark Wieder
 [hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
In reply to this post by Trevor DeVore
Trevor-

Friday, March 31, 2006, 11:26:34 AM, you wrote:

> The one problem is what if RegisterEvent makes it to the engine and
> there is no lib to handle it?  The engine throws an error even though
> the message was passed along the message path.  That brings me back
> to my post to the improve list...

...and I forget whether or not there was a buy-in from rev on the
idea...

At any rate, my idea for the "RegisterEvent" or whatever handler is
that my event-dispatching library stack would have that. If I decided
to scrap my library stack and use yours then the "RegisterEvent"
handler in your library would be called instead. And if I took one of
your components and dropped it onto my stack it would use my
RegisterEvent handler instead of yours. That way there's no need to
see whose stack is in use and write specific object code to work with
one or another.

--
-Mark Wieder
 [hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Trevor DeVore
On Mar 31, 2006, at 11:45 AM, Mark Wieder wrote:

> Trevor-
>
> Friday, March 31, 2006, 11:26:34 AM, you wrote:
>
> > The one problem is what if RegisterEvent makes it to the engine and
> > there is no lib to handle it?  The engine throws an error even  
> though
> > the message was passed along the message path.  That brings me back
> > to my post to the improve list...
>
> ...and I forget whether or not there was a buy-in from rev on the
> idea...

Mark Waddingham didn't have an objection either way.  I imagine it  
isn't at the top of the priority list though since people get along  
fine the current behavior.  I still don't see how it could break any  
existing code so I may corner him at RevCon and throw Skittles (small  
bite-size candies) at him until he agrees to change it ;-)

> At any rate, my idea for the "RegisterEvent" or whatever handler is
> that my event-dispatching library stack would have that. If I decided
> to scrap my library stack and use yours then the "RegisterEvent"
> handler in your library would be called instead. And if I took one of
> your components and dropped it onto my stack it would use my
> RegisterEvent handler instead of yours. That way there's no need to
> see whose stack is in use and write specific object code to work with
> one or another.

OK, I understand what you mean now.


--
Trevor DeVore
Blue Mango Learning Systems - www.bluemangolearning.com
[hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
Trevor-

Friday, March 31, 2006, 11:54:38 AM, you wrote:

> Mark Waddingham didn't have an objection either way.  I imagine it
> isn't at the top of the priority list though since people get along
> fine the current behavior.  I still don't see how it could break any
> existing code so I may corner him at RevCon and throw Skittles (small
> bite-size candies) at him until he agrees to change it ;-)

ROTFL - I wonder if Dar's coming... anyway, I understand a reticence
to change engine behavior - it's not something that should be
undertaken lightly. I normally think of it the same way I think of
changes to the Constitution - it's a bad idea unless there's some
really overpowering need to make a change, there's no workaround, and
it fixes an egregious fault.

--
-Mark
 [hidden email]





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Ken Ray
In reply to this post by mwieder
On 3/31/06 1:16 PM, "Mark Wieder" <[hidden email]> wrote:

> ...and what's becoming increasingly clear to me is that this goes in
> the opposite direction from identifying unique namespaces for
> libraries, as per the ECMI. I'm more thinking that for component event
> passing we want to promote namespace collisions to enable polymorphism
> at the library level. In other words, rather than my having a library
> function named "mdw_libEventStuff_RegisterEvent", what I really should
> have is "RegisterEvent". That way library stacks are interchangeable
> without change. And more importantly, it means that components someone
> else develops can be pasted or drag-and-dropped into my stacks without
> my having to fiddle with the code.

But what it also means is that we need to agree on a common set of handlers
that do the expected thing; that is, I can no longer use "RegisterEvent" as
a handler for some personal thing (not that I was going to anyway, but you
get my drift); instead, we as a community agree that "RegisterEvent" is for
registering events that will be passed to an object.

Not that I have any problem with that, but I think the problem is that the
discussions have been talking "either-or" instead of "both". I see a place
for personal handlers that shouldn't kabosh other similar handlers by other
people (the "current" ECMI approach), along with a set of common handlers
that would do "known" things, regardless of whose library or component is
being used.

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [hidden email]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Ken Ray
In reply to this post by Trevor DeVore
On 3/31/06 1:26 PM, "Trevor DeVore" <[hidden email]> wrote:

> But I am a custom prop kind of guy.  I think they solve most of the
> worlds problems ;-)
> The one problem is what if RegisterEvent makes it to the engine and
> there is no lib to handle it?  The engine throws an error even though
> the message was passed along the message path.  That brings me back
> to my post to the improve list...

Agreed - it's a catch-22; you either use more typing to get the same effect:

  get (the RegisterEvent["mouseUp"] of stack "myStack")

vs.

  RegisterEvent "mouseUp"

and get the benefit that there are no thrown errors, or you make it a
handler with some common backscript or equivalent to "stub out" the calls
that aren't being handled.

Between the devil and the deep blue sea...

;-)

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [hidden email]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

mwieder
In reply to this post by Ken Ray
Ken-

Friday, March 31, 2006, 12:06:58 PM, you wrote:

> Not that I have any problem with that, but I think the problem is that the
> discussions have been talking "either-or" instead of "both". I see a place
> for personal handlers that shouldn't kabosh other similar handlers by other
> people (the "current" ECMI approach), along with a set of common handlers
> that would do "known" things, regardless of whose library or component is
> being used.

Yes - I didn't mean to say otherwise. What I'd like to see us work out
as a standard is a minimal set of handlers required for interoperable
components.

--
-Mark
 [hidden email]




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Ken Ray
In reply to this post by Marielle Lange-3
On 3/31/06 8:36 AM, "Marielle Lange" <[hidden email]> wrote:

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

Actually, Marielle, I said that... although it has its advantages, it jus
seems awkward to me to execute a command like "RegisterEvent" using a custom
property, but that's probably just me. :-)

> 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:
>    http://projects.widged.com/widgets/

When I went there, I got a bit confused... if you make the script of a field
available to all stacks via "insert script", then that is not very different
to using library stacks, since in both cases, there is the possibility of
clobbering a handler unless prefixing conventions are used. And if you don't
do that, you end up calling it like this:

put value("items2List(" & quote & pParams & quote & ")", field
"lib_asciitext" of card "data manipulation") into tLst

which seems a lot more cumbersome than a prefixed function in a library:

  put ABC_items2List(pParam1,pParam2) into tLst

Or am I missing something?

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [hidden email]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: Re: More on custom properties...

Richard Gaskin
In reply to this post by Alain Farmer
Alain Farmer wrote:

> Marielle's point is that we should encourage the reuse
> of code, [in the form of widgets]+, amongst ourselves,
> e.g. Transcript users, in the spirit of benefitting us
> all (in the manner described in this post). This is a
> worthwhile goal, no doubt about it. But are we serious
> enough to take the necessary steps to make it happen?
> -- that is the question! Marielle & me, and others, we
> answer YES! What is YOUR answer going to be? The more
> we are, the *less* each stakeholder will need to do to
> accomplish our collective goal. IOW a "multiplication"
> factor. So what are **y'all** going to answer? :-))

This is exactly the sort of thing the Rev Interoperability Project was
established for.  The ECMI draft was a small but necessary first step,
and there are plenty of opportunities to explore beyond that into other
aspects of sharing modular components.

There was a discussion on Joel recently in which a poster made the
distinction between theorized and extracted frameworks.  Those made from
theorizing tended toward overdesign and resulted in systems that were
too complex to be easily learnable, or to some degree even usable.  In
contrast, what he called "extracted" frameworks are those that are
naturally extracted in the course of building something; it's much like
building something without a framework, but with an eye for reuse on a
case-by-case basis during development of an actual software product.

With that in mind, we might consider this as a test case for doing one
small thing to define how such things work:

Ken's done some remarkable work on the Variable Watcher for the MC IDE.
It's a big, deep task, and I wouldn't want to replicate it.

But with Rev, Constellation, and MC, there are now three Message
Watchers; that's a lot of productivity lost to produce a single
component, over and over again.

The Variable Watcher may be a good test case because on the one hand its
scope is very focused, but on the other it's often considered so
integrated into the rest of the debugging environment that even though
the MC IDE is open source under the generous terms of the X11 license
(which supports both commercial and other open source use) every other
IDE maker has instead chosen to replicate that effort.

So here's a question:

What does a Variable Watcher expect from its environment, what does that
environment expect from it, and how could a Variable Watcher be designed
as a modular component to make it easy to integrate with existing IDEs?

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

Re: More on custom properties...

Richard Gaskin
In reply to this post by Trevor DeVore
--- In [hidden email], Trevor DeVore <lists@...> wrote:

>
> On Mar 31, 2006, at 11:45 AM, Mark Wieder wrote:
>
> > Trevor-
> >
> > Friday, March 31, 2006, 11:26:34 AM, you wrote:
> >
> > > The one problem is what if RegisterEvent makes it to the engine and
> > > there is no lib to handle it?  The engine throws an error even  
> > though
> > > the message was passed along the message path.  That brings me back
> > > to my post to the improve list...
> >
> > ...and I forget whether or not there was a buy-in from rev on the
> > idea...
>
> Mark Waddingham didn't have an objection either way.  I imagine it  
> isn't at the top of the priority list though since people get along  
> fine the current behavior.

I've also suggested the same thing to him, esp. since RunRev has
started adding non-engine messages without the "rev" prefix (see
savingStandalone and standaloneSaved).  As long as they're going to
encourage folks to use engine-looking message names they should at
least alter things so we don't need to take up a backscript to stub them.










 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|

[OT] Warning: SpamCop is lying again

Richard Gaskin

I just noticed a lot of revInterop messages in my spam bin, put there by
false positives from the vigilante service SpamCop.

According to SpamCop, all of Yahoo Group's servers are "verified open
relays", and the vigilante is hanging all messages without a trial.

I've written to both the willfully unaccountable SpamCop, and the
engineers at Yahoo, and neither seem to care that the other is wasting
their time.

Just thought I'd let you know in case you have SpamCop on your server.
(I don't really care for the dismissive lack of ethics of vigilante
services like SpamCop, but truth be told they do stop a lot of spam that
gets through other systems, albeit with a reputation for holding the
record for false positives).

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  [hidden email]       http://www.FourthWorld.com


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/revInterop/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


12345