Re: VCL
At 04:01 AM 22-02-1999 , you wrote:
>Daniel Berstein wrote:
>
>>About this future ECM, Euphoria Component Model, (ECL would be the
>>"standard" components deployed with Euphoria):
>>
>>A interface API should be developed to command the component
>>appearence/functionality. The component should be built providing a defined
>>interface. Interfaces may be:
>> ECM_Create() -- Creates an instance of the component
>> ECM_Destroy() -- Destroys an instance of the component
>> ECM_Command() -- Send a component specific command (like WinAPI's
>>SendMessage)
>> ECM_GetProperty() -- Retrives a component property (data
>member)
>> etc...
>
>Thanks for the links.
>
>You could fold all those seperate calls into a generic sendMessage command,
>much like Win32 does it. You've still encapsulated the functionality, but
>implementing the interface to the actual class becomes trivial - just build
>a index of routine id's:
True. But we don't have a specification. A standard way for retriving
information (runtime component quering) from the component is required too,
what functionality does this component have? Which are their parameters?
Return type?
Imagine an Euphoria IDE that allows visual form edition. To add a component
to it's palette all you need is "include" it to the source, then when the
user drops a component on the form the IDE can send a "display at x,y"
command and query the component for it's properties, etc...
The ECM "manager" itself shouldn't be complex. The work is for the
component builder, once built it can be perpetually reused.
>If Win32Lib was based on a true OO model (like WinMan was), then the COM
>approach would make sense. But for the most part, it's driven by the Win32
>API. By not trying to bury the Win32 interface, it's possible for someone to
>hack into the code and call Win32 directly - as many have chosen to do.
>Hiding it all behind a COM-style interface makes it portable, but prevents
>that kind of hacking.
That's the word: hack. ECM = !hack. COM-style interfaces do prevent from
hacking, but not of customization... you just need to sub-class an existing
component and override the appropiate methods. It's really nice to know
that the "control" you just created can coexist with third parties controls
and won't crash on another users win32lib distribution ;)
>I've also noticed that a number of UI implementations have taken a slightly
>different spin on the component model. Both Java Swing and the Zinc API have
>two seperate components to their UI - the control (a data field), and the
>data object represented by the control (a date value).
ECM ain't just for UI elements. In ECM the implemetation of the component
is up to the developer, as long as he respect the standard interfaces.
The complex task is to create the ECM specification, it should define a
reduced number of interfaces that maximize it's functionality.
Think of ECM not as a programming challenge (everything can be done some
other way), but of a conceptual model. What I call interface is just a
routine_id, but thinking of it as an Object interface makes it much more
powerful.
When I resume VE's development I'll start drafting something for ECM.
Regards,
Daniel Berstein
[daber at pair.com]
|
Not Categorized, Please Help
|
|
