Alex,

Still trying to figure this all out.

Are the user-configuration options stored in the files as:
Where a hash of arrays is created, such that each array is:

[
'field_name',
'field_value',
'field_description'
]


I'm trying to at least format my programs to become plugins once I understand it all <G>




PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Hi,

Yes, but you don't need to worry about that. To get your configuration you call:

my $cfg = Links::Plugins::get_plugin_user_cfg ('YahooSubcats');

and to save it:

Links::Plugins::set_plugin_user_cfg ('YahooSubcats', $cfg);

and it returns a hash reference of your options.

See the YahooSubcat mod as an example.

Cheers,

Alex

--
Gossamer Threads Inc.

Thing is, how do you get the values into that to begin with <G>

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Hi,

Ah, in the Install.pm you create your options with:

$mgr->install_options ( 'YahooSubcats', [ ['subcat_font', 'font size=2', 'font of the subcategory.'] ] );

If you use the Plugin Wizard it will create the Install file for you and you can tweak it as needed.

Cheers,

Alex

--
Gossamer Threads Inc.

Where I'm having a problem, and I guess I shouldn't be... is how to set up the variables for the plug-ins, similar to the "globals".

For instance, rather than abstracts, in the picture-post-gallery mod, the script needs to have a whole bunch of variables available to it, including the $CFG variables, $USER variables, and then it's own $UPLOAD_CFG set of variables (which include paths, options, etc).

Within my script, what should those configuration options be called? Is there a passed object that holds all that?

Right now, I'd have a my_plugin.pm which would be equivalent to the Links.pm in version 1.1x. That would be loaded on script start up, to hold the variables. But, I want that to be administered via the Admin/plugin options, so I don't have to re-invent the wheel and come up with an admin screen.

I'm getting too close to this, and probably need to take a break, since I've gotten further in the past 2 days than I ever thought possible. Right now, I have to integrate the filescan/process with the image upload, and the actual program will be working. The other features -- such as adding in existing collections, and re-creating databases or indexes, etc will follow, but I'm very close to a working picture-post-gallery-postcards program all in one.

What I've found is that the thumbnailer I'm using is using backtic function to run parts of the netpbm package to do the image conversions.

That should still function in CGI calls by the server, right? I'd just have to give full paths to the netpbm utilities, since the server user has no defaults set. This is something that is new to me, and I need to figure out how to prevent people from uploading files that would be security holes or problems. Maybe there are none, but when something is dropped to the system like that, the potential exists.



PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

There is a missing feature in /admin/GT/Plugins/Manager.pm in sub load_options:
The TEXT input fields always have size 20.

When TEXT input type is used, will call GT::SQL::Display::HTML::text. It awaits the 'form_size' => 'x' hashref (additionally to the name, and other options), otherwise will return SIZE=20 into TEXT input form...

Please correct it by adding an exception, or if you accept my modification, let me know: I will do it, and send a diff file for you.
Or if you want, contact me through email, and we will discuss it.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Alex,

Here is a possible solution of the missing feature. Well, it just corrects the TEXT input field problem, and only uses, the form_size key. If we would also want to use the other keys (default and type), then I would suggest other solution.
Could be easily correct the missing features from other types, like TEXTAREA or SELECT, etc, if there are missing, unimplemented features.

So to be able to resize the input TEXT form size, when installing plugin user options, you need this modification. It reads the first line of the Names field (the 5. parameter in plugin cfg, user options: 'user' => [ '1','2','3','4', [ this], [] ] array. ), so you have to type there the TEXT form size.

Replace this code:

To this code:

This is not the best soltution, but works.
Alex, if you would like, it can be improved to treat the other missing features.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...