Hi Lars,
On Jan 9, 2007, at 9:49 AM, Lars Huttar wrote:
Ah, wait... I get it. By clicking on "422ms" (how intuitive!), or
"xslt (testpage.xsl)" (better), you get the XML output.
Then you dig through the sample code, and discover that the profile
generator takes URL parameters (not sitemap parameters) "result" and
"component" that tell it to emit information about a particular output
of a particular component.
E.g.
http://localhost/samples/blocks/profiler/profile.html?key=
-9147137934425539743&result=0&component=1&cocoon-view=content
I guess the profile2.html view makes this a little more obvious, but
only after you discover that the "0" under "Last" is a link, and that
it might be something worthwhile to click on!
If you want to improve the profiler web interface and you have the time
to do it, please do it and drop a patch on JIRA (see below)...
http://cocoon.apache.org/2.1/userdocs/profile-generator.html has some
of this information; it would be good to have a link from
http://cocoon.apache.org/2.1/userdocs/concepts/profiler.html to the
latter. I've added a comment to that page in Daisy (does anybody read
those comments?)
Not sure... :-/
It would also be helpful to put an explanatory note about that on the
sample page:
http://localhost/samples/blocks/profiler/profile.html?key=
-9147137934425539743
could say at the top, "Click on a time to view the relevant XML result
from that component."
I agree, this is very useful functionality, but not very easy to
discover. Hence its value for newcomers, who need it most, is greatly
diminished.
I think I would like to rework this sample to be more illuminating,
and submit it for committing.
I think ideally if you could make the profiler page itself more
intuitive and/or add some explanatory text there (maybe)... then if
more is needed on the sample page, it could be added. In other words,
if the profiler page sucks, let's not just leave it that way and rely
on the sample page to explain it, instead let's improve it as much as
possible and if it still isn't self-explanatory, enhance the sample to
bridge the gap.
I would also be happy to work on improving the documentation pages.
That would be great, too. You'll need to spend a little time in the
docs area at cocoon.zones.apache.org to orient yourself, and Helma or
Reinhard or somebody can hook you up with a Diasy login with
"doc-editor" privileges, then you are set.
Can somebody tell me the process for getting changes approved and
committed?
Right here: http://cocoon.apache.org/2.1/1177.html
As for getting them "approved", it seems like it's more of a "do first"
approach in this community. You'll have to show them what you've got,
in the form of a patch... and then, hopefully someday the patch will be
accepted. You don't need any pre-approval to submit a patch, but
neither is there any guarantee it'll be accepted. Sometimes further
discussion is warranted, or the patch will be accepted w/ some
modifications. I have a few patches in limbo on JIRA that I'd very
much like to see accepted, so maybe it's time I made some noise :-)
In any case, you're to be commended for wanting to improve both the
code and the docs together :-) :-) :-)
best regards,
—ml—
