So would the doc comments be placed with the class doc comments and if no
event doc comments are present the generator would simply not pick up any
events?
> An event is not a part of a method. It is a part of a class. Yes, events
> are fired in methods. But the event listeners are registered a
> I know this would be more tedious, but couldn't this task not be left to
> the author of the code? After all, you manually have to code @param,
> @see and the other tags yourself, too.
Not exactly. The doc generator doesn't scan for doc comments, it scans
for structures that need documentatio
I know this would be more tedious, but couldn't this task not be left to
the author of the code? After all, you manually have to code @param,
@see and the other tags yourself, too. So why not add a tag @listen and
@dispatch?
@listen qx.constant.Event.INTERVAL on each interval event, widget tur
>> But how should this work for events? Events are just fired. OK. I could
>> scan the code for these calls, that actually fire the event. But where
>> should the doc comment be placed then?
>>
>> Perhaps we could change qx.core.Target, so events have to be declared,
>> before they can be fired.
Til Schneider schrieb:
>> You might want to think about adding a documentation tag for the events
>> thrown by the object.
>> This has been missing from the API docs in the 0.5.x branch and is very
>> important if one wants to make full use of the fine event system!
>
> Yes, right. We already th
> You might want to think about adding a documentation tag for the events
> thrown by the object.
> This has been missing from the API docs in the 0.5.x branch and is very
> important if one wants to make full use of the fine event system!
Yes, right. We already thought about this. The problem i
> Thanks for the article. Does the documentation generator store the parsed
> information as XML before it renders the HTML or does it go straight to
> HTML?
The documentation is stored as a serialized JavaScript data structure
(JSON) in the file source/demo/apiviewer/docTree.js.
All the advanta
Til Schneider schrieb:
> I've just written a wiki article that describes the new API
> documentation system.
>
> See: http://qooxdoo.org/documentation/developer/api_documentation
>
You might want to think about adding a documentation tag for the events
thrown by the object.
This has been missin
: [EMAIL PROTECTED]; qooxdoo Development
Subject: Re: [qooxdoo-devel] Experiences with webapp frameworks integration
> Documentation? We don't need no stinkin' documentation! Real engineers
read
> code, not documentation!
> :-) :-) :-)
I've just written a wiki article th
ECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian
Boulanger
Sent: June 21, 2006 5:53 AM
To: qooxdoo Development
Subject: Re: [qooxdoo-devel] Experiences with webapp frameworks integration
> 3. Dynamic UI generation
> I have to admit that I haven't used the great-sounding qxBuilder yet.
> Documentation? We don't need no stinkin' documentation! Real engineers read
> code, not documentation!
> :-) :-) :-)
I've just written a wiki article that describes the new API
documentation system.
See: http://qooxdoo.org/documentation/developer/api_documentation
___
> 3. Dynamic UI generation
> I have to admit that I haven't used the great-sounding qxBuilder yet.
> Like I said, I load the entire UI in one page and that's it.
> What's a typical use case, what's the performance like, and what are your
> current benefits in a real project?
[...]
> There's onl
Cool, cheers TilOn 6/21/06, Til Schneider <[EMAIL PROTECTED]> wrote:
> I know that one of the big goals of the namespaces branch was substantially> improved automatic documentation generation. I haven't used it, though, so I> don't know what state it's in. There is active work in progress on it (
> I know that one of the big goals of the namespaces branch was substantially
> improved automatic documentation generation. I haven't used it, though, so I
> don't know what state it's in. There is active work in progress on it (there
> were even check-ins related to it today). I suspect someon
"Danny Adair" <[EMAIL PROTECTED]> writes:
> I'll switch to the namespaces branch right away. :-)
> Found the stuff in tools/migration, but I'll probably adjust my code
> manually, it's not that much.
> Is there auto-updated API documentation for the namespaces branch somewhere
> browsable?
Docume
Thanks Derrell,I'll switch to the namespaces branch right away. :-)Found the stuff in tools/migration, but I'll probably adjust my code manually, it's not that much.Is there auto-updated API documentation for the namespaces branch somewhere browsable?
Kind regards,DannyOn 6/21/06, [EMAIL PROTECTED]
"Danny Adair" <[EMAIL PROTECTED]> writes:
> In my case, there's a one-page core application (= 1 template) which
> provides the main "qxWindow" and pulls the qooxdoo files from the
> available/enabled modules.
> The qxWindow (and in my case also a qxTabView) is globally accessible, and
> the modul
Hello,Just some thoughts, questions, and a couple of proposals :-).I'm currently working on an application where I am looking at ways of integrating the qooxdoo framework with the web app framework TurboGears (which has CherryPy at its core).
What are others using? How do you integrate qooxdoo?
-
18 matches
Mail list logo
