Adding interface layers

swiftone has asked for the wisdom of the Perl Monks concerning the following question:

I'm working on a program (still in concept mode now), and I'd like to seperate the interface from the actual program, so the the end user can specify their interface of choice and new interfaces can be added (Tk,PerlGtk, Curses, whatever).

My question is: What is the best way to go about it?

My current thought is that my program will go something like this:

$interface=""; #$interface can be read from a config file
require $interface; #Can't use use because it isn't known at compile t
+ime
$object=new $interface; #symbolic reference to the interface package
#fiddle with my data.
$object->update_screen();  #one form of output
$item=$object->item();     #creates a sub element
$item->update();           #another form of output
[download]

So will this work? What are the problems involved in using require rather than use? Is there a more standard way to have an interface layer? Perhaps with a standard Interface package, and you specify modules for it to use, much like DBI provides a standard interface to DBD modules?

Comment on Adding interface layers Download Code

Replies are listed 'Best First'.
Re: Adding interface layers by btrott (Parson) on May 24, 2000 at 19:30 UTC
Well, if you're planning on using similar interfaces, where they all have something akin to an "update_screen" method, etc., then your idea--of a DBI-like interface to implementation modules--sounds like an interesting one. The problem with that is that if you move into other interfaces, they don't necessarily have the same paradigms as your current interfaces--so you end up grafting functionality meant for one interface onto a completely different, and non-fitting, interface. The key, I guess, is to be as abstract as possible. I'll tell you, though, how I've done similar things in the past. Rather than objectify my interfaces, I've objectified the backend--I've created an API that lets me manipulate the objects that my interfaces will be manipulating. Then across all of my interfaces I have a standardized way of updating, modifying, adding, and removing data (or whatever it is that you're doing). The interfaces, then--since they really don't have much in common, in my case--exist essentially as UI wrappers around my API. And they don't need--and shoudn't--be sharing functionality, because there's none to share; a forms-based web interface, in my mind, doesn't share much functionality with a command-line interface, for example. Just to give you some ideas. By the way, there are really no problems using require instead of use. Just make sure you wrap it in an eval in case it blows up (since it'll be a run-time error). Just remember that using require won't call import for you, whereas use will. So if you're exporting, that's something to be aware of.	[reply]
RE: Re: Adding interface layers by swiftone (Curate) on May 24, 2000 at 19:36 UTC
Sounds fascinating. I realized that the functions for my interfaces would have to be generic and abstract to allow for the flexibility I wanted. Could you give a short demonstration of an API modifying the interface as you described? That's what I'm curious about, and I'm not really sure how to do that. Also, wrapping my use in an eval, would it be: `$interface="MyInterface"; #demo, could be any of my interface packages eval "use $interface"; die "Interface dead" if $@; #...rest of program here` [download]	[reply] [d/l]