I'm actually weighing up the pro's and con's of a binary solution over
a web based solution. Managing printing seems to be much easier from a
binary solution, but it seems to be the only major pro over going for
a web based solution in my case..
Still investigating, but it looks like more and more of my work is PHP/
Javascript/Java/XHTML based....
- Tom
On 31/12/2008, at 5:12 AM, Eric Williams wrote:
On Dec 30, 2008, at 2:05 AM, Tom Benson wrote:
This is going to sound strange from a long time RB user, but I've
been out of the loop for a while on Web based projects, so here
goes anyway.
Oversimplified Scenario:
Imagine (simply) a listbox that lists all of the installed plugins
in the apps "plugins" folder, with a folderitem reference to each
plugin stored in the celltag property. Easy enough.
Then imagine that to the right of that listbox is an empty area
that I would like to embed a containerControl instance in.
Which containerControl instance I embed depends on which plugin
from the list I select, and the instance should be loaded from that
plugin file/binary.
No way to do this, unless you're going to create the controls
yourself (i.e., the plugin contains a description of what the user
interface, and you create one during runtime based on the
description). RB does not support loading user interface elements
like this; they must exist in the compiled binary to appear on the
screen.
I'm guess what I'm asking is "Is it possible to create an
application that can be functionally extended by plugins (created
in REALbasic), similar in concept to photoshop, OS X mail etc.?"
Yes, but the user interface is the hard part. I built an entire
plugin system a number of years ago, but I don't think it's probably
flexible enough or fast enough for most needs. Essentially, each
plugin was an AppleScript, an internal class, or an external
compiled application that communicated with the host application via
a simple string interface. My plugin-enabled apps would have a list
of plugins, similar to what you're describing, but would only
present a user interface when the user pressed an "Edit Settings..."
button, and then the plugin settings would be presented in a modal
dialog. If you've ever used FileMaker, it's set up similar to some
of ScriptMaker circa 2001. :)
The principles are close to what you're talking about, but my
implementation was rather limited. Plugins could only be explicitly
called by the application; they couldn't wait around for things to
happen and take action on their own. They were limited in that they
had little access to the application's internal data structures
(with the exception of the compiled-in plugin classes).
Here's a wild thought. How about if your plugins presented a user
interface via HTML? Your app could query them for an HTML interface,
run it in HTML Viewer, and feed the result back to the plugin. This
would allow each plugin to present a very rich interface without
binding all the controls to RB code (of course, they would have to
programmed in JavaScript or something similar).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|