On Sun, Mar 28, 2010 at 12:06 PM, Niklas Laxström <[email protected]> wrote: > ^demon, Happy-melon, ialex, ashley and I have been preparing a new > class. It is intended to be replacement for the old wfMsg* functions > that many seem to dislike. > The most important reasons why we want to replace them are below. > There is some more at [1]. > * There is too many functions with too many parameters > * It is easy to do the wrong thing > * It is difficult to do the right thing > > The new class is in my opinion now ready enough for comments and > criticism. The full source code is at [2] and formatted documentation > at [3]. > It should be possible form the documentation to see how it is meant to be > used. > > Few examples are below. More examples and how they compare to old > wfMsg* functions can be found at [2]. > # $button = Xml::submitButton( Message::key( 'submit' )->text() ); > # Message::key( 'welcome-to' )->params( $wgSitename )->parse(); > # Message::key( 'bad-message' )->rawParams( '<script>...</script>' > )->escaped(); > # Message::key( 'file-log' )->params( $user, $filename > )->inContentLanguage()->text(); > > It should be noted that it is not our intention to replace > OutputPage::addWikiMsg() and ::wrapWikiMsg(). > > Things I'd like to have comments for: > (1) Is it easy to use this class? Have we solved the three main issues > given above? > (2) The primary entry point is Message::key(). The syntax is little > more verbose than wfMsg*'s, but much more readable imho. Do we want to > use even short wrapper for the entry point? If yes, how should it be > called? For example _() (often used in Gettext projects) and > Msg::key() have been suggested. > (3) Anything else with regards to the documentation, the code or other issues. > > In the current state the class should be able to cover almost all use > cases wfMsg-functions had, with some exceptions. I'd like to have some > tests for this class, can somebody help with that? Obviously this > quite a small change itself, but it will have a big impact when we > start converting code to use these new methods. For that reason I want > to get it right. I think we should proceed slowly during 1.17 cycle, > for example using these only in new code and iron out all problems. > Like ^demon pointed out at bug 16026 [4], we should perhaps review > HTML-safety of any message we convert to use these new methods. > > [1] http://www.mediawiki.org/wiki/New_messages_api > [2] > http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Message.php > [3] http://svn.wikimedia.org/doc/classMessage.html > [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=16026#c8 > > -- > Niklas Laxström > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >
Different train of thought from the factory/naming discussions. I don't really see the need to call ->params() once you've gotten the object, it seems like a needless step. Our current format of wfMsg( $key, $param, $param2, ... ) has worked well and is easy to remember. Might I suggest: Msg::get( $key, $param, $param2 )->parse(); I'm not commenting on the factory function, naming, or desired calling method. Just wanted to drop the (seemingly needless) call to params(). -Chad _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
