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):
> >>
> >>
> >> intwidth
> >>
> >
> >
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):
intwidth
I added a patch to do this.
http://www.powertrip.co.za/livedocs/
Please notice Ilia
* Thus wrote Philip Olson:
>
> > >> integer > >> choice="opt">width
> > >>
> > >> VS
> > >>
> > >> width
> > >
> > > 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 only be added
> >> integer >> choice="opt">width
> >>
> >> VS
> >>
> >> width
> >
> > 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 only be added inside a funcprototype according to the DocBook
>
width
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?
integer width
VS
width
Parameter has no type attribute, so only the former is possible.
Ups, parameter also has no choice attribute, it is
width
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?
integer width
VS
width
Parameter has no type attribute, so only the former is possible.
Goba
> > http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
> >
> > As far as rendering, right now & 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:
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=en&q=function.exif-thumbnail
As far as rendering, right now & and [
> >>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=en&q=function.exif-thumbnail
> >
> > Livedocs does not handle parameters with & correctly, they show
> > up blank. I'l
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=en&q=function.exif-thumbnail
Livedocs does not handle parameters with & correctly, they show
up blank. I'll clean exif up, and add the typ
> > (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!)
* Thus wrote Gabor Hojtsy:
>
> BTW the names of the parameters are missing from
>
> http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
livedocs doesnt seem to like:
&width
And is very picky with whitespace between as well.
Curt
--
First, let me assure you that this is no
(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 lik
Philip Olson 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 ha
> >> 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 confusi
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 ha
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 apart
> > 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* descr
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:
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
>
> http://livedocs.phpp.o
> 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=en&q=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 wh
> > The above would output something similar to:
> >
> > CHANGELOG
> >
> > ---
> > |Version | Role | Description |
> > ---
> > |4.3.0| |foo() is binary sa
Okay this sounds good, let's do it! The following would go right
along with our new refsect1 style, does it appear doable?
&reftitle.changelog;
foo() is binary safe.
The length parameter is optional with a default value of 1024.
length
The above would output something simil
> >
> >
> > length
> > 4.2.0
> >
> >Became optional with a default value of 1024.
> >
> >
> > ...
> >
> >
> > Maybe it's not generic enough, could we cover every condition?
> > , , etc. Thoughts?
>
> As the TODO suggests we planned to introduce roles, and not new tags. In
>
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:
http://m
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 websi
> > > 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 sectio
> > 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.
> 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
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 cont
31 matches
Mail list logo
