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

[bugzilla-daemon at bugzilla.maptools.org]

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

           Summary: MLT implementation and resulting upgrade changes
           Product: Chameleon
           Version: 2.4
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
        AssignedTo: chameleon-dev at lists.maptools.org
        ReportedBy: mcgrawj at agr.gc.ca


Although this is not a 'bug' per se, I didn't want to send this out to a 
mailing list. I figured this approach would result in only the people involved 
in the implementation of the new MLT approach getting my question.

Obviously, I don't know the inner workings of the new MLT implementation (or 
the old one for that matter) as much as the person/people who made the changes 
introduced in chameleon 2.4, but I can't help wondering why it was decided to 
insert the new parameter to indicate what 'table' to use at the beginning of 
the parameter list rather than tacking it on as an optional arguement at the 
end.

The reason I ask is because, by inserting it at the front, that will require 
everyone who's ever written a custom widget that supports multiple languages to 
go through and make changes to their widgets. Whereas, if it was added at the 
end and made optional, people's existing code would likely work if they called 
their dbf file the same name as their widget (which from any examples I've ever 
seen, most people do). If you left the 'table' (now 'file') name optional, the 
code could somehow access the moMLT object's parent widget class name and use 
that name as the default unless a different 'table' was specified using the 
optional parameter.

I realize this would not apply to usage inside widget popup windows, but it 
would reduce some of the bother involved with upgrading from 2.2 to 2.4 and 
reduce the likihood of introducing other errors (with cutting/pasting mistakes 
or whatever). Even though I am only inserting parameters, because I am having 
to edit these custom widgets at all they will be highlighted as requiring a 
complete testing cycle.

Anyway, like I said, it's not a bug, but I'd really like to know why the choice 
was made to implement it this way because this upgrading is a pain. And, when 
it doesn't seem necessary it makes it hurt more. Obviously, if there's no way 
around it, that's one thing, but I can't imagine that is is the case. And, I 
figured it's better to bring something like this up now when the product is in 
beta than after the release when nothing can be done about it.

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.