[Chameleon-dev] [Bug 1413] MLT implementation and resulting upgrade changes

[bugzilla-daemon at bugzilla.maptools.org]

http://bugzilla.maptools.org/show_bug.cgi?id=1413





------- Additional Comments From mcgrawj at agr.gc.ca  2006-04-06 14:40 -------
I'm not certain that my question was answered by your response. If it was and I
just didn't pick up on it, I apologize and hope you won't mind responding again.

I have no objection to moving away from the use of a dBase format, etc.; the
combined keyed-array approach is fine with me; and, similar to Bart, I have
edited all my custom widgets' calls to the MLT get method by inserting
'$this->mszWidgetName' at the front of the parameter list. It's this widget
identifier 'requirement' only that I am asking about and perhaps the problem is
that I'm not clearly staing what I want. I'll give it another try...

Again, I'm not talking about usage in popup windows, only the MLTs used within
the widgets.

>From what I can see, the moMLT object is accessed using the '$this' variable
which represents the widget. Does the moMLT object have any concept of its
parent? And, if not, can it? Because if it can, a new get function could be
added to mlt.php that still has only the 2.2 two parameters passed and calls the
new 2.4 get function with the name of its parent widget. Like this (excepting
that I don't know how to access the parent from within the MLT object):

function get($szDefault = "", $aszParams = array() )
{
    return $this->get($szDefault, $aszParams, get_class($this->getParent()))
}

I think my original post boils down to the following series of questions: 
1. Do the moMLT objects in the widgets have access to their parent objects
(widgets)? 
2. If not, can they? 
3. And if they do or can, can the new MLT implementation be enhanced to overload
the get method with the same get method declaration that used to be used
pre-2.4? That is, with just the two parameters. And, if your going to overload
it, the new get method's key parameter should be moved to the end (rather than
the beginning) to have consistent parameter lists between the two gets.

If it's not possible for the MLT to be made aware of its parent, then I agree
that the key parameter is necessary. Otherwise, that parameter is not necessary
but should be available as an option because the name of the dbf may not be the
same as the widget and in those circumtances I will need to add the key to the
parameter list. If it's not necessary because an adequate default can be used
(key = parent's class name), it will not be necessary to make clients have to
change all their custom widget.php files that use the MLT...only the ones that
have a dbf file name that is different than the widget name. Anyone would
appreciate that saving of their time and effort.

With respect
jtm





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Please do NOT reply to this email, use the link above instead to 
login to bugzilla and submit your comment. Any email reply to this
address will be lost.