Paul,

I'm still struggling with this. I tried to make the changes you suggested (not sure if this is right) but my code now looks like this:


This gives me a "Unable to compile 'select_country': " error....

Suggestions or fixes on how I implemeted your suggestion?

Safe swoops
Sangiro

You are missing a comma:

value => scalar $IN->param('Ad_category') || $select ,



Unable to compile or hard errors are almost _always_ punctuation or other syntactical errors, not logic ones.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

There was an error:

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...

I actually added the comma before I mde this post. It gave me another error so I assumed (worngly I guess) that it should not be there. When I add it back I get:


Safe swoops
Sangiro

Oops, change:


to...

Paul,

Here's the code I'm currently working with:


I'm not sure if I added the my ($select) = shift; statement at the right place. At the moment this generates a dropdown but always defaults to the first country on the list... It does not go to the selected country when modifying.

Safe swoops
Sangiro

Paul, what field should I reference for the Ad_category above? I don't have an Ad_category field, I obviously have the normal Category table. Is this what this is referring to? If so, should this just be "Category" or should it have the db prefix in fromt of it?

Safe swoops
Sangiro

Category should be ok.

Just from a stylistic and "safety" note, if you are shifting items off the passed parameters stack, it's much safer and better, less confusing, to shift those values immediately, not down in the code. It's possible to get confused, and chase your tail for 'bugs' if you don't.

The problem is this:


value => [scalar $IN->param('Ad_category') || $select ],


It would be better to do it:


value => [$select || scalar $IN->param('Ad_category') ],


Since $select is what you are shifting off the stack (what was passed in) and if nothing was passed in, default to the <yecch> $IN hash for some potentially corrupted or weird value .


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

I think $IN->param('Category') can be removed. I just looked further up the thread at the tag structure (which I hadn't seen before) and he is wrapping the global with:

<%if Category%>

...and then if that returns true then he's passing the category into the global. As $Category is the same as $IN->param('Category') then it becomes redundant.


$select contains the same value as $IN->param('Category') - $select is just as insecure :)

You are now pulling the $IN values from another set of routines, inside another module or compiled block.

You can't trust it to pull the right $IN values, or not have them mixed up by that time. Maybe another running process, or maybe just buggy code refs, or whatever.

It's also confusing, and unnecessary -- especially if you can easily and specifically pass that value in. The key here, is "unnecessary" risk.

Good coding would suggest that you only take the $IN values from where they were originally passed in. Anything you need, you should specifically pass on (not necessarily from $IN, but from _any_ where). This has been a mantra for good coding for 20+ years.

If you need the $IN values, pass them as $in = $IN->get_hash()

When subroutines start pulling in values out of the air, you don't know where they are pulling them from -- only where you _think_ they are pulling them from <G>.

Repeatable, reproducable, and reliable coding would suggest that any values be specifically passed in, or requested (ie: grabbing your own table reference via $DB rather than the old $LINKS_DB || $DB->table().

I checked out some GT code, and in Build.pm, they ask for $IN in the category and detailed routine, as a last resort, and only to try to find an ID, if the check for a hash ref or passed in ID fails. That's probably OK, since those routines are called in several ways, one pretty directly via a user script. But it's only done on the right side of an || after everything else has failed, and only for one very specific -- and expected -- "harmless" type of value. "ID" is a key passed fragment of data, and the worst that will happen is it displays the wrong link. Also, it's the "top" or "key" field, so by calling it, even wrongly, you are getting the "whole" object, not a sub fraction of it. It's an entry point, not a branch.

Anyway, this is something that has been a mantra since I wrote my first line of code. "KNOW" where your data is coming from, and anything you need, EXPLICITLY pass. Don't "assume" anything. And this was back in the old stand-alone, single-user, single-process, single-brain-dead-OS days. It's even more true today.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Yes, that's the point I was making. As $Category is passed in to the global then you don't need $IN->param('Category') in the global itself. $Category is only $IN->param('Category') anyway, but just in the form of a template tag.

<G> Actually I realized that all that passing in was unnecessary -- redundant here, but I was commenting on the point about $select and $IN->_whatever_ being equally insecure. $select is "better" for the reasons above.

$IN should only be used in the original .cgi, or when you think the original .cgi didn't pass it in, or you are desperately trying to find a value, any value, and not bomb. But it's a risk. Are you grabbing the $IN that was, or the $IN that is now?

Once you call other modules (the jump.cgi / Jump.pm type construct, excluded) you should use explicitly passed values. Especially in things like the globals, or called functions from the templates. $IN will be unreliable. Even in the Jump.pm type construct, $IN should be called as soon as possible, then assigned to $in if needed more than initially. You at least know you have a uniform snapshot of what was in $IN when you started to work with it.

$IN is out of the modules control, but $in is encapsulated as best as perl can do it.

We've differed on this for quite a while now <G> But I'm old-school, and like to play it safe.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

They are both exactly the same. $select is the Category parameter but just in the form of a tag. Whether you pass $Category into the global, or call $IN->param('Category') directly, you'll still end up with the same value.


$IN doesn't change in the middle of your code. The parameters are retrieved when the $IN object is created, which is when the script is requested by a client.

Paul,

We need to agree to disagree on this. $IN is an object that can be accessed by methods outside the subroutine, or other process. $IN is a "global" object, that was created where $IN was requested -- usually quite a ways away from a global or called template function.

$in, or a passed parameter, is a copy of what was in $IN, at the time you started the process. It can't (easily, or accidentally) be altered or changed, and you'll always get the values you expected, or thought you would at _that_ point in the program.

While in most cases it may not matter, there are going to cases -- the ones that really create grief -- where it might matter. Play it safe :)

While $select and $IN->{'Adcategory'} or whatever may (usually) contain the same "value", $select is a value that was passed in, and belongs to, the currently running code segment. $IN belongs to _EVERY_ code segment called after the original script was initialized.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Pugdog,

OK - I've tried your alternative (Paul, I couldn't get your s to work either). When modifying it still gave me the first country in the list only and not the country already in the DB. Here's what I went with:

Global: (select_country)

And in my template I called it with:


Where:

Ad_Country is the name of the field that holds the country value for each record
select_country is the name of the Global (above) that bulds the dropdown
Country is the name of the DB table tha holds all the country names

Any thoughts?

Safe swoops
Sangiro

You are passing in $Country to the global - can you check what it contains.

change

my ($select) = shift;

to

my $select = shift;


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

That won't make a difference. It only makes a difference the other way around (so to speak). For example if you pass in an array to the subroutine and do:

my $arg = @_;

Then $arg will contain the number of elements in @_...but:

my ($arg) = @_;

....will make $arg the value of element 0 in @_

It's to do with scalar vs list context.

shift() will force scalar context anyway so brackets or no brackets will be the same.

I suspect this post will help solve this problem.

Thanks guys!

Safe swoops
Sangiro