* Thus wrote Philip Olson:
typeinteger/type parameter role=ref
choice=optwidth/parameter
VS
parameter role=ref choiceopt type=integerwidth/parameter
Parameter has no type attribute, so only the former is possible.
Ups, parameter also has no choice attribute, it
We may need a livedocs person to tackle this as the structure is already
in place. Using the same example we have the following in the
methodsynopsis (split from one line to fit in this email):
methodparam choice=opt
typeint/typeparameter role=referencewidth/parameter
/methodparam
I added
On August 18, 2004 03:52 pm, Gabor Hojtsy wrote:
We may need a livedocs person to tackle this as the structure is already
in place. Using the same example we have the following in the
methodsynopsis (split from one line to fit in this email):
methodparam choice=opt
typeinteger/type parameter role=ref
choice=optwidth/parameter
VS
parameter role=ref choiceopt type=integerwidth/parameter
Parameter has no type attribute, so only the former is possible.
Ups, parameter also has no choice attribute, it is of paramdef. Which in
turn can
Type information and by reference passing should be included IMHO too.
BTW the names of the parameters are missing from
http://livedocs.phpp.org/index.php?l=enq=function.exif-thumbnail
Livedocs does not handle parameters with amp; correctly, they show
up blank. I'll clean exif up, and add the
Type information and by reference passing should be included IMHO too.
BTW the names of the parameters are missing from
http://livedocs.phpp.org/index.php?l=enq=function.exif-thumbnail
Livedocs does not handle parameters with amp; correctly, they show
up blank. I'll clean exif
Done. But if this information is shown it seems we'd also have to
include all parameter information, like if it's optional. Look again
at the exif_thumbnail() docs for how this might look:
http://livedocs.phpp.org/index.php?l=enq=function.exif-thumbnail
As far as rendering, right now amp;
http://livedocs.phpp.org/index.php?l=enq=function.exif-thumbnail
As far as rendering, right now amp; and [] are typed into the parameter
listing and this feels dirty. If we could use a role with the parameter
tag (Curt suggested this in irc) it might solve this. For example:
parameter role=ref choice=optwidth/parameter
But anyway Goba what tags (if any) do you suggest for this?
This last option seems to be fine with me.
Should go as far as adding the type here too?
typeinteger/type parameter role=ref choice=optwidth/parameter
VS
parameter role=ref choiceopt
(ii) Parameter List: I'd like to see this kept as compact as
possible, so I'd prefer to do without the vertical spacing
between the parameter name and its description. (Also, if it
were possible to merge the top and bottom dashed borders, that
would be great!) However, I would
* Thus wrote Gabor Hojtsy:
BTW the names of the parameters are missing from
http://livedocs.phpp.org/index.php?l=enq=function.exif-thumbnail
livedocs doesnt seem to like:
parameteramp;width/parameter
And is very picky with whitespace between methodparam as well.
Curt
--
First, let
(ii) Parameter List: I'd like to see this kept as compact as
possible, so I'd prefer to do without the vertical spacing
between the parameter name and its description. (Also, if it
were possible to merge the top and bottom dashed borders, that
would be great!) However,
On 10 August 2004 23:53, Philip Olson wrote:
I'll work on some examples, this is going to be good.
Here's an example where:
* Two new sections: Parameter listing and CHANGELOG
* The parameter listing is a variablelist
* The CHANGELOG is a table
On Wed, 11 Aug 2004, Ford, Mike [LSS] wrote:
Oh, I like these! I have a few comments that I'd like to cast into
the pool for discussion:
(i) Personally, I'd like to see the Parameter Information and Change
Log before the full description, so I'd go for something like:
Oh, I like these! I have a few comments that I'd like to cast into
the pool for discussion:
(i) Personally, I'd like to see the Parameter Information and Change
Log before the full description, so I'd go for something like:
Definition(proto + *short* description of
I thought about this but here's why I went with one description.
First, the short definition (purpose) is already in the refpurpose
of the function. Also, writing a summary for each would be a bit
too difficult. As far as using just the first para, I think it'd
be confusing having it so far
Gabor Hojtsy wrote:
I thought about this but here's why I went with one description.
First, the short definition (purpose) is already in the refpurpose
of the function. Also, writing a summary for each would be a bit
too difficult. As far as using just the first para, I think it'd
be confusing
I'll work on some examples, this is going to be good.
Here's an example where:
* Two new sections: Parameter listing and CHANGELOG
* The parameter listing is a variablelist
* The CHANGELOG is a table
http://livedocs.phpp.org/index.php?l=enq=function.exif-thumbnail
This looks pretty
If you expect a table layout, why overload simple paragraphs with
attributes? If it is going to be a table, then para is not right for the
markup IMHO. It does not fit semantically and does not fit into DocBook
either. BTW I have not checked, but I don't think docbook has a version
attribute
Okay this sounds good, let's do it! The following would go right
along with our new refsect1 style, does it appear doable?
refsect1
reftitle.changelog;
para role=changed-behavior version=4.3.0
foo() is binary safe.
/para
para role=changed-parameter version=4.2.0
The length parameter is
The above would output something similar to:
CHANGELOG
---
|Version | Role | Description |
---
|4.3.0| |foo() is binary safe.
changelog
changedparameter
parameterlength/parameter
version4.2.0/version
para
Became optional with a default value of 1024.
/para
/changedparameter
...
/changelog
Maybe it's not generic enough, could we cover every condition?
changedbehavior, newparameter,
Now as to the CHANGELOG, I am guessing nobody will implement it
in DSSSL (I know I won't) so focusing on livedocs may end up
happening. Livedocs or bust, 2004!
Or 2005, 2006, 2007,. I don't mind focusing on livedocs, because I have
some free time now. But I would like to have the oficial
What it will contain:
1) Parameter changes (new, modified, ...)
2) Function changes (new features, new behaviors, ...)
3) PHP Version info for each change
From TODO:
new roles: seealso, newparameter, and changedparameter.
That idea is similar and here's one of the threads on the topic:
A partial proposal: CHANGELOG refsect1
What it will contain:
1) Parameter changes (new, modified, ...)
2) Function changes (new features, new behaviors, ...)
3) PHP Version info for each change
From TODO:
new roles: seealso, newparameter, and changedparameter.
Of course this is a good
A partial proposal: CHANGELOG refsect1
What it will contain:
1) Parameter changes (new, modified, ...)
2) Function changes (new features, new behaviors, ...)
3) PHP Version info for each change
From TODO:
new roles: seealso, newparameter, and changedparameter.
Of course this
This would be great and it's a perfect time to implement because
when people update old docs to the new refsect1 style we would
also implement these changelog entries! Woohoo!!!
What is the new refsext1 style? The credits tag?...
Each manual page is split up in sections, see
A partial proposal: CHANGELOG refsect1
What it will contain:
1) Parameter changes (new, modified, ...)
2) Function changes (new features, new behaviors, ...)
3) PHP Version info for each change
From TODO:
new roles: seealso, newparameter, and changedparameter.
That idea is similar and here's
I like the theory, its always handy to tell what has changed between version x
and version y. The implementation on the other hand, will be a bit more
interesting i think.
Nathan.
On Wednesday 28 July 2004 12:25, Philip Olson wrote:
A partial proposal: CHANGELOG refsect1
What it will
29 matches
Mail list logo
