Klaus Hartl schrieb:
> Agreed. I just thought that the conversion from "&" to "&" should be
> done while generating that xml file...
>
Ah, ok, good point. That makes both inline and generated docs readable.
--
Jörn Zaefferer
http://bassistance.de
Jörn Zaefferer schrieb:
> Klaus Hartl schrieb:
>> I found another little glitch with "&" characters in inline
>> documentation. Unless you do not escape it as "&" the XML for the
>> generated docs is ill-formed. But that means, that the inline
>> documentatin is misleading, for example for the fo
Klaus Hartl schrieb:
> I found another little glitch with "&" characters in inline
> documentation. Unless you do not escape it as "&" the XML for the
> generated docs is ill-formed. But that means, that the inline
> documentatin is misleading, for example for the form plugin
> formSerialize met
Jörn Zaefferer schrieb:
> Hi jQueryians,
>
> as discussed before, the jQuery API contains quite a lot of methods. The
> event shortcuts or one thing, another is single methods with optional
> parameters. Let's take slideDown() as an example. It has two paremters, speed
> and callback. There is
BIG thumbs up here... a few hours were spent trying to figure out what the hell
some of these functions expected... good stuff Jorn...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Jörn Zaefferer"
Sent: Monday, October 30, 2006 2:22 AM
To: discuss@jque
Mike Alsup schrieb:
>>> While we are at it, how to go about params that can be be a string or a
>>> number (like speed)? Just stating the argument is an object is ambiguous
>>> to me.
>>>
>>> What about: @param Integer|String ?
>
> Since there is no Integer data type I'd stick with Number and doc
> > While we are at it, how to go about params that can be be a string or a
> > number (like speed)? Just stating the argument is an object is ambiguous
> > to me.
> >
> > What about: @param Integer|String ?
Since there is no Integer data type I'd stick with Number and doc the
supported/expected v
> Makes sense to me. Although I just changed that for the cookie plugin,
> sigh (Maybe that made you start the discussion?).
Kind of. But your change makes sense, too. The method behaves quite different
based on the parameters. In the fadeIn(speed[, callback]) case, it essentially
does the same
> Output could look like this:
>
> someFunction(requiredArg[, optionalArg]);
Hm, makes not so much sense for getter/setter methods where the
behaviour is completly different.
These methods should remain splitted.
-- Klaus
___
jQuery mailing list
d
Jörn Zaefferer schrieb:
> Hi jQueryians,
>
> as discussed before, the jQuery API contains quite a lot of methods. The
> event shortcuts or one thing, another is single methods with optional
> parameters. Let's take slideDown() as an example. It has two paremters, speed
> and callback. There is
10 matches
Mail list logo
