in reply to Re: Potental project - Perl Beads?
in thread Potential project - Perl Beads?

First, the concept of a Java Bean is that it is a drop-in component that can be configured by an external mechanism (a so-called 'Bean Box'); this is done by inheriting certain functions, and having specific names for the methods that get and set properties for the Bean (eg getString, setString), thanks to Java's Reflection package. Typically, these end up being GUI elements but there's no need for them to be that way.

This isn't a problem in perl thanks to numerous ways to introspect a module after loading.

As for examples, let me try to give a couple. Let's say you wanted a stock quote off a certain web page out of the rest of the junk on the page. Sure, this is a breeze in straightforward perl, but the idea with Beads is that you can put this together without knowing the language to any great extent. So the connection in Beads would be something like:

ConstantBead : Stores the URL | V HTMLRetriverBead : Retrived the value from the input | : bead and returns the text of the | : HTML page that it refers to V LineMatcherBead : Given a multiline text document, | : return all lines that match a given | : pattern V TokerizerBead : Given a line, returns text that | : matches a given pattern V OutputBead : Prints input text to screen.
Note that the beads should be sufficiently reusable.

As another example, let's say I wanted to make a web page of thumbnails from a directory of images. Here's a possible Bead string for that:

ConstantBead | V DirectoryListingBead | V LineMatcherBead : limit to just .jpg | \ \___________________________ | \_________ \ V \ | LoadImageBead | | | | FileProperties Bead V V | ResizeImageBead StringModifierBead | | | :("<>-thumb.jpg") | V | | SaveImageBead <---------/ / / / / Value Bead HTMLTableGeneratorBead <------------/ :get size | V OutputBead
Here, I hopefully demonstrate that data sent through beads would need to have synchorization; here, SaveImageBead would wait until it has both inputs from data that was generated by LineMatcherBead, and HTMLTableGeneratorBead would also wait for the same. Note that this means that some beads would run in a threaded environment, while others would be 'batch' operations.

Again, these examples are easy enough to do in straightforward perl but what I'm aiming for is a way for those not familar with programming or scripting to have a solution to put together advanced 'scripts' without help. While XBeans, the JAva solution, will probably work too, using perl means that you avoid the overhead of instaniting a Java environment, you are probably insured of it working without the installation of additional packages on most *NIX installs, and that adding to the system by third parties should be much simpler than adding to it via Java.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

Replies are listed 'Best First'.
Re: Re: Re: Potental project - Perl Beads?
by suaveant (Parson) on Sep 24, 2001 at 17:44 UTC
    So, if I am grokking this correctly, it would almost be like building a super-layer scripting language on top of perl, and each bead is kind of a super function that encompasses popular perl code. Similar to modules or objects, but with a stricter set of rules for defining them... I suppose this could be a useful thing, but maybe not so useful as in java, since java is much more of a pain in the a** than perl :)

    I can see it as a good thing for perl, what I think would go well with it would be the ability to call a bean you didn't have, and the first run of the script would load all necessary beans from a known source, all you would need is use Perl::Beads; Just a thought. I suppose anything in the FAQ or Tutorials section would be fair game for a bead, as well.

    I'm not sure... it sounds plausible, but unless it is designed just right it could easily become so much perl cruft... but if designed right, it might help those less familiar with programming...

                    - Ant
                    - Some of my best work - Fish Dinner

Re (tilly) 3: Potental project - Perl Beads?
by tilly (Archbishop) on Sep 24, 2001 at 17:41 UTC
      Actually, it's pretty much exactly like that :-) ... the only thing here is trying to match what XBeans is doing in terms of how data is transferred around.

      And to answer someone else as pointed out in this thread, yes, XML would seem to be inefficient, but a hidden advantage of using XML as transfer mechanisms would be that beads would not necessarily have to lie on the same computer; the bead could easily be a report server that does something with XML and return XML back, or could be a client bead talking to a server bead, etc. In addition, beads would not necessary need to talk to other beads; using XML allows anything to be inserted into the mechanism as long as it understands the XML. Using perl internals would be nice, but at some point if you cross the machine boundary, you need to serialize the objects, and XML is a very convinent way to do this.

      -----------------------------------------------------
      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      It's not what you know, but knowing how to find it if you don't know that's important